
Randy MacLeod
On 2022-01-04 10:00, staticd wrote: One final update for anyone who might run into this problem. With all of my fiddling/twiddling I failed to get libquadmath to build under the `zeus` branch. Unfortunately, my other layer dependencies only support `zeus` so it seems I will have to wait until they support a branch that can build `libquadmath`. I am fairly certain there is just a simple mistake somewhere but, alas, I have been unable to find where that is. Hi, If you can come up with a reasonably simple reproducer and it fails on a supported branch: https://wiki.yoctoproject.org/wiki/Releasesthen we'd appreciate if if you could report the bug in the YP Bugzilla: https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_TrackingDon't worry too much about getting every field right if you aren't familiar with the overall project. There's no guarantee that we'll get someone to work on it but at least it's tracked and we might get to it at some point. ../Randy On Mon, Jan 3, 2022 at 4:55 PM staticd <staticd@... <mailto:staticd@...>> wrote: I made some progress... It turns out that libquadmath is failing to build. When I goto the `build/tmp/work/...../gcc-runtime/9.2.0-r0/gcc-9.2.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/arm-oe-linux-gnueabi/libquadmath` directory, the only files that are there are: ``` libquadmath ] ls -l total 476 -rw-r--r--. 1 2017 oe-builder 4433 Jan 3 16:17 config.h -rw-r--r--. 1 2017 oe-builder 69297 Jan 3 16:17 config.log -rwxr-xr-x. 1 2017 oe-builder 77122 Jan 3 16:17 config.status -rwxr-xr-x. 1 2017 oe-builder 267083 Jan 3 16:17 libtool -rw-r--r--. 1 2017 oe-builder 57241 Jan 3 16:17 Makefile -rw-r--r--. 1 2017 oe-builder 23 Jan 3 16:17 stamp-h1 ``` In the config.log, there are errors, some of which are expected, but still: ``` libquadmath ] grep -i error config.log arm-oe-linux-gnueabi-gcc: error: unrecognized command line option '-V' arm-oe-linux-gnueabi-gcc: fatal error: no input files arm-oe-linux-gnueabi-gcc: error: unrecognized command line option '-qversion'; did you mean '--version'? arm-oe-linux-gnueabi-gcc: fatal error: no input files conftest.c:11:10: fatal error: ac_nonexistent.h: No such file or directory arm-oe-linux-gnueabi-gcc: error: unrecognized command line option '-V' arm-oe-linux-gnueabi-gcc: fatal error: no input files arm-oe-linux-gnueabi-gcc: error: unrecognized command line option '-qversion'; did you mean '--version'? arm-oe-linux-gnueabi-gcc: fatal error: no input files conftest.c:28:10: fatal error: ac_nonexistent.h: No such file or directory configure:12551: arm-oe-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 --sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/gcc-runtime/9.2.0-r0/recipe-sysroot -c -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/gcc-runtime/9.2.0-r0/recipe-sysroot= -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/gcc-runtime/9.2.0-r0/recipe-sysroot-native= -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work-shared/gcc-9.2.0-r0/gcc-9.2.0=/usr/src/debug/gcc-runtime/9.2.0-r0 -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work-shared/gcc-9.2.0-r0/gcc-9.2.0/include=/usr/src/debug/gcc-runtime/9.2.0-r0/libstdc++-v3/../include -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work-shared/gcc-9.2.0-r0/gcc-9.2.0/libiberty=/usr/src/debug/gcc-runtime/9.2.0-r0/libstdc++-v3/../libiberty -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/gcc-runtime/9.2.0-r0/gcc-9.2.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi=/usr/src/debug/gcc-runtime/9.2.0-r0 -Werror conftest.c >&5 glibcxx_cv_system_error10=yes glibcxx_cv_system_error11=yes glibcxx_cv_system_error12=yes glibcxx_cv_system_error13=yes glibcxx_cv_system_error14=yes glibcxx_cv_system_error15=yes glibcxx_cv_system_error16=yes glibcxx_cv_system_error17=yes glibcxx_cv_system_error18=yes glibcxx_cv_system_error19=yes glibcxx_cv_system_error1=yes glibcxx_cv_system_error2=yes glibcxx_cv_system_error3=yes glibcxx_cv_system_error4=yes glibcxx_cv_system_error5=yes glibcxx_cv_system_error6=yes glibcxx_cv_system_error7=yes glibcxx_cv_system_error8=yes glibcxx_cv_system_error9=yes ``` If I check out another library that I expect to get, like, `libitm`, I see: ``` libquadmath ] ls -trl ../libitm/ total 2872 -rwxr-xr-x. 1 2017 oe-builder 97435 Jan 3 16:17 config.status -rw-r--r--. 1 2017 oe-builder 47665 Jan 3 16:17 Makefile drwxr-xr-x. 2 2017 oe-builder 22 Jan 3 16:17 testsuite -rw-r--r--. 1 2017 oe-builder 162 Jan 3 16:17 libitm.spec -rw-r--r--. 1 2017 oe-builder 5251 Jan 3 16:17 config.h -rw-r--r--. 1 2017 oe-builder 23 Jan 3 16:17 stamp-h1 -rwxr-xr-x. 1 2017 oe-builder 274850 Jan 3 16:17 libtool -rw-r--r--. 1 2017 oe-builder 868 Jan 3 16:17 gstdint.h -rw-r--r--. 1 2017 oe-builder 119521 Jan 3 16:17 config.log -rw-r--r--. 1 2017 oe-builder 50080 Jan 3 16:18 alloc_c.o ... -rw-r--r--. 1 2017 oe-builder 931 Jan 3 16:18 libitm.la <http://libitm.la> ``` Have you seen something like this before? I am not sure how to fix this... Any help is greatly appreciated. On Sun, Jan 2, 2022 at 5:13 PM staticd via lists.yoctoproject.org <http://lists.yoctoproject.org> <staticd=gmail.com@... <mailto:gmail.com@...>> wrote: So, I built the latest poky and created the example recipe with the `DEPENDS` from my recipe and indeed, I see `libquadmath.so <http://libquadmath.so>` in `sysroots-components/`. I am really scratching my head now. I must be missing something silly somewhere... My build environment is running `zeus` and the latest `poky` I grabbed is `honister` Perhaps something changed that I am just overlooking somehow. On Sun, Jan 2, 2022 at 2:18 PM staticd via lists.yoctoproject.org <http://lists.yoctoproject.org> <staticd=gmail.com@... <mailto:gmail.com@...>> wrote: Thank you, Konrad. I have tried both of the approaches (local.conf and gcc-runtime_%.bbappend/gcc_%.bbappend), still `libquadmath.so <http://libquadmath.so>` is not being built. I will keep fiddling but I think we are onto something. The interesting thing I found is that `libquadmath.so <http://libquadmath.so>` IS being built for the nativesdk but NOT when I add `DEPENDS = "virtual/${TARGET_PREFIX}compillerlibs"` to my recipe. Perhaps, because `FORTRAN = ""` is in the gcc_%.bb, maybe that should be something less strict? I might be screwing up my bbappend too... My append is in `meta-mylayer/recipes-devtools/gcc/gcc-runtime_%.bbappend` Which is mapped correctly to $BBFILES n my layers `layer.conf` On Sun, Jan 2, 2022 at 2:07 PM Konrad Weihmann <kweihmann@... <mailto:kweihmann@...>> wrote: The following I just found in local.conf.sample.extended # Enabling FORTRAN # Note this is not officially supported and is just illustrated here to # show an example of how it can be done # You'll also need your fortran recipe to depend on libgfortran FORTRAN:forcevariable = ",fortran" guess that will solve your issue without the need for a bbappend. Just inject that line via distro or local.conf On 02.01.22 18:31, staticd wrote: > I think to clarify...what I need are these files: > > --- snipped from gcc-runtime.inc --- > ``` > FILES_libquadmath = "${libdir}/libquadmath*.so.*" > SUMMARY_libquadmath = "GNU quad-precision math library" > FILES_libquadmath-dev = "\ > ${libdir}/${TARGET_SYS}/${BINV}/include/quadmath* \ > ${libdir}/libquadmath*.so \ > ${libdir}/libquadmath.la <http://libquadmath.la> <http://libquadmath.la <http://libquadmath.la>> \ > " > ``` > --- > to be in my $STAGING_LIBDIR > > So far, I have been unable to figure out how to do that, unfortunately. > > On Sun, Jan 2, 2022 at 12:23 PM staticd <staticd@... <mailto:staticd@...> > <mailto:staticd@... <mailto:staticd@...>>> wrote: > > Thank you, Michael. > > I have `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"` > > and `do_compile[depends] += > "virtual/arm-oe-linux-gnueabi-compilerlibs:do_check"` > > However, libquadmath.so <http://libquadmath.so> is still not present in `recipe-sysroot/lib` > > I used the `do_check` task from gcc_runtime but that still isn't > providing `libquadmath.so <http://libquadmath.so>` in my $STAGING_LIBDIR, which is where I > need it. > > Many thanks. > > On Sun, Jan 2, 2022 at 12:17 PM Michael Ho <michael.ho@... <mailto:michael.ho@...> > <mailto:michael.ho@... <mailto:michael.ho@...>>> wrote: > > Not familiar with Fortran but maybe it helps to know that this > is normally handled with the DEPENDS mechanism. When you add > other recipes as dependencies to your recipe, the task > do_prepare_recipe_sysroot (run before do_compile) will make hard > links to the files from those dependency recipes into that > recipe-sysroot directory. > > See: > https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot <https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot> > <https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot <https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot>> > > Kind regards, > Michael > > On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@... <mailto:staticd@...> > <mailto:staticd@... <mailto:staticd@...>>> wrote: > > okay...I think I have a more interesting question now... > > In the package I am building I have some Fortran code that > requires `libquadmath` > > I see that `gcc-runtime` provides the library but I need the > library present in `recipe-sysroot/lib` when my `do_compile` > runs > > Is there a way for me to do that? > > My current approach is to build my image, copy the > libraries/includes to my recipe and `install` them in > `recipe-sysroot` before `do_compile` > > This doesn't seem like the correct approach but I am not > sure how else to do it at this point > > Any help would be greatly appreciated. > > > > > > >
-- # Randy MacLeod # Wind River Linux
|
|
Re: Preferred provide base-utils issue
Paul van Berlo <pvanberlo@...>
Hi,
Adding that line results in an error:
The kernel panic ends with "not syncing: Attempted to kill init! exitcode=0x00000100". This is using the genericx86-64 machine.
Regards,
Paul van Berlo
toggle quoted message
Show quoted text
On 2022-01-26 11:17, Paul van Berlo wrote:
> Hello,
>
> so I'm a bit at a loss. I admit, I've not yet been using Yocto for a
> long time. I'm trying to use base-utils as provided by
> packagegroup-core-base-utils to have a more full featured set of base
> utils instead of busybox. It all builds just fine, however, whatever I
> do (using dunfell), it ends up with a kernel panic during boot.
>
> I added the following to local.conf on a clean clone of poky:
>
> INIT_MANAGER="systemd"
>
> IMAGE_FSTYPES="live"
>
> PREFERRED_PROVIDER_base-utils = "packagegroup-core-base-utils"
> VIRTUAL-RUNTIME_base-utils = "packagegroup-core-base-utils"
> VIRTUAL-RUNTIME_base-utils-hwclock = "util-linux-hwclock"
> VIRTUAL-RUNTIME_base-utils-syslog = ""
Hi Paul,
Try adding:
VIRTUAL-RUNTIME_base-utils-syslog = "syslog"
as shown on:
https://git.yoctoproject.org/poky/tree/meta-poky/conf/local.conf.sample.extended#n371
I would expect that since you have systemd, you'd have the systemd
journal as well so
you wouldn't need syslog but it would be good to do a sanity check.
If that doesn't help, show us what the kernel panic is saying.
Is this with a custom BSP and if so can you reproduce with qemux86-64?
Try the same things using poky on the master branch if you can.
../Randy
>
> Does anyone have any idea how to get this to work?
>
> Regards,
>
> Paul van Berlo
>
>
>
--
# Randy MacLeod
# Wind River Linux
|
|
Re: Preferred provide base-utils issue

