Date   

Re: Writing a BSP from downstream kernel sources

Jonas Vautherin
 

Thanks a lot for the advice! However, I can't seem to find a `const` that I can simply remove. To give more context, here is the log output around such an error (it seems like it is often surrounded by this log2.h warning, by the way):

| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
|                  from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kallsyms.h:9,
|                  from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/ftrace.h:10,
|                  from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/kernel/extable.c:18:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
|    22 | int ____ilog2_NaN(void);
|       | ^~~
|   CC      fs/fat/dir.o
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
|                  from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/list.h:8,
|                  from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/module.h:9,
|                  from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/fs/fat/dir.c:16:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
|    22 | int ____ilog2_NaN(void);
|       | ^~~
|   CC      block/deadline-iosched.o
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
|                  from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/block/deadline-iosched.c:6:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
|    22 | int ____ilog2_NaN(void);
|       | ^~~
| /tmp/cc52vFrQ.s: Assembler messages:
| /tmp/cc52vFrQ.s:2683: Error: .err encountered
| /tmp/cc52vFrQ.s:2927: Error: .err encountered
|   LD      sound/sparc/built-in.o
|   LD      sound/spi/built-in.o
| make[3]: *** [/home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/scripts/Makefile.build:257: block/scsi_ioctl.o] Error 1

I pasted the full output here, if that can help: https://paste.ubuntu.com/p/KqN8nVWmvv/. The lines that seem to get the log2 warning are:

```
extern __attribute__((const, noreturn))
int ____ilog2_NaN(void);
 ```

So there is a const there, but well... not sure what to do with it :-).

Best,

On Mon, Jan 25, 2021 at 9:00 AM Diego Santa Cruz <Diego.SantaCruz@...> wrote:

From: yocto@... <yocto@...> On Behalf Of Jonas Vautherin via lists.yoctoproject.org
Sent: 24 January 2021 14:30
To: Jonas Vautherin <jonas.vautherin@...>
Cc: Paul Barker <pbarker@...>; Yocto-mailing-list <yocto@...>
Subject: Re: [yocto] Writing a BSP from downstream kernel sources

 

Just to close this: it seems like the gcc-cross-arm used by yocto gatesgarth is too new for that specific downstream kernel (3.18.31).

 

The goal was to get a proper BSP package for this device for a modern yocto, so I don't think I will try with an older version of Yocto. If I compile an old gcc as part of a custom Yocto layer (on gatesgarth), I am guessing that I will have issues creating a distro that runs both on RPi and on that older device (because RPi will have a newer kernel and gcc, and the skycontroller will use older ones). I also guess that the downstream dts won't work with a modern kernel, and I would not know how to write one myself for that apq8009 chip.

 

Hence, I'm giving up. Thanks a lot for the help :-).

[Diego Santa Cruz] Wait! You may be able to get it working, see below.

 

On Sat, Jan 23, 2021 at 2:07 PM Jonas Vautherin via lists.yoctoproject.org <jonas.vautherin=gmail.com@...> wrote:

Thanks a lot for the answer!

 

It seems like using `KCONFIG_MODE = "--alldefconfig"` with `KBUILD_DEFCONFIG = "msm8909_defconfig"` now ends up with the same kind of errors as when I use the defconfig from the downstream kernel [1], i.e.:

 

[Diego Santa Cruz] I happen to be doing a similar kind of work, getting an even older (2.6.37+) downstream kernel for an ARM machine to compile with recent GCC in Yocto, in my case GCC 9.3 from dunfell. There are a few fixes and backports necessary to make it happen and boot. I’m not done with the work yet, so I do not know how stable it is, but I have it booting.

```

| /tmp/ccz8jKgm.s: Assembler messages:
| /tmp/ccz8jKgm.s:985: Error: .err encountered

```

[Diego Santa Cruz] The fix here is rather simple once you understand what’s going on, the problem is abusive use of const for register variables, see https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Local-Register-Variables.html so when put_user() is used for a literal constant value it gets assigned the wrong register, so just remove the const qualifier from the put_user() register variable assignment for the value argument. For my older kernel the patch is like this.

--- arch/arm/include/asm/uaccess.h

+++ arch/arm/include/asm/uaccess.h