Randy MacLeod
On 2022-01-26 11:17, Paul van Berlo wrote: Hello,
so I'm a bit at a loss. I admit, I've not yet been using Yocto for a long time. I'm trying to use base-utils as provided by packagegroup-core-base-utils to have a more full featured set of base utils instead of busybox. It all builds just fine, however, whatever I do (using dunfell), it ends up with a kernel panic during boot.
I added the following to local.conf on a clean clone of poky:
INIT_MANAGER="systemd"
IMAGE_FSTYPES="live"
PREFERRED_PROVIDER_base-utils = "packagegroup-core-base-utils" VIRTUAL-RUNTIME_base-utils = "packagegroup-core-base-utils" VIRTUAL-RUNTIME_base-utils-hwclock = "util-linux-hwclock" VIRTUAL-RUNTIME_base-utils-syslog = "" Hi Paul, Try adding: VIRTUAL-RUNTIME_base-utils-syslog = "syslog" as shown on: https://git.yoctoproject.org/poky/tree/meta-poky/conf/local.conf.sample.extended#n371I would expect that since you have systemd, you'd have the systemd journal as well so you wouldn't need syslog but it would be good to do a sanity check. If that doesn't help, show us what the kernel panic is saying. Is this with a custom BSP and if so can you reproduce with qemux86-64? Try the same things using poky on the master branch if you can. ../Randy Does anyone have any idea how to get this to work?
Regards,
Paul van Berlo
-- # Randy MacLeod # Wind River Linux
|
|
Re: Fetch private gitlab repo using ssh with Yocto recipe
#bitbake

Khem Raj
On Fri, Jan 28, 2022 at 2:27 AM VIVAVIS AG <embedded@...> wrote: Hi,
Von: yocto@... <yocto@...> Im Auftrag von Sourabh Hegde Gesendet: Freitag, 28. Januar 2022 10:47
Can you please let me know how to "forward SSH_AGENT into it to be able to fetch from internal projects without the need to mount the key into the container."? I never did that before. I use the following options within the Docker run command: -v $SSH_AUTH_SOCK:/ssh.socket \ -e SSH_AUTH_SOCK=/ssh.socket \
Furthermore, I had to mount the .ssh folder into the container to make it working (be aware of security risk). Additionally, you should check that uid, gid of the user in the container is the same on the host.
yeah something like that works, we use it for yoe which always uses container to build see https://github.com/YoeDistro/yoe-distro/blob/master/envsetup.sh#L528-L541Regards,
Carsten
|
|
Re: Custom SDK generation from YoctoSDK
#sdk

Randy MacLeod
On 2022-01-28 12:02, Randy MacLeod
wrote:
On 2022-01-24 13:04, Praveen wrote:
I am looking for Custom SDK with filtered Header
files/libraries based on some rules/approvals. It means not
all files from YoctoSDK will be packaged in the CustomSDK.
What is the mechanism or approach where we can pull only
those approved header files & libraries from YoctoSDK and
package as Customized SDK tar?
Is there a way we can fetch those approved header files
from YOCTO SDK and filter it?
I am thinking like creating subset versioned module recipe and
specify those approved header files and package only those
files. Is there any better mechanism on packaging or filtering
the SDK based on some rules to filter some header files?
Like for example in YoctoSDK, we have 2 modules
moduleA (A1.h, A2.h,A3.h and libA.so),
moduleB (B1.h, B2.h, B3.h and libB.so)
Lets say A3.h & B3.h are not
approved in my Custom SDK, then in final Customer SDK we
will only package
moduleA (A1.h, A2.h and libA.so), moduleB (B1.h, B2.h,
and libB.so)
I want to keep YoctoSDK
without any filters, so that A3.h/B3.h can be used for
internal purposes without any issue.
Hi Praveen,
I'm not aware of anyone else doing that.
For libraries/recipes, you could just omit certain packages
from the eSDK but you don't seem to want to do that.
What is your goal in filtering headers and libraries rather
than say generating two SDKs:
one that is unrestricted and the other with limited APIs ?
That is, can you not package each moduleA as moduleA and
moduleA-private using Yocto's packaging
mechanism with the *3.h files being in the private packages?
I don't work with the SDK very much so I could be out in left
field but
if I am, hopefully someone will reply and straighten us both out!
../Randy
../Randy
--
# Randy MacLeod
# Wind River Linux
--
# Randy MacLeod
# Wind River Linux
|
|
Re: Custom SDK generation from YoctoSDK
#sdk