@@ -145,7 +145,7 @@

 #define put_user(x,p)                                                                                                    \

                ({                                                                                                                             \

-                               register const typeof(*(p)) __r2 asm("r2") = (x); \

+                              register typeof(*(p)) __r2 asm("r2") = (x);                             \

                                register const typeof(*(p)) __user *__p asm("r0") = (p);\

                                register int __e asm("r0");                                                           \

                        switch (sizeof(*(__p))) {                                                \

 

Could it be related to the tuning, e.g. I'm somehow defining a wrong toolchain in my machine configuration [2] and it fails to build? I was thinking about the tune-cortexa7.inc include, though it seems to me that the apq8009 is a cortexa7 [3]:

 

[Diego Santa Cruz] Other commits from post 3.18 that you may need to backport are the following (start from bottom of list)

474c90156c8dcc2fa815e6716cc9394d7930cb9c give up on gcc ilog2() constant optimizations

cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the various compiler-gcc[345].h files

f6d133f877c8bb0a0934dc8c521c758ee771e901 compiler-gcc.h: neatening

7829fb09a2b4268b30dd9bc782fa5ebee278b137 lib: make memzero_explicit more robust against dead store elimination

cb4188ac8e5779f66b9f55888ac2c75b391cde44 compiler: introduce __alias(symbol) shortcut

0b053c9518292705736329a8fe20ef4686ffc8e9 lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR

ee91ef6173e81819f5ff610c2485802081635657 bufferhead: force inlining of buffer head flag operations

cc7fce80229067890365c1ee196be5d304d36dea mtd: blkdevs: fix switch-bool compilation warning

 

 

> The Qualcomm Snapdragon 212 APQ8009 is an entry level SoC for Android based tablets and smartphones. It contains four ARM Cortex-A7 CPU cores (quad core)

 

 

Best,

 

On Sat, Jan 23, 2021 at 11:06 AM Paul Barker <pbarker@...> wrote:

On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin <jonas.vautherin@...> wrote:
>
> As a learning experience, I am trying to create a BSP for a device I own and whose downstream kernel is published. The device in question is the Parrot Skycontroller3, and the sources are available here.
>
> Let me start by sharing my issue. When I build the kernel with `bitbake virtual/kernel`, it fails with errors like:
>
> ```
> |   AS      arch/arm/lib/backtrace.o
> |   AS      arch/arm/lib/bswapsdi2.o
> |   AS      arch/arm/lib/call_with_stack.o
> | /tmp/ccz8jKgm.s: Assembler messages:
> | /tmp/ccz8jKgm.s:985: Error: .err encountered
> | /tmp/ccz8jKgm.s:1033: Error: .err encountered
> | /tmp/ccz8jKgm.s:6812: Error: .err encountered
> ```
>
> My layer is available here.
>
> I created it getting inspiration from meta-raspberrypi and meta-qti-bsp, which seems to have the same CPU: apq8009. According to the Parrot sources, my device runs a Qualcomm apq8009/msm89090 cpu. In my repo, I use as a defconfig file the linux.config that is available in the Parrot sources (I copied it in my kernel recipe under `files/defconfig` and added it to SRC_URI).
>
> The Parrot sources also refer to `LINUX_DEFAULT_CONFIG_TARGET := msm8909_defconfig`, so I tried to set `KBUILD_DEFCONFIG = "msm8909_defconfig"`, but that is failing with different errors, such as:
>
> ```
> error: 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this function); did you mean 'DMA_ATTR_NON_CONSISTENT'?
> ```
>
> or
>
> ```
> error: 'L_PTE_YOUNG' undeclared
> ```
>
> As a side note, their `drivers/Kconfig` seemed invalid, so I patched it.
>
> I am a bit lost now, not completely sure where my issues come from. I realize that changing the defconfig has quite some impact (I get different errors), and also that my machine configuration may be completely wrong (I am essentially guessing from the fact that it is an apq8009/msm8909, but for instance the tuning I just copied from meta-qti-bsp, which may be invalid).
>
> I would be glad if I could get hints about debugging this. Again, it is really a learning project: I would like to learn how to create a BSP from a downstream kernel.

I think setting `KBUILD_DEFCONFIG = "msm8909_defconfig"` is likely the
correct approach here. What you may be missing though is the correct
value for KCONFIG_MODE. By default, the supplied defconfig file is
copied to .config but dependencies between config options aren't
resolved. You need to set `KCONFIG_MODE = "--alldefconfig"` to get the
equivalent of `make msm8909_defconfig` to occur. See
https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linux/linux-raspberrypi.inc#L19
for an idea of how this is done for Raspberry Pi.

Thanks,

--
Paul Barker
Konsulko Group


--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com


#yocto #zeus #sdk populate_sdk_ext build failing #yocto #zeus #sdk

Monsees, Steven C (US)
 

 

I need some help in understanding why the SDK EXT is failing to build under zeus…

 

Can someone explain why the extended sdk build fails and how I might resolve ?

 

sbcb-defaultfs kernel builds and boots correctly…

 

SDK builds under zeus for sbcb-defaultfs :

 

bitbake sbcb-defaultfs-full -c populate_sdk    -WORKING CORRECTLY

 

bitbake sbcb-defaultfs-full -c populate_sdk_ext  -Fails build with the following Errors:

 

17:13 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default> bitbake sbcb-defaultfs-full -c populate_sdk_ext

Loading cache: 100% |###########################################################| Time: 0:00:00

Loaded 3645 entries from dependency cache.

NOTE: Resolving any missing task queue dependencies

 

Build Configuration:

BB_VERSION           = "1.44.0"

BUILD_SYS            = "x86_64-linux"

NATIVELSBSTRING      = "rhel-7.9"

TARGET_SYS           = "x86_64-poky-linux"

MACHINE              = "sbcb-default"

DISTRO               = "limws"

DISTRO_VERSION       = "3.0.4"

TUNE_FEATURES        = "m64 corei7"

TARGET_FPU           = ""

meta

meta-poky            = "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"

meta-perl

meta-python

meta-filesystems

meta-networking

meta-initramfs

meta-oe              = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"

meta                 = "master:a32ddd2b2a51b26c011fa50e441df39304651503"

meta-intel           = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"

meta-intel

workspace            = "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"

 

Initialising tasks: 100% |######################################################| Time: 0:00:04

Checking sstate mirror object availability: 100% |##############################| Time: 0:00:00

Sstate summary: Wanted 503 Found 298 Missed 205 Current 1936 (59% match, 91% complete)

NOTE: Executing Tasks

NOTE: Setscene tasks completed

WARNING: rpcsvc-proto-native-1.4+gitAUTOINC+9bc3b5b785-r0 do_fetch: Failed to fetch URL git://github.com/thkukuk/rpcsvc-proto, attempting MIRRORS if available

WARNING: nativesdk-libnss-nis-3.1+gitAUTOINC+062f31999b-r0 do_fetch: Failed to fetch URL git://github.com/thkukuk/libnss_nis, attempting MIRRORS if available

NOTE: Excluding local workspace layer /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/workspace from extensible SDK

ERROR: sbcb-defaultfs-full-1.0-r0 do_populate_sdk_ext: Failed to generate filtered task list for extensible SDK:

/bin/bash: line 0: .: .: is a directory

ERROR: bitbake failed:

/bin/sh: bitbake: command not found

ERROR: sbcb-defaultfs-full-1.0-r0 do_populate_sdk_ext: Error executing a python function in exec_python_func() autogenerated:

 

The stack trace of python calls that resulted in this exception/failure was:

File: 'exec_python_func() autogenerated', lineno: 2, function: <module>

     0001:

*** 0002:copy_buildsystem(d)

     0003:

File: '/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/classes/populate_sdk_ext.bbclass', lineno: 444, function: copy_buildsystem

     0440:    sdk_ext_type = d.getVar('SDK_EXT_TYPE')

     0441:    if (sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative) and not sdk_include_nativesdk:

     0442:        # Create the filtered task list used to generate the sstate cache shipped with the SDK

     0443:        tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'

*** 0444:        create_filtered_tasklist(d, baseoutpath, tasklistfn, conf_initpath)

     0445:    else:

     0446:        tasklistfn = None

     0447:

     0448:    if os.path.exists(builddir + '/cache/bb_unihashes.dat'):

File: '/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/classes/populate_sdk_ext.bbclass', lineno: 180, function: create_filtered_tasklist

     0176:        # Clean out residue of running bitbake, which check_sstate_task_list()

     0177:        # will effectively do

     0178:        clean_esdk_builddir(d, sdkbasepath)

     0179:    finally:

*** 0180:        os.replace(sdkbasepath + '/conf/local.conf.bak', sdkbasepath + '/conf/local.conf')

     0181:

     0182:python copy_buildsystem () {

     0183:    import re

     0184:    import shutil

Exception: FileNotFoundError: [Errno 2] No such file or directory: '/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/sdk-ext/image//opt/limws/3.0.4/conf/local.conf.bak' -> '/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/sdk-ext/image//opt/limws/3.0.4/conf/local.conf'

 

ERROR: Logfile of failure stored in: /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/temp/log.do_populate_sdk_ext.14130

ERROR: Task (/disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/recipes-core/images/sbcb-defaultfs-full.bb:do_populate_sdk_ext) failed with exit code '1'

NOTE: Tasks Summary: Attempted 6770 tasks of which 6274 didn't need to be rerun and 1 failed.

 

Summary: 1 task failed:

  /disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/recipes-core/images/sbcb-defaultfs-full.bb:do_populate_sdk_ext

Summary: There were 2 WARNING messages shown.

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

17:49 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>


Re: Task only for target recipe

Ayoub Zaki
 

thanks for the hint :-)

it did it however I run in other problems:

My goal is to cross-compile executable scripts into binaries using shc tool:  https://github.com/neurobin/shc

the SHC tool converts the scripts into C files, inherits the CC, CFLAGS and LDFLAGS from environment and compiles them using ${CC}.

This works fine for recipes that cross-compile since  CC, CFLAGS and LDFLAGS are defined but stuck when  dealing with allarch recipes (They are Not defined).

Is there a way to overcome this?


Cheers



On Thu, Jan 28, 2021 at 10:26 PM Richard Purdie <richard.purdie@...> wrote:
On Thu, 2021-01-28 at 18:53 +0100, Ayoub Zaki via
lists.yoctoproject.org wrote:
> Hello I created a new task that I want to run for every recipe of my
> image but only for target recipes and skip all native, sdk,...
> mytask.bbclass:
>
> addtask do_mytask after do_install
>
> do_mytask() {
>     :
> }
>
> do_mytask_class-target() {
>
>     bbwarn "mytask"
>     :
> }
>
> I added to local.conf :
>
> INHERIT += "mytask"
>
> I don't see it running! what is the proper way to achieve this?

How are you running it? You've said you want it to run after do_install
but not what should trigger it.

Adding "before do_build" to the addtask line for example might trigger
it (do_build is the default task).

Cheers,

Richard


Re: SDKMACHINE and ppc64le issue with latest head?

Richard Purdie
 

On Fri, 2021-01-29 at 13:48 -0600, Andrew Geissler wrote:

On Jan 29, 2021, at 10:54 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:

On Fri, 2021-01-29 at 08:40 -0800, Andrew Geissler wrote:
What was SDKMACHINE set to before?
Hey Richard, thanks for the quick response.

We did not have it set. It looks like this recent commit is what
changed things on us:

commit c74ec1dd7393b9dc7bec1a3ca2ed0a56fb18d8fb
Author: Ross Burton <ross@burtonini.com>
Date: Tue Dec 22 17:23:14 2020 +0000

    bitbake.conf: default SDKMACHINE to the build host architecture


Looks like I need to submit a patch to y'all to add a ppc64le.conf to
conf/machine-sdk/?
That would likely avoid the failures you're seeing, yes.

I really wish we had better support for ppc64le both for hosts and
targets and had people actively involved/maintaining the ppc support,
its in need of massive modernisation particularly on the target side.
Darn, I tried just adding this:

cat meta/conf/machine-sdk/ppc64le.conf

SDK_ARCH = "ppc64le"
ABIEXTENSION_class-nativesdk = ""

I get further but then hit a bunch of fails like this:

ERROR: /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb: Unable to determine endianness for architecture '${SDK_ARCH}'
ERROR: /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb: Please add your architecture to siteinfo.bbclass
ERROR: Failed to parse recipe: /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb
ERROR: /home/andrewg/Code/openbmc/meta/recipes-graphics/xorg-lib/libxext_1.3.4.bb: Unable to determine endianness for architecture '${SDK_ARCH}'
ERROR: /home/andrewg/Code/openbmc/meta/recipes-graphics/xorg-lib/libxext_1.3.4.bb: Please add your architecture to siteinfo.bbclass


I’m did some grepping around but don’t see anything obvious. Why is it not
finding the SDK_ARCH I’ve set in the new conf file?

Wondering if I should just go with my first workaround and set SDKMACHINE=x86_64.
Apparently using that default in the past hasn’t affected our use cases.
SDKMACHINE is the machine to run any SDK that is built on. If you're
not building an SDK or eSDK, it won't matter to your use case.
BUILD_ARCH is the machine you're building upon which is already being
set correctly and unchanged.

Cheers,

Richard


Re: pypi setuptools based recipe fails ModuleNotFoundError: No module named 'pkg_resources' #python

Konrad Weihmann
 

The issue here is that you are overwriting the DEPENDS after the inherit.
Two ways to solve this problem

Either use

DEPENDS = "python3-astropy-helpers"
PYPI_PACKAGE = "astropy"
inherit pypi


or

PYPI_PACKAGE = "astropy"
inherit pypi

DEPENDS += "python3-astropy-helpers"

python3-setuptools doesn't need to be added at all manually as this is done implicitly by setuptools3 class

On 29.01.21 21:41, ddbabich@bootseeds.com wrote:
I'm attempting to make a simple bitbake recipe for python3-astropy that inherits from pypi and setuptools3.  The very simple recipe is attached.
When I build I'm getting this error:
|     import pkg_resources
| ModuleNotFoundError: No module named 'pkg_resources'
| WARNING: exit code 1 from a shell command.
I don't understand this error because I'm using setuptools3 which I believe contains pkg_resources.  In desperation I added a "DEPENDS = "python3-setuptools" but that did not help either.  I'd appreciate any advice on this.
Thanks


pypi setuptools based recipe fails ModuleNotFoundError: No module named 'pkg_resources' #python

David Babich
 

I'm attempting to make a simple bitbake recipe for python3-astropy that inherits from pypi and setuptools3.  The very simple recipe is attached.
When I build I'm getting this error:

|     import pkg_resources

| ModuleNotFoundError: No module named 'pkg_resources'

| WARNING: exit code 1 from a shell command.

I don't understand this error because I'm using setuptools3 which I believe contains pkg_resources.  In desperation I added a "DEPENDS = "python3-setuptools" but that did not help either.  I'd appreciate any advice on this.
Thanks


Re: #yocto #gstreamer #gstreamer1.0-plugins-bad #yocto #gstreamer #aom #av1

Randy MacLeod
 

On 2021-01-29 3:11 p.m., Randy MacLeod wrote:
Did you figure this out?
Oops, I see that Khem has replied to a later email.

--
# Randy MacLeod
# Wind River Linux


Re: #yocto #gstreamer #gstreamer1.0-plugins-bad #yocto #gstreamer #aom #av1

Randy MacLeod
 

On 2021-01-04 3:43 a.m., safouane maaloul wrote:
Bonjour, j'essaye d'ajouter le aom plugin au niveau de la gstreamer1.0-plugins-bad. J'ai basculé sur gatesgarth version. Je commence à faire lebuild. J'avais un problème de lisence. Je l'ai résolu. Et maintenant j'ai un problème "no such file or directory automake-native yocto" et j'arrive pas à la résoudre ? Est-ce que vous pouvez m'aider ? y a t il quelqu'un qui a essayé d'ajouter av1 codec (aom plugins/gstreamer1.0-plugins-bad).
Cordialement,
Safouane.Maaloul
Bonjour Safouane.Maaloul,

Did you figure this out?

The Yocto email list is >99.99% English so please consider translating
before posting:

Google translate says:

Hello, I'm trying to add the aom plugin to the level of the
gstreamer1.0-plugins-bad. I switched to gatesgarth version. I start to
do a build. I had a license problem. I solved it. And now I have a "no
such file or directory automake-native yocto" problem and I can't
solve it? Can you help me ? has anyone tried adding av1 codec (aom
plugins / gstreamer1.0-plugins-bad).
I don't use gstreamer but if you answer the following questions,
you may get an answer:

What version of oe-core/poky are you using?
What's the top level commit id?
What image are you using and what changes have you made
to your local.conf file?

If you are only using oe-core or poky and have a reproducible
problem and no one helps, you can open a defect as decribed here:

http://docs.yoctoproject.org/dev-manual/common-tasks.html#submitting-a-defect-against-the-yocto-project

../Randy


--
# Randy MacLeod
# Wind River Linux


Re: SDKMACHINE and ppc64le issue with latest head?

Andrew Geissler
 

On Jan 29, 2021, at 10:54 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:

On Fri, 2021-01-29 at 08:40 -0800, Andrew Geissler wrote:
What was SDKMACHINE set to before?
Hey Richard, thanks for the quick response.

We did not have it set. It looks like this recent commit is what
changed things on us:

commit c74ec1dd7393b9dc7bec1a3ca2ed0a56fb18d8fb
Author: Ross Burton <ross@burtonini.com>
Date: Tue Dec 22 17:23:14 2020 +0000

bitbake.conf: default SDKMACHINE to the build host architecture


Looks like I need to submit a patch to y'all to add a ppc64le.conf to
conf/machine-sdk/?
That would likely avoid the failures you're seeing, yes.

I really wish we had better support for ppc64le both for hosts and
targets and had people actively involved/maintaining the ppc support,
its in need of massive modernisation particularly on the target side.
Darn, I tried just adding this:

cat meta/conf/machine-sdk/ppc64le.conf

SDK_ARCH = "ppc64le"
ABIEXTENSION_class-nativesdk = ""

I get further but then hit a bunch of fails like this:

ERROR: /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb: Unable to determine endianness for architecture '${SDK_ARCH}'
ERROR: /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb: Please add your architecture to siteinfo.bbclass
ERROR: Failed to parse recipe: /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb
ERROR: /home/andrewg/Code/openbmc/meta/recipes-graphics/xorg-lib/libxext_1.3.4.bb: Unable to determine endianness for architecture '${SDK_ARCH}'
ERROR: /home/andrewg/Code/openbmc/meta/recipes-graphics/xorg-lib/libxext_1.3.4.bb: Please add your architecture to siteinfo.bbclass


I’m did some grepping around but don’t see anything obvious. Why is it not
finding the SDK_ARCH I’ve set in the new conf file?

Wondering if I should just go with my first workaround and set SDKMACHINE=x86_64.
Apparently using that default in the past hasn’t affected our use cases.


Cheers,

Richard


Re: SDKMACHINE and ppc64le issue with latest head?

Richard Purdie
 

On Fri, 2021-01-29 at 08:40 -0800, Andrew Geissler wrote:
What was SDKMACHINE set to before?
Hey Richard, thanks for the quick response.

We did not have it set. It looks like this recent commit is what
changed things on us:

commit c74ec1dd7393b9dc7bec1a3ca2ed0a56fb18d8fb
Author: Ross Burton <ross@burtonini.com>
Date:   Tue Dec 22 17:23:14 2020 +0000

    bitbake.conf: default SDKMACHINE to the build host architecture


Looks like I need to submit a patch to y'all to add a ppc64le.conf to
conf/machine-sdk/?
That would likely avoid the failures you're seeing, yes.

I really wish we had better support for ppc64le both for hosts and
targets and had people actively involved/maintaining the ppc support,
its in need of massive modernisation particularly on the target side.

Cheers,

Richard


Re: SDKMACHINE and ppc64le issue with latest head?

Andrew Geissler
 

> What was SDKMACHINE set to before?

Hey Richard, thanks for the quick response.

We did not have it set. It looks like this recent commit is what changed things on us:

commit c74ec1dd7393b9dc7bec1a3ca2ed0a56fb18d8fb
Author: Ross Burton <ross@...>
Date:   Tue Dec 22 17:23:14 2020 +0000

    bitbake.conf: default SDKMACHINE to the build host architecture


Looks like I need to submit a patch to y'all to add a ppc64le.conf to conf/machine-sdk/?


Re: SDKMACHINE and ppc64le issue with latest head?

Richard Purdie
 

On Fri, 2021-01-29 at 06:38 -0800, Andrew Geissler wrote:
Over in OpenBMC, we utilize a mix of x86 and ppc64le machines for our
CI.

Our latest rebase of poky master
(https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/39533/) has
started failing to compile on our ppc64le machines with the below
error.

I can workaround it by setting "SDKMACHINE=x86_64" but that seems a
bit weird on a ppc64le machine?

+ bitbake obmc-phosphor-image obmc-phosphor-debug-tarball
ERROR: OE-core's config sanity checker detected a potential
misconfiguration.
    Either fix the cause of this error or at your own risk disable
the checker (see sanity.conf).
    Following is the list of potential problems / advisories:

    Specified SDKMACHINE value is not valid
What was SDKMACHINE set to before?

Cheers,

Richard


[dunfell][PATCH v2 3/3] bitbake: fetch/git: download LFS content too during do_fetch

Mikko Rapeli
 

From: Matt Hoosier <matt.hoosier@garmin.com>

Insert an explicit pass to fetch all blobs needed by Git LFS, during the
fetch() function. This avoids the default behavior of Git LFS to wait
until 'git checkout' to begin downloading the blobs pointed to by LFS rec=
ords.
Network access is not allowed at that point in the recipe's lifecycle.

[YOCTO #14191]

(Bitbake rev: 0efac66043662e7a2027192f50e92e982db2ba1c)

Signed-off-by: Matt Hoosier <matt.hoosier@garmin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
bitbake/lib/bb/fetch2/git.py | 44 ++++++++++++++++++++++++++++++++---
bitbake/lib/bb/tests/fetch.py | 28 +++++++++++++++-------
2 files changed, 61 insertions(+), 11 deletions(-)

diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index d255afeb36..7c32eba6c3 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -378,6 +378,35 @@ class Git(FetchMethod):
if missing_rev:
raise bb.fetch2.FetchError("Unable to find revision %s e=
ven from upstream" % missing_rev)
=20
+ if self._contains_lfs(ud, d, ud.clonedir) and self._need_lfs(ud)=
:
+ # Unpack temporary working copy, use it to run 'git checkout=
' to force pre-fetching
+ # of all LFS blobs needed at the the srcrev.
+ #
+ # It would be nice to just do this inline here by running 'g=
it-lfs fetch'
+ # on the bare clonedir, but that operation requires a workin=
g copy on some
+ # releases of Git LFS.
+ tmpdir =3D tempfile.mkdtemp(dir=3Dd.getVar('DL_DIR'))
+ try:
+ # Do the checkout. This implicitly involves a Git LFS fe=
tch.
+ self.unpack(ud, tmpdir, d)
+
+ # Scoop up a copy of any stuff that Git LFS downloaded. =
Merge them into
+ # the bare clonedir.
+ #
+ # As this procedure is invoked repeatedly on incremental=
fetches as
+ # a recipe's SRCREV is bumped throughout its lifetime, t=
his will
+ # result in a gradual accumulation of LFS blobs in <ud.c=
lonedir>/lfs
+ # corresponding to all the blobs reachable from the diff=
erent revs
+ # fetched across time.
+ #
+ # Only do this if the unpack resulted in a .git/lfs dire=
ctory being
+ # created; this only happens if at least one blob needed=
to be
+ # downloaded.
+ if os.path.exists(os.path.join(tmpdir, "git", ".git", "l=
fs")):
+ runfetchcmd("tar -cf - lfs | tar -xf - -C %s" % ud.c=
lonedir, d, workdir=3D"%s/git/.git" % tmpdir)
+ finally:
+ bb.utils.remove(tmpdir, recurse=3DTrue)
+
def build_mirror_data(self, ud, d):
if ud.shallow and ud.write_shallow_tarballs:
if not os.path.exists(ud.fullshallow):
@@ -473,7 +502,7 @@ class Git(FetchMethod):
if os.path.exists(destdir):
bb.utils.prunedir(destdir)
=20
- need_lfs =3D ud.parm.get("lfs", "1") =3D=3D "1"
+ need_lfs =3D self._need_lfs(ud)
=20
if not need_lfs:
ud.basecmd =3D "GIT_LFS_SKIP_SMUDGE=3D1 " + ud.basecmd
@@ -562,6 +591,9 @@ class Git(FetchMethod):
raise bb.fetch2.FetchError("The command '%s' gave output wit=
h more then 1 line unexpectedly, output: '%s'" % (cmd, output))
return output.split()[0] !=3D "0"
=20
+ def _need_lfs(self, ud):
+ return ud.parm.get("lfs", "1") =3D=3D "1"
+
def _contains_lfs(self, ud, d, wd):
"""
Check if the repository has 'lfs' (large file) content
@@ -572,8 +604,14 @@ class Git(FetchMethod):
else:
branchname =3D "master"
=20
- cmd =3D "%s grep lfs origin/%s:.gitattributes | wc -l" % (
- ud.basecmd, ud.branches[ud.names[0]])
+ # The bare clonedir doesn't use the remote names; it has the bra=
nch immediately.
+ if wd =3D=3D ud.clonedir:
+ refname =3D ud.branches[ud.names[0]]
+ else:
+ refname =3D "origin/%s" % ud.branches[ud.names[0]]
+
+ cmd =3D "%s grep lfs %s:.gitattributes | wc -l" % (
+ ud.basecmd, refname)
=20
try:
output =3D runfetchcmd(cmd, d, quiet=3DTrue, workdir=3Dwd)
diff --git a/bitbake/lib/bb/tests/fetch.py b/bitbake/lib/bb/tests/fetch.p=
y
index 4702c99a7e..9453c90d2b 100644
--- a/bitbake/lib/bb/tests/fetch.py
+++ b/bitbake/lib/bb/tests/fetch.py
@@ -2046,13 +2046,14 @@ class GitLfsTest(FetcherTest):
cwd =3D self.gitdir
return bb.process.run(cmd, cwd=3Dcwd)[0]
=20
- def fetch(self, uri=3DNone):
+ def fetch(self, uri=3DNone, download=3DTrue):
uris =3D self.d.getVar('SRC_URI').split()
uri =3D uris[0]
d =3D self.d
=20
fetcher =3D bb.fetch2.Fetch(uris, d)
- fetcher.download()
+ if download:
+ fetcher.download()
ud =3D fetcher.ud[uri]
return fetcher, ud
=20
@@ -2062,16 +2063,21 @@ class GitLfsTest(FetcherTest):
uri =3D 'git://%s;protocol=3Dfile;subdir=3D${S};lfs=3D1' % self.=
srcdir
self.d.setVar('SRC_URI', uri)
=20
- fetcher, ud =3D self.fetch()
+ # Careful: suppress initial attempt at downloading until
+ # we know whether git-lfs is installed.
+ fetcher, ud =3D self.fetch(uri=3DNone, download=3DFalse)
self.assertIsNotNone(ud.method._find_git_lfs)
=20
- # If git-lfs can be found, the unpack should be successful
- ud.method._find_git_lfs =3D lambda d: True
- shutil.rmtree(self.gitdir, ignore_errors=3DTrue)
- fetcher.unpack(self.d.getVar('WORKDIR'))
+ # If git-lfs can be found, the unpack should be successful. Only
+ # attempt this with the real live copy of git-lfs installed.
+ if ud.method._find_git_lfs(self.d):
+ fetcher.download()
+ shutil.rmtree(self.gitdir, ignore_errors=3DTrue)
+ fetcher.unpack(self.d.getVar('WORKDIR'))
=20
# If git-lfs cannot be found, the unpack should throw an error
with self.assertRaises(bb.fetch2.FetchError):
+ fetcher.download()
ud.method._find_git_lfs =3D lambda d: False
shutil.rmtree(self.gitdir, ignore_errors=3DTrue)
fetcher.unpack(self.d.getVar('WORKDIR'))
@@ -2082,10 +2088,16 @@ class GitLfsTest(FetcherTest):
uri =3D 'git://%s;protocol=3Dfile;subdir=3D${S};lfs=3D0' % self.=
srcdir
self.d.setVar('SRC_URI', uri)
=20
+ # In contrast to test_lfs_enabled(), allow the implicit download
+ # done by self.fetch() to occur here. The point of this test cas=
e
+ # is to verify that the fetcher can survive even if the source
+ # repository has Git LFS usage configured.
fetcher, ud =3D self.fetch()
self.assertIsNotNone(ud.method._find_git_lfs)
=20
- # If git-lfs can be found, the unpack should be successful
+ # If git-lfs can be found, the unpack should be successful. A
+ # live copy of git-lfs is not required for this case, so
+ # unconditionally forge its presence.
ud.method._find_git_lfs =3D lambda d: True
shutil.rmtree(self.gitdir, ignore_errors=3DTrue)
fetcher.unpack(self.d.getVar('WORKDIR'))
--=20
2.20.1


[dunfell][PATCH v2 2/3] bitbake: git.py: Use the correct branch to check if the repository has LFS objects.

Mikko Rapeli
 

From: Mauro Queirós <maurofrqueiros@gmail.com>

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.

(Bitbake rev: 4fa67c2af830035a1ddedc14592ee25a15ebff22)

Signed-off-by: Mauro Queiros <maurofrqueiros@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
bitbake/lib/bb/fetch2/git.py | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index 59afc32de1..d255afeb36 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -566,8 +566,15 @@ class Git(FetchMethod):
"""
Check if the repository has 'lfs' (large file) content
"""
- cmd = "%s grep lfs HEAD:.gitattributes | wc -l" % (
- ud.basecmd)
+
+ if not ud.nobranch:
+ branchname = ud.branches[ud.names[0]]
+ else:
+ branchname = "master"
+
+ cmd = "%s grep lfs origin/%s:.gitattributes | wc -l" % (
+ ud.basecmd, ud.branches[ud.names[0]])
+
try:
output = runfetchcmd(cmd, d, quiet=True, workdir=wd)
if int(output) > 0:
--
2.20.1


[dunfell][PATCH v2 1/3] bitbake: git.py: skip smudging if lfs=0 is set

Mikko Rapeli
 

From: Mauro Queirós <maurofrqueiros@gmail.com>

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.

(Bitbake rev: 646d86df7de774255246a3d7051c308e43eb257d)

Signed-off-by: Mauro Queiros <maurofrqueiros@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
bitbake/lib/bb/fetch2/git.py | 3 +++
1 file changed, 3 insertions(+)

diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index dcecff5d38..59afc32de1 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -475,6 +475,9 @@ class Git(FetchMethod):

need_lfs = ud.parm.get("lfs", "1") == "1"

+ if not need_lfs:
+ ud.basecmd = "GIT_LFS_SKIP_SMUDGE=1 " + ud.basecmd
+
source_found = False
source_error = []

--
2.20.1


Re: [OE-core] [dunfell][PATCH 1/2] bitbake: git.py: Use the correct branch to check if the repository has LFS objects.

Mikko Rapeli
 

Sorry, third patch needs to be backported from master for git lfs to work
nicely on dunfell. Will send a v2.

-Mikko


SDKMACHINE and ppc64le issue with latest head?

Andrew Geissler
 

Over in OpenBMC, we utilize a mix of x86 and ppc64le machines for our CI.

Our latest rebase of poky master (https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/39533/) has started failing to compile on our ppc64le machines with the below error.

I can workaround it by setting "SDKMACHINE=x86_64" but that seems a bit weird on a ppc64le machine?

+ bitbake obmc-phosphor-image obmc-phosphor-debug-tarball
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
    Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
    Following is the list of potential problems / advisories:

    Specified SDKMACHINE value is not valid


[dunfell][PATCH 2/2] bitbake: fetch/git: download LFS content too during do_fetch

Mikko Rapeli
 

From: Matt Hoosier <matt.hoosier@garmin.com>

Insert an explicit pass to fetch all blobs needed by Git LFS, during the
fetch() function. This avoids the default behavior of Git LFS to wait
until 'git checkout' to begin downloading the blobs pointed to by LFS rec=
ords.
Network access is not allowed at that point in the recipe's lifecycle.

[YOCTO #14191]

(Bitbake rev: 0efac66043662e7a2027192f50e92e982db2ba1c)

Signed-off-by: Matt Hoosier <matt.hoosier@garmin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
bitbake/lib/bb/fetch2/git.py | 44 ++++++++++++++++++++++++++++++++---
bitbake/lib/bb/tests/fetch.py | 28 +++++++++++++++-------
2 files changed, 61 insertions(+), 11 deletions(-)

diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index fc14192e24..85c45d4dd4 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -378,6 +378,35 @@ class Git(FetchMethod):
if missing_rev:
raise bb.fetch2.FetchError("Unable to find revision %s e=
ven from upstream" % missing_rev)
=20
+ if self._contains_lfs(ud, d, ud.clonedir) and self._need_lfs(ud)=
:
+ # Unpack temporary working copy, use it to run 'git checkout=
' to force pre-fetching
+ # of all LFS blobs needed at the the srcrev.
+ #
+ # It would be nice to just do this inline here by running 'g=
it-lfs fetch'
+ # on the bare clonedir, but that operation requires a workin=
g copy on some
+ # releases of Git LFS.
+ tmpdir =3D tempfile.mkdtemp(dir=3Dd.getVar('DL_DIR'))
+ try:
+ # Do the checkout. This implicitly involves a Git LFS fe=
tch.
+ self.unpack(ud, tmpdir, d)
+
+ # Scoop up a copy of any stuff that Git LFS downloaded. =
Merge them into
+ # the bare clonedir.
+ #
+ # As this procedure is invoked repeatedly on incremental=
fetches as
+ # a recipe's SRCREV is bumped throughout its lifetime, t=
his will
+ # result in a gradual accumulation of LFS blobs in <ud.c=
lonedir>/lfs
+ # corresponding to all the blobs reachable from the diff=
erent revs
+ # fetched across time.
+ #
+ # Only do this if the unpack resulted in a .git/lfs dire=
ctory being
+ # created; this only happens if at least one blob needed=
to be
+ # downloaded.
+ if os.path.exists(os.path.join(tmpdir, "git", ".git", "l=
fs")):
+ runfetchcmd("tar -cf - lfs | tar -xf - -C %s" % ud.c=
lonedir, d, workdir=3D"%s/git/.git" % tmpdir)
+ finally:
+ bb.utils.remove(tmpdir, recurse=3DTrue)
+
def build_mirror_data(self, ud, d):
if ud.shallow and ud.write_shallow_tarballs:
if not os.path.exists(ud.fullshallow):
@@ -473,7 +502,7 @@ class Git(FetchMethod):
if os.path.exists(destdir):
bb.utils.prunedir(destdir)
=20
- need_lfs =3D ud.parm.get("lfs", "1") =3D=3D "1"
+ need_lfs =3D self._need_lfs(ud)
=20
source_found =3D False
source_error =3D []
@@ -559,6 +588,9 @@ class Git(FetchMethod):
raise bb.fetch2.FetchError("The command '%s' gave output wit=
h more then 1 line unexpectedly, output: '%s'" % (cmd, output))
return output.split()[0] !=3D "0"
=20
+ def _need_lfs(self, ud):
+ return ud.parm.get("lfs", "1") =3D=3D "1"
+
def _contains_lfs(self, ud, d, wd):
"""
Check if the repository has 'lfs' (large file) content
@@ -569,8 +601,14 @@ class Git(FetchMethod):
else:
branchname =3D "master"
=20
- cmd =3D "%s grep lfs origin/%s:.gitattributes | wc -l" % (
- ud.basecmd, ud.branches[ud.names[0]])
+ # The bare clonedir doesn't use the remote names; it has the bra=
nch immediately.
+ if wd =3D=3D ud.clonedir:
+ refname =3D ud.branches[ud.names[0]]
+ else:
+ refname =3D "origin/%s" % ud.branches[ud.names[0]]
+
+ cmd =3D "%s grep lfs %s:.gitattributes | wc -l" % (
+ ud.basecmd, refname)
=20
try:
output =3D runfetchcmd(cmd, d, quiet=3DTrue, workdir=3Dwd)
diff --git a/bitbake/lib/bb/tests/fetch.py b/bitbake/lib/bb/tests/fetch.p=
y
index 4702c99a7e..9453c90d2b 100644
--- a/bitbake/lib/bb/tests/fetch.py
+++ b/bitbake/lib/bb/tests/fetch.py
@@ -2046,13 +2046,14 @@ class GitLfsTest(FetcherTest):
cwd =3D self.gitdir
return bb.process.run(cmd, cwd=3Dcwd)[0]
=20
- def fetch(self, uri=3DNone):
+ def fetch(self, uri=3DNone, download=3DTrue):
uris =3D self.d.getVar('SRC_URI').split()
uri =3D uris[0]
d =3D self.d
=20
fetcher =3D bb.fetch2.Fetch(uris, d)
- fetcher.download()
+ if download:
+ fetcher.download()
ud =3D fetcher.ud[uri]
return fetcher, ud
=20
@@ -2062,16 +2063,21 @@ class GitLfsTest(FetcherTest):
uri =3D 'git://%s;protocol=3Dfile;subdir=3D${S};lfs=3D1' % self.=
srcdir
self.d.setVar('SRC_URI', uri)
=20
- fetcher, ud =3D self.fetch()
+ # Careful: suppress initial attempt at downloading until
+ # we know whether git-lfs is installed.
+ fetcher, ud =3D self.fetch(uri=3DNone, download=3DFalse)
self.assertIsNotNone(ud.method._find_git_lfs)
=20
- # If git-lfs can be found, the unpack should be successful
- ud.method._find_git_lfs =3D lambda d: True
- shutil.rmtree(self.gitdir, ignore_errors=3DTrue)
- fetcher.unpack(self.d.getVar('WORKDIR'))
+ # If git-lfs can be found, the unpack should be successful. Only
+ # attempt this with the real live copy of git-lfs installed.
+ if ud.method._find_git_lfs(self.d):
+ fetcher.download()
+ shutil.rmtree(self.gitdir, ignore_errors=3DTrue)
+ fetcher.unpack(self.d.getVar('WORKDIR'))
=20
# If git-lfs cannot be found, the unpack should throw an error
with self.assertRaises(bb.fetch2.FetchError):
+ fetcher.download()
ud.method._find_git_lfs =3D lambda d: False
shutil.rmtree(self.gitdir, ignore_errors=3DTrue)
fetcher.unpack(self.d.getVar('WORKDIR'))
@@ -2082,10 +2088,16 @@ class GitLfsTest(FetcherTest):
uri =3D 'git://%s;protocol=3Dfile;subdir=3D${S};lfs=3D0' % self.=
srcdir
self.d.setVar('SRC_URI', uri)
=20
+ # In contrast to test_lfs_enabled(), allow the implicit download
+ # done by self.fetch() to occur here. The point of this test cas=
e
+ # is to verify that the fetcher can survive even if the source
+ # repository has Git LFS usage configured.
fetcher, ud =3D self.fetch()
self.assertIsNotNone(ud.method._find_git_lfs)
=20
- # If git-lfs can be found, the unpack should be successful
+ # If git-lfs can be found, the unpack should be successful. A
+ # live copy of git-lfs is not required for this case, so
+ # unconditionally forge its presence.
ud.method._find_git_lfs =3D lambda d: True
shutil.rmtree(self.gitdir, ignore_errors=3DTrue)
fetcher.unpack(self.d.getVar('WORKDIR'))
--=20
2.20.1


[dunfell][PATCH 1/2] bitbake: git.py: Use the correct branch to check if the repository has LFS objects.

Mikko Rapeli
 

From: Mauro Queirós <maurofrqueiros@gmail.com>

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.

(Bitbake rev: 4fa67c2af830035a1ddedc14592ee25a15ebff22)

Signed-off-by: Mauro Queiros <maurofrqueiros@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
bitbake/lib/bb/fetch2/git.py | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index dcecff5d38..fc14192e24 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -563,8 +563,15 @@ class Git(FetchMethod):
"""
Check if the repository has 'lfs' (large file) content
"""
- cmd = "%s grep lfs HEAD:.gitattributes | wc -l" % (
- ud.basecmd)
+
+ if not ud.nobranch:
+ branchname = ud.branches[ud.names[0]]
+ else:
+ branchname = "master"
+
+ cmd = "%s grep lfs origin/%s:.gitattributes | wc -l" % (
+ ud.basecmd, ud.branches[ud.names[0]])
+
try:
output = runfetchcmd(cmd, d, quiet=True, workdir=wd)
if int(output) > 0:
--
2.20.1


Re: git lfs not working in dunfell

Richard Purdie
 

On Thu, 2021-01-28 at 16:18 +0100, Marek Belisko wrote:
Hi,

I have repo where I'm using lfs. I've added to my SRC_URI =
"git://...... ;lfs=1" and the project is fetched but the issue is that
lfs files are shown as references only (content is not fetched).
I briefly checked git fetcher in bitbake and seems it checks that repo
have lfs content but I cannot see anywhere git lfs pull to actually
pull lfs content. Am I missing something? When checked poky master it
looks like proper fetching is in place. Is there any way how to get it
to dunfell LTS release? Thanks.
There is a patch in bitbake master related to this which you may want
to test and maybe request for adding to dunfell if it helps.

https://git.openembedded.org/bitbake/commit/?id=0efac66043662e7a2027192f50e92e982db2ba1c

Cheers,

Richard

2661 - 2680 of 54795