Randy MacLeod
On 2022-01-24 13:04, Praveen wrote:
I am looking for Custom SDK with filtered Header
files/libraries based on some rules/approvals. It means not
all files from YoctoSDK will be packaged in the CustomSDK.
What is the mechanism or approach where we can pull only
those approved header files & libraries from YoctoSDK and
package as Customized SDK tar?
Is there a way we can fetch those approved header files from
YOCTO SDK and filter it?
I am thinking like creating subset versioned module recipe and
specify those approved header files and package only those
files. Is there any better mechanism on packaging or filtering
the SDK based on some rules to filter some header files?
Like for example in YoctoSDK, we have 2 modules moduleA (A1.h,
A2.h,A3.h and libA.so), moduleB (B1.h,
B2.h, B3.h and libB.so)
Lets say A3.h & B3.h are not
approved in my Custom SDK, then in final Customer SDK we will
only package
moduleA (A1.h, A2.h and libA.so), moduleB (B1.h, B2.h,
and libB.so)
I want to keep YoctoSDK
without any filters, so that A3.h/B3.h can be used for
internal purposes without any issue.
Hi Praveen,
I'm not aware of anyone else doing that.
For libraries/recipes, you could just omit certain packages from
the eSDK but you don't seem to want to do that.
What is your goal in filtering headers and libraries rather than
say generating two SDKs:
one that is unrestricted and the other with limited APIs ?
../Randy
--
# Randy MacLeod
# Wind River Linux
|
|
Re: Fetch private gitlab repo using ssh with Yocto recipe
#bitbake
On Fri, Jan 28, 2022 at 11:50 AM Nicolas Jeker <n.jeker@...> wrote: On Fri, 2022-01-28 at 10:27 +0000, VIVAVIS AG wrote:
Hi,
Von: yocto@... <yocto@...> Im Auftrag von Sourabh Hegde Gesendet: Freitag, 28. Januar 2022 10:47
Can you please let me know how to "forward SSH_AGENT into it to be able to fetch from internal projects without the need to mount the key into the container."? I never did that before. I use the following options within the Docker run command: -v $SSH_AUTH_SOCK:/ssh.socket \ -e SSH_AUTH_SOCK=/ssh.socket \
That's pretty much what I use.
Furthermore, I had to mount the .ssh folder into the container to make it working (be aware of security risk). Additionally, you should check that uid, gid of the user in the container is the same on the host. I do something similar, my "problem" was that ssh needs the .ssh/known_hosts file with a matching entry in addition to your key/agent, but mounting the .ssh folder was not possible for me because of permissions. Currently, I just created a little script that wraps "oe-init-build-env" and populates the known_hosts file accordingly.
mkdir -p ~/.ssh
cat <<EOF >> ~/.ssh/known_hosts git.example.com ssh-ed25519 <base64key> EOF
I use my own Dockerfile based on crops/poky where I do the following, which might be helpful if you also use this. It sets up the config changes in /etc/skel/ since it creates users "on the fly" with matching uid. # Remove strict host key checking for ssh # This is needed since the build will pull source over git-ssh RUN mkdir -p /etc/skel/.ssh/ COPY ci-scripts/docker-stuff/config /etc/skel/.ssh/ RUN echo 'export GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"' >> /etc/skel/.bashrc The ci-scripts/docker-stuff/config file contains: Host * StrictHostKeyChecking no UserKnownHostsFile=/dev/null Now it was ages ago I set this up, and right now I can't really understand why I basically do the same thing twice. So you'd have to check which of the two things that actually solves the issue :-) Cheers, Erik Regards,
Carsten
|
|
Re: Fetch private gitlab repo using ssh with Yocto recipe
#bitbake
On Fri, 2022-01-28 at 10:27 +0000, VIVAVIS AG wrote: Hi,
Von: yocto@... <yocto@...> Im Auftrag von Sourabh Hegde Gesendet: Freitag, 28. Januar 2022 10:47
Can you please let me know how to "forward SSH_AGENT into it to be able to fetch from internal projects without the need to mount the key into the container."? I never did that before. I use the following options within the Docker run command: -v $SSH_AUTH_SOCK:/ssh.socket \ -e SSH_AUTH_SOCK=/ssh.socket \
That's pretty much what I use. Furthermore, I had to mount the .ssh folder into the container to make it working (be aware of security risk). Additionally, you should check that uid, gid of the user in the container is the same on the host. I do something similar, my "problem" was that ssh needs the .ssh/known_hosts file with a matching entry in addition to your key/agent, but mounting the .ssh folder was not possible for me because of permissions. Currently, I just created a little script that wraps "oe-init-build-env" and populates the known_hosts file accordingly. mkdir -p ~/.ssh cat <<EOF >> ~/.ssh/known_hosts git.example.com ssh-ed25519 <base64key> EOF Regards,
Carsten
|
|
Re: Fetch private gitlab repo using ssh with Yocto recipe
#bitbake
Hi, Von: yocto@... <yocto@...> Im Auftrag von Sourabh Hegde Gesendet: Freitag, 28. Januar 2022 10:47
Can you please let me know how to "forward SSH_AGENT into it to be able to fetch from internal projects without the need to mount the key into the container."? I never did that before. I use the following options within the Docker run command: -v $SSH_AUTH_SOCK:/ssh.socket \ -e SSH_AUTH_SOCK=/ssh.socket \ Furthermore, I had to mount the .ssh folder into the container to make it working (be aware of security risk). Additionally, you should check that uid, gid of the user in the container is the same on the host. Regards, Carsten
|
|
Re: Fetch private gitlab repo using ssh with Yocto recipe
#bitbake
Hi Nicolas,
Thanks for your answer.
That's great. Even I am building inside a docker container. I tried with creating a "config" file in .ssh directory. But I still have same issue.
Can you please let me know how to "forward SSH_AGENT into it to be able to fetch from internal projects without the need to mount the key into the container."? I never did that before.
Thanks in advance.
toggle quoted message
Show quoted text
On Fri, Jan 28, 2022, 10:42 Nicolas Jeker < n.jeker@...> wrote: On Tue, 2022-01-25 at 23:16 -0800, hrsourabh011@... wrote:
> I am trying to fetch a private gitlab repo within Yocto image recipe
> using SSH protocol. In my image recipe I have passed SRC_URI as:
>
> SRC_URI = " \
> gitsm://git@...:2224/blah/blah/blah/blah;protocol
> =ssh;branch=master \
> "
I use almost the same, just without submodules.
SRC_URI =
"git://git@...:1234/group/project.git;protocol=ssh"
It should "just work" if ssh is able to find your key. I often build in
a docker container, so I have to forward SSH_AGENT into it to be able
to fetch from internal projects without the need to mount the key into
the container. I don't really have any insight for builds outside
docker, if git clone works, the bitbake fetcher should too.
> But this results in the error:
>
<snip>
>
> But I am able to clone the repo using git clone.
> SSH key is already added to the Gitlab. There is no config file in my
> ~/.ssh. Do I need to create a config file? What should be the content
> of the config file?
You should not need a ssh config file.
> Can anyone please let me know how to resolve this?
> Thanks in advance.
|
|
Re: Fetch private gitlab repo using ssh with Yocto recipe
#bitbake
On Tue, 2022-01-25 at 23:16 -0800, hrsourabh011@... wrote: I am trying to fetch a private gitlab repo within Yocto image recipe using SSH protocol. In my image recipe I have passed SRC_URI as:
SRC_URI = " \ gitsm://git@...:2224/blah/blah/blah/blah;protocol =ssh;branch=master \ " I use almost the same, just without submodules. SRC_URI = "git://git@...:1234/group/project.git;protocol=ssh" It should "just work" if ssh is able to find your key. I often build in a docker container, so I have to forward SSH_AGENT into it to be able to fetch from internal projects without the need to mount the key into the container. I don't really have any insight for builds outside docker, if git clone works, the bitbake fetcher should too. But this results in the error:
<snip> But I am able to clone the repo using git clone. SSH key is already added to the Gitlab. There is no config file in my ~/.ssh. Do I need to create a config file? What should be the content of the config file?
You should not need a ssh config file. Can anyone please let me know how to resolve this? Thanks in advance.
|
|
Re: [meta-lts-mixins][dunfell/go PATCH 1/4] Initial commit: add license, readme and layer config.
On Thu, 27 Jan 2022 at 22:04, Khem Raj < raj.khem@...> wrote:
On Thu, Jan 27, 2022 at 12:06 PM Denys Dmytriyenko < denis@...> wrote: On Thu, Jan 27, 2022 at 06:07:06PM +0100, Alexander Kanavin wrote:
> A question specifically to Denys, how can I actually get this into the
> mixin repo, and have commit rights to the branch? We've tested this quite
> well in private, and there are further enhancements coming up.
Michael,
Would it be possible to create 2 additional branches in the meta-lts-mixins
repository at https://git.yoctoproject.org/meta-lts-mixins/ called
"dunfell/go" and also "dunfell/docker" and give Alex push rights to them?
How would one use new version of both go and say kernel in a project
Checkout the branches from the same repo into two different directories. Yes this is unusual, and slightly confusing. But that way the branches can be maintained and included into builds independently.
Alex
Please let us know, thanks a lot!
--
Denys
> On Thu, 27 Jan 2022 at 15:43, Alexander Kanavin via lists.yoctoproject.org
> <alex.kanavin=gmail.com@...> wrote:
>
> > Reviewed-by: Martin Kaistra <martin.kaistra@...>
> > Signed-off-by: Alexander Kanavin <alex@...>
> > ---
> > COPYING.MIT | 17 +++++++++++++++++
> > README | 23 +++++++++++++++++++++++
> > conf/layer.conf | 19 +++++++++++++++++++
> > 3 files changed, 59 insertions(+)
> > create mode 100644 COPYING.MIT
> > create mode 100644 README
> > create mode 100644 conf/layer.conf
> >
> > diff --git a/COPYING.MIT b/COPYING.MIT
> > new file mode 100644
> > index 0000000..fb950dc
> > --- /dev/null
> > +++ b/COPYING.MIT
> > @@ -0,0 +1,17 @@
> > +Permission is hereby granted, free of charge, to any person obtaining a
> > copy
> > +of this software and associated documentation files (the "Software"), to
> > deal
> > +in the Software without restriction, including without limitation the
> > rights
> > +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> > +copies of the Software, and to permit persons to whom the Software is
> > +furnished to do so, subject to the following conditions:
> > +
> > +The above copyright notice and this permission notice shall be included
> > in
> > +all copies or substantial portions of the Software.
> > +
> > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > OR
> > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> > THE
> > +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > FROM,
> > +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> > +THE SOFTWARE.
> > diff --git a/README b/README
> > new file mode 100644
> > index 0000000..5b22b72
> > --- /dev/null
> > +++ b/README
> > @@ -0,0 +1,23 @@
> > +"Mixin" layer for adding latest Go toolchain versions into the Yocto
> > Project LTS.
> > +
> > +At the time Dunfell was released in April 2020, Go 1.14 was the latest
> > version
> > +and officially Dunfell supports only that. This thin special-purpose mixin
> > +layer is meant to address this issue by backporting Go recipes from the
> > master
> > +branch of openembedded-core.
> > +
> > +You can see what Go versions are provided by listing recipes-devtools/
> > content.
> > +
> > +Including the layer automatically picks up the latest Go version;
> > different versions
> > +need to be set explicitly by adding the following line to your distro
> > config
> > +or local.conf:
> > +
> > +GOVERSION = "1.16%"
> > +
> > +Please note: enabling these newer Go versions makes docker from dunfell
> > branch
> > +of meta-virtualization unbuildable as it is too old. If you need a
> > working docker
> > +recipe, you can use the supplementary 'dunfell/docker' layer from this
> > meta-lts-mixin
> > +repository.
> > +
> > +
> > +Maintainers:
> > +Alexander Kanavin <alex@...>
> > diff --git a/conf/layer.conf b/conf/layer.conf
> > new file mode 100644
> > index 0000000..5f74224
> > --- /dev/null
> > +++ b/conf/layer.conf
> > @@ -0,0 +1,19 @@
> > +# We have a conf and classes directory, append to BBPATH
> > +BBPATH .= ":${LAYERDIR}"
> > +
> > +# We have a recipes directory, add to BBFILES
> > +BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
> > +
> > +BBFILE_COLLECTIONS += "lts-go-mixin"
> > +BBFILE_PATTERN_lts-go-mixin := "^${LAYERDIR}/"
> > +BBFILE_PRIORITY_lts-go-mixin = "6"
> > +
> > +LAYERSERIES_COMPAT_lts-go-mixin = "dunfell"
> > +
> > +LAYERDEPENDS_lts-go-mixin = " \
> > + core \
> > +"
> > +
> > +GOVERSION ?= "1.17%"
> > +PREFERRED_PROVIDER_go-native = "go-binary-native"
> > +
> > --
> > 2.20.1
|
|
Re: [meta-lts-mixins][dunfell/go PATCH 1/4] Initial commit: add license, readme and layer config.

Khem Raj
On Thu, Jan 27, 2022 at 12:06 PM Denys Dmytriyenko < denis@...> wrote: On Thu, Jan 27, 2022 at 06:07:06PM +0100, Alexander Kanavin wrote:
> A question specifically to Denys, how can I actually get this into the
> mixin repo, and have commit rights to the branch? We've tested this quite
> well in private, and there are further enhancements coming up.
Michael,
Would it be possible to create 2 additional branches in the meta-lts-mixins
repository at https://git.yoctoproject.org/meta-lts-mixins/ called
"dunfell/go" and also "dunfell/docker" and give Alex push rights to them?
How would one use new version of both go and say kernel in a project
Please let us know, thanks a lot!
--
Denys
> On Thu, 27 Jan 2022 at 15:43, Alexander Kanavin via lists.yoctoproject.org
> <alex.kanavin=gmail.com@...> wrote:
>
> > Reviewed-by: Martin Kaistra <martin.kaistra@...>
> > Signed-off-by: Alexander Kanavin <alex@...>
> > ---
> > COPYING.MIT | 17 +++++++++++++++++
> > README | 23 +++++++++++++++++++++++
> > conf/layer.conf | 19 +++++++++++++++++++
> > 3 files changed, 59 insertions(+)
> > create mode 100644 COPYING.MIT
> > create mode 100644 README
> > create mode 100644 conf/layer.conf
> >
> > diff --git a/COPYING.MIT b/COPYING.MIT
> > new file mode 100644
> > index 0000000..fb950dc
> > --- /dev/null
> > +++ b/COPYING.MIT
> > @@ -0,0 +1,17 @@
> > +Permission is hereby granted, free of charge, to any person obtaining a
> > copy
> > +of this software and associated documentation files (the "Software"), to
> > deal
> > +in the Software without restriction, including without limitation the
> > rights
> > +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> > +copies of the Software, and to permit persons to whom the Software is
> > +furnished to do so, subject to the following conditions:
> > +
> > +The above copyright notice and this permission notice shall be included
> > in
> > +all copies or substantial portions of the Software.
> > +
> > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > OR
> > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> > THE
> > +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > FROM,
> > +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> > +THE SOFTWARE.
> > diff --git a/README b/README
> > new file mode 100644
> > index 0000000..5b22b72
> > --- /dev/null
> > +++ b/README
> > @@ -0,0 +1,23 @@
> > +"Mixin" layer for adding latest Go toolchain versions into the Yocto
> > Project LTS.
> > +
> > +At the time Dunfell was released in April 2020, Go 1.14 was the latest
> > version
> > +and officially Dunfell supports only that. This thin special-purpose mixin
> > +layer is meant to address this issue by backporting Go recipes from the
> > master
> > +branch of openembedded-core.
> > +
> > +You can see what Go versions are provided by listing recipes-devtools/
> > content.
> > +
> > +Including the layer automatically picks up the latest Go version;
> > different versions
> > +need to be set explicitly by adding the following line to your distro
> > config
> > +or local.conf:
> > +
> > +GOVERSION = "1.16%"
> > +
> > +Please note: enabling these newer Go versions makes docker from dunfell
> > branch
> > +of meta-virtualization unbuildable as it is too old. If you need a
> > working docker
> > +recipe, you can use the supplementary 'dunfell/docker' layer from this
> > meta-lts-mixin
> > +repository.
> > +
> > +
> > +Maintainers:
> > +Alexander Kanavin <alex@...>
> > diff --git a/conf/layer.conf b/conf/layer.conf
> > new file mode 100644
> > index 0000000..5f74224
> > --- /dev/null
> > +++ b/conf/layer.conf
> > @@ -0,0 +1,19 @@
> > +# We have a conf and classes directory, append to BBPATH
> > +BBPATH .= ":${LAYERDIR}"
> > +
> > +# We have a recipes directory, add to BBFILES
> > +BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
> > +
> > +BBFILE_COLLECTIONS += "lts-go-mixin"
> > +BBFILE_PATTERN_lts-go-mixin := "^${LAYERDIR}/"
> > +BBFILE_PRIORITY_lts-go-mixin = "6"
> > +
> > +LAYERSERIES_COMPAT_lts-go-mixin = "dunfell"
> > +
> > +LAYERDEPENDS_lts-go-mixin = " \
> > + core \
> > +"
> > +
> > +GOVERSION ?= "1.17%"
> > +PREFERRED_PROVIDER_go-native = "go-binary-native"
> > +
> > --
> > 2.20.1
|
|
Re: [meta-lts-mixins][dunfell/go PATCH 1/4] Initial commit: add license, readme and layer config.
On Thu, Jan 27, 2022 at 06:07:06PM +0100, Alexander Kanavin wrote: A question specifically to Denys, how can I actually get this into the mixin repo, and have commit rights to the branch? We've tested this quite well in private, and there are further enhancements coming up. Michael, Would it be possible to create 2 additional branches in the meta-lts-mixins repository at https://git.yoctoproject.org/meta-lts-mixins/ called "dunfell/go" and also "dunfell/docker" and give Alex push rights to them? Please let us know, thanks a lot! -- Denys On Thu, 27 Jan 2022 at 15:43, Alexander Kanavin via lists.yoctoproject.org <alex.kanavin=gmail.com@...> wrote:
Reviewed-by: Martin Kaistra <martin.kaistra@...> Signed-off-by: Alexander Kanavin <alex@...> --- COPYING.MIT | 17 +++++++++++++++++ README | 23 +++++++++++++++++++++++ conf/layer.conf | 19 +++++++++++++++++++ 3 files changed, 59 insertions(+) create mode 100644 COPYING.MIT create mode 100644 README create mode 100644 conf/layer.conf
diff --git a/COPYING.MIT b/COPYING.MIT new file mode 100644 index 0000000..fb950dc --- /dev/null +++ b/COPYING.MIT @@ -0,0 +1,17 @@ +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN +THE SOFTWARE. diff --git a/README b/README new file mode 100644 index 0000000..5b22b72 --- /dev/null +++ b/README @@ -0,0 +1,23 @@ +"Mixin" layer for adding latest Go toolchain versions into the Yocto Project LTS. + +At the time Dunfell was released in April 2020, Go 1.14 was the latest version +and officially Dunfell supports only that. This thin special-purpose mixin +layer is meant to address this issue by backporting Go recipes from the master +branch of openembedded-core. + +You can see what Go versions are provided by listing recipes-devtools/ content. + +Including the layer automatically picks up the latest Go version; different versions +need to be set explicitly by adding the following line to your distro config +or local.conf: + +GOVERSION = "1.16%" + +Please note: enabling these newer Go versions makes docker from dunfell branch +of meta-virtualization unbuildable as it is too old. If you need a working docker +recipe, you can use the supplementary 'dunfell/docker' layer from this meta-lts-mixin +repository. + + +Maintainers: +Alexander Kanavin <alex@...> diff --git a/conf/layer.conf b/conf/layer.conf new file mode 100644 index 0000000..5f74224 --- /dev/null +++ b/conf/layer.conf @@ -0,0 +1,19 @@ +# We have a conf and classes directory, append to BBPATH +BBPATH .= ":${LAYERDIR}" + +# We have a recipes directory, add to BBFILES +BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend" + +BBFILE_COLLECTIONS += "lts-go-mixin" +BBFILE_PATTERN_lts-go-mixin := "^${LAYERDIR}/" +BBFILE_PRIORITY_lts-go-mixin = "6" + +LAYERSERIES_COMPAT_lts-go-mixin = "dunfell" + +LAYERDEPENDS_lts-go-mixin = " \ + core \ +" + +GOVERSION ?= "1.17%" +PREFERRED_PROVIDER_go-native = "go-binary-native" + -- 2.20.1
|
|
Re: [meta-lts-mixins][dunfell/go PATCH 1/4] Initial commit: add license, readme and layer config.

Khem Raj
On Thu, Jan 27, 2022 at 9:07 AM Alexander Kanavin <alex.kanavin@...> wrote: A question specifically to Denys, how can I actually get this into the mixin repo, and have commit rights to the branch? We've tested this quite well in private, and there are further enhancements coming up.
this could be an independent layer too. Alex
On Thu, 27 Jan 2022 at 15:43, Alexander Kanavin via lists.yoctoproject.org <alex.kanavin=gmail.com@...> wrote:
Reviewed-by: Martin Kaistra <martin.kaistra@...> Signed-off-by: Alexander Kanavin <alex@...> --- COPYING.MIT | 17 +++++++++++++++++ README | 23 +++++++++++++++++++++++ conf/layer.conf | 19 +++++++++++++++++++ 3 files changed, 59 insertions(+) create mode 100644 COPYING.MIT create mode 100644 README create mode 100644 conf/layer.conf
diff --git a/COPYING.MIT b/COPYING.MIT new file mode 100644 index 0000000..fb950dc --- /dev/null +++ b/COPYING.MIT @@ -0,0 +1,17 @@ +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN +THE SOFTWARE. diff --git a/README b/README new file mode 100644 index 0000000..5b22b72 --- /dev/null +++ b/README @@ -0,0 +1,23 @@ +"Mixin" layer for adding latest Go toolchain versions into the Yocto Project LTS. + +At the time Dunfell was released in April 2020, Go 1.14 was the latest version +and officially Dunfell supports only that. This thin special-purpose mixin +layer is meant to address this issue by backporting Go recipes from the master +branch of openembedded-core. + +You can see what Go versions are provided by listing recipes-devtools/ content. + +Including the layer automatically picks up the latest Go version; different versions +need to be set explicitly by adding the following line to your distro config +or local.conf: + +GOVERSION = "1.16%" + +Please note: enabling these newer Go versions makes docker from dunfell branch +of meta-virtualization unbuildable as it is too old. If you need a working docker +recipe, you can use the supplementary 'dunfell/docker' layer from this meta-lts-mixin +repository. + + +Maintainers: +Alexander Kanavin <alex@...> diff --git a/conf/layer.conf b/conf/layer.conf new file mode 100644 index 0000000..5f74224 --- /dev/null +++ b/conf/layer.conf @@ -0,0 +1,19 @@ +# We have a conf and classes directory, append to BBPATH +BBPATH .= ":${LAYERDIR}" + +# We have a recipes directory, add to BBFILES +BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend" + +BBFILE_COLLECTIONS += "lts-go-mixin" +BBFILE_PATTERN_lts-go-mixin := "^${LAYERDIR}/" +BBFILE_PRIORITY_lts-go-mixin = "6" + +LAYERSERIES_COMPAT_lts-go-mixin = "dunfell" + +LAYERDEPENDS_lts-go-mixin = " \ + core \ +" + +GOVERSION ?= "1.17%" +PREFERRED_PROVIDER_go-native = "go-binary-native" + -- 2.20.1
|
|
Re: [meta-lts-mixins][dunfell/go PATCH 1/4] Initial commit: add license, readme and layer config.
A question specifically to Denys, how can I actually get this into the mixin repo, and have commit rights to the branch? We've tested this quite well in private, and there are further enhancements coming up.
Alex
toggle quoted message
Show quoted text
Reviewed-by: Martin Kaistra <martin.kaistra@...>
Signed-off-by: Alexander Kanavin <alex@...>
---
COPYING.MIT | 17 +++++++++++++++++
README | 23 +++++++++++++++++++++++
conf/layer.conf | 19 +++++++++++++++++++
3 files changed, 59 insertions(+)
create mode 100644 COPYING.MIT
create mode 100644 README
create mode 100644 conf/layer.conf
diff --git a/COPYING.MIT b/COPYING.MIT
new file mode 100644
index 0000000..fb950dc
--- /dev/null
+++ b/COPYING.MIT
@@ -0,0 +1,17 @@
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.
diff --git a/README b/README
new file mode 100644
index 0000000..5b22b72
--- /dev/null
+++ b/README
@@ -0,0 +1,23 @@
+"Mixin" layer for adding latest Go toolchain versions into the Yocto Project LTS.
+
+At the time Dunfell was released in April 2020, Go 1.14 was the latest version
+and officially Dunfell supports only that. This thin special-purpose mixin
+layer is meant to address this issue by backporting Go recipes from the master
+branch of openembedded-core.
+
+You can see what Go versions are provided by listing recipes-devtools/ content.
+
+Including the layer automatically picks up the latest Go version; different versions
+need to be set explicitly by adding the following line to your distro config
+or local.conf:
+
+GOVERSION = "1.16%"
+
+Please note: enabling these newer Go versions makes docker from dunfell branch
+of meta-virtualization unbuildable as it is too old. If you need a working docker
+recipe, you can use the supplementary 'dunfell/docker' layer from this meta-lts-mixin
+repository.
+
+
+Maintainers:
+Alexander Kanavin <alex@...>
diff --git a/conf/layer.conf b/conf/layer.conf
new file mode 100644
index 0000000..5f74224
--- /dev/null
+++ b/conf/layer.conf
@@ -0,0 +1,19 @@
+# We have a conf and classes directory, append to BBPATH
+BBPATH .= ":${LAYERDIR}"
+
+# We have a recipes directory, add to BBFILES
+BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
+
+BBFILE_COLLECTIONS += "lts-go-mixin"
+BBFILE_PATTERN_lts-go-mixin := "^${LAYERDIR}/"
+BBFILE_PRIORITY_lts-go-mixin = "6"
+
+LAYERSERIES_COMPAT_lts-go-mixin = "dunfell"
+
+LAYERDEPENDS_lts-go-mixin = " \
+ core \
+"
+
+GOVERSION ?= "1.17%"
+PREFERRED_PROVIDER_go-native = "go-binary-native"
+
--
2.20.1
|
|
Re: bbappend conditional check for advanced metadata (yocto-kernel-cache)?
Hello Bruce, Another is to make that append conditional based on something you can test. i.e. test for kernel-cache in the SRC_URI, and if present, do the append. Or you could test for the defconfig in the SRC_URI and don't do the append. There may be other options for this, but without all the details of the recipes, I can't say for sure. I have a few variations of that theme in meta-virtualization, since there's a broad range of kernel types supported (https://git.yoctoproject.org/meta-virtualization/tree/recipes-kernel/linux/linux-yocto_virtualization.inc). I chose the variant based on SRC_URI, but used KERNEL_CONFIG_URI because I got endless recursion between SRC_URI and KERNEL_FEATURES in the kernel recipe I use. I ended up with this function: def insert_if_kernel_cache_available(feature, d): import re if d.getVar('KERNEL_CONFIG_URI'): config_uri = d.getVar('KERNEL_CONFIG_URI') kernel_cache = re.search("kernel-cache", config_uri) if kernel_cache: return feature return "" KERNEL_FEATURES:append = "${@insert_if_kernel_cache_available(' features/overlayfs/overlayfs.scc', d)}" Many greetings, Matthias
|
|
Re: [PATCH yocto-autobuilder-helper] run-docs-build: fix checkout of releases.rst from master
Hi Quentin, Thank you very much for the review. On 1/26/22 09:11, Quentin Schulz wrote: Hi Michael,
On January 25, 2022 5:45:46 PM GMT+01:00, Michael Opdenacker <michael.opdenacker@...> wrote:
A wrong path was given given the working directory.
Also revert the changes with "git reset --hard" to have a clean state before further branch switches.
One change at a time please ☺️ Well, here, the two should go together. I admit my description is probably misleading. My initial "git checkout" was wrong (wrong path), so wasn't doing anything. Now that "git checkout" works as expected, I need a way to clean the branch after the docs are generated. Otherwise, I'll switch branches in the rest of the script from an unclean state.
Signed-off-by: Michael Opdenacker <michael.opdenacker@...> --- scripts/run-docs-build | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/scripts/run-docs-build b/scripts/run-docs-build index 5d6d24a..c93b3e6 100755 --- a/scripts/run-docs-build +++ b/scripts/run-docs-build @@ -43,11 +43,12 @@ cp -r ./_build/final/* $outputdir/bitbake/next # see the latest releases. for branch in 1.46 1.48 1.50 1.52; do git checkout $branch - git checkout master doc/releases.rst + git checkout master releases.rst make clean make publish mkdir $outputdir/bitbake/$branch cp -r ./_build/final/* $outputdir/bitbake/$branch + git reset --hard This should be done right after the git checkout. It's better to ensure what you build is clean that try to ensure the next oneto build has a clean env. Especially since checkouts can dirty the git repo I think (I've had this issue multiple times when switching between kernel branches far enough from one another).
Also git reset --hard is not enough. I use git clean -ffdx instead usually. Didn't have a problem with this one for a while now.
My point was just to undo the "git checkout" to fetch releases.txt from "master", not to be a substitute for "make clean". I can't do it right after "git checkout" otherwise I'm not doing anything at all. You have a valid point about a possible "dirty" git version though. Fortunately, I checked and it seems that uncommitted changes have no impact on the generated docs. I couldn't find any git commit anywhere. Thanks Michael. -- Michael Opdenacker, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
|
|
Minutes: Yocto Project Weekly Triage Meeting 1/27/2022
Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage
Attendees: Alexandre, Armin, Daiane, Michael, Randy,
Richard, Ross, Saul, Stephen, Steve, Tim, Trevor
ARs:
- Randy to take a look AB-INT defects for M2s and update them
to M3
- Everyone to review open bugs and move Old Milestone (M2) bugs
to M3 or later
Notes:
- ~50% of AB workers have been switched to SSDs. Failure rate
appears lower, but still TBD
Medium+ 3.5 Unassigned Enhancements/Bugs: 76 (Last week
80)
Medium+ 3.99 Unassigned Enhancements/Bugs: 39 (Last
week 38)
AB Bugs: 76
(Last week 76)
|
|
Re: [meta-lts-mixins][dunfell/go PATCH 1/4] Initial commit: add license, readme and layer config.
On Thu, 27 Jan 2022 at 15:48, Konrad Weihmann < kweihmann@...> wrote: > +GOVERSION ?= "1.17%"
> +PREFERRED_PROVIDER_go-native = "go-binary-native"
Just out of curiosity: I thought the agreement was that neither
PREFERRED_PROVIDER_* nor recipe/provider specific settings should be
part of a layer.conf
PREFERRED_PROVIDER_go-native as a hard assignment might be troublesome
in some setups (mainly depending on what order bblayers.conf actually has)
Yes, but this way it 'just works'. I do not think writing complicated instructions in README for what needs to be in local.conf or distro config is a better alternative. Suggestions welcome.
Alex
|
|