|
Honister on Ubuntu 14.04
You might be better off trying to use a container to build, but with a host that old, even that might be hard. There are several container solutions for the project, including: * crops - https://githu
You might be better off trying to use a container to build, but with a host that old, even that might be hard. There are several container solutions for the project, including: * crops - https://githu
|
By
Joshua Watt
· #56367
·
|
|
QA change - reduced number of reproducibility builds tests?
I agree. I assume the change is simple enough to make that we can bring them back easily if we think it might be helpful is some scenario? Also, just to clarify, those workers will still contribute to
I agree. I assume the change is simple enough to make that we can bring them back easily if we think it might be helpful is some scenario? Also, just to clarify, those workers will still contribute to
|
By
Joshua Watt
· #56286
·
|
|
Minutes: Yocto Project Weekly Triage Meeting 1/6/2022
<trevor.gamblin@...> wrote: Merged as 52d5f76f54eac384f9480dffe96df089d9ee8f33 in OE-core
<trevor.gamblin@...> wrote: Merged as 52d5f76f54eac384f9480dffe96df089d9ee8f33 in OE-core
|
By
Joshua Watt
· #55923
·
|
|
Red alert but apparently harmless setscene errors
<michael.opdenacker@...> wrote: This usually happens when there is a sstate archive (.tar.zst), but no corresponding siginfo file (.tar.zst.siginfo). The sstate code assumes the siginfo file i
<michael.opdenacker@...> wrote: This usually happens when there is a sstate archive (.tar.zst), but no corresponding siginfo file (.tar.zst.siginfo). The sstate code assumes the siginfo file i
|
By
Joshua Watt
· #55840
·
|
|
Reproducible build website broken (CORS setting on git.yoctoproject.org?)
Michael, I noticed that the https://www.yoctoproject.org/reproducible-build-results/ website went down (it always shows "Error fetching test results"). I did a little debugging and I think that the CO
Michael, I noticed that the https://www.yoctoproject.org/reproducible-build-results/ website went down (it always shows "Error fetching test results"). I did a little debugging and I think that the CO
|
By
Joshua Watt
· #55809
·
|
|
spdx: Extending SPDX SBOMs for SDKs
<abeltran@...> wrote: Looks like the loop is: nativesdk-clang-glue.bb:do_create_spdx -> clang_git.bb:do_create_spdx -> clang-crosssdk_git.bb:do_create_spdx -> nativesdk-clang-glue.bb:d
<abeltran@...> wrote: Looks like the loop is: nativesdk-clang-glue.bb:do_create_spdx -> clang_git.bb:do_create_spdx -> clang-crosssdk_git.bb:do_create_spdx -> nativesdk-clang-glue.bb:d
|
By
Joshua Watt
· #55598
·
|
|
[meta-mingw] [PATCH] grpc: use the new PACKAGECONFIG to disable shared
This is good, thanks. Is the libnsl2 also tied to some feature? Perhaps you can explain why it needs to be removed from MinGW
This is good, thanks. Is the libnsl2 also tied to some feature? Perhaps you can explain why it needs to be removed from MinGW
|
By
Joshua Watt
· #54580
·
|
|
[meta-mingw] [PATCH] grpc: remove nl2 requirement since it is optional
Yes, that's a good idea. Sinan, please make that change in meta-oe, then change this patch to remove it from PACKAGECONFIG
Yes, that's a good idea. Sinan, please make that change in meta-oe, then change this patch to remove it from PACKAGECONFIG
|
By
Joshua Watt
· #54528
·
|
|
[meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk
RIght, the "mingw32" override shouldn't affect what you do with the *target* unless your target is MinGW; I'm not sure if anyone is actually doing that, most SDKs target Linux for ARM, Linux for AArch
RIght, the "mingw32" override shouldn't affect what you do with the *target* unless your target is MinGW; I'm not sure if anyone is actually doing that, most SDKs target Linux for ARM, Linux for AArch
|
By
Joshua Watt
· #54459
·
|
|
[meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk
Are you building with "mingw32" as the target (not as the SDK), and it works there? I wonder why it only fails for the SDK build and not the target build? If that is truly the case, then yes I suppose
Are you building with "mingw32" as the target (not as the SDK), and it works there? I wonder why it only fails for the SDK build and not the target build? If that is truly the case, then yes I suppose
|
By
Joshua Watt
· #54457
·
|
|
[meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk
I had to clean these up a little bit and pushed them to master-next. Please verify that they still work for you and if not used them as a starting point and send a V4 patchset.
I had to clean these up a little bit and pushed them to master-next. Please verify that they still work for you and if not used them as a starting point and send a V4 patchset.
|
By
Joshua Watt
· #54452
·
|
|
[meta-mingw] [PATCH v2 1/3] protobuf: static link tools when generating sdk
These 3 recipes are in meta-oe, not OE-core which means that the bbappends are going to cause a dangling appends error/warning. Please add a dynamic BBFILES pattern[1] so that these are conditionally
These 3 recipes are in meta-oe, not OE-core which means that the bbappends are going to cause a dangling appends error/warning. Please add a dynamic BBFILES pattern[1] so that these are conditionally
|
By
Joshua Watt
· #54441
·
|
|
[meta-mingw] [PATCH v2 1/3] protobuf: static link tools when generating sdk
Apologies, this should use the :mingw32 override, since it's not *specific* to the SDK, but MinGW in general. Anyway, I fixed this up for you since I wasn't clear; this is in master-next and I'll get
Apologies, this should use the :mingw32 override, since it's not *specific* to the SDK, but MinGW in general. Anyway, I fixed this up for you since I wasn't clear; this is in master-next and I'll get
|
By
Joshua Watt
· #54440
·
|
|
[meta-mingw] [PATCH 1/3] protobuf: static link tools when generating sdk
All of the bbappends in meta-mingw should be using the :mingw32 override (or sdkmingw32 if it specific to just the SDK). If you found an example in the current code where that is not the case, it need
All of the bbappends in meta-mingw should be using the :mingw32 override (or sdkmingw32 if it specific to just the SDK). If you found an example in the current code where that is not the case, it need
|
By
Joshua Watt
· #54435
·
|
|
[meta-mingw] [PATCH] binutils: Package static libdep linker plugins
Hmm, I'm not sure why I missed this. However, why is the MinGW build producing the .a files and not all the builds? It seems like this could go in the oe-core version of the recipe (w/o the override)
Hmm, I'm not sure why I missed this. However, why is the MinGW build producing the .a files and not all the builds? It seems like this could go in the oe-core version of the recipe (w/o the override)
|
By
Joshua Watt
· #54391
·
|
|
How to pass arguments to a shell function from python task bb.build.exec_func ?
#bitbake
#yocto
AFAIK, passing arguments from a python function to a shell function is not allowed
AFAIK, passing arguments from a python function to a shell function is not allowed
|
By
Joshua Watt
· #54186
·
|
|
[meta-mingw][PATCH] openssl: support for building nativesdk of mingw
It would appear that some or all of this patch is unnecessary. OE-core 166bb89f6d97495b6522786182b4f9623acd7ff4 implements part of this patch, which makes me think it's working there without any chang
It would appear that some or all of this patch is unnecessary. OE-core 166bb89f6d97495b6522786182b4f9623acd7ff4 implements part of this patch, which makes me think it's working there without any chang
|
By
Joshua Watt
· #54066
·
|
|
Zuul - Project Gating System with Yocto Project
I haven't, but it's on my radar to look at as it seems like it could be pretty useful. If you look into it, please share your findings!
I haven't, but it's on my radar to look at as it seems like it could be pretty useful. If you look into it, please share your findings!
|
By
Joshua Watt
· #54033
·
|
|
[meta-mingw][PATCH] Disable debuginfod
Disables debuginfod when using MingGW. This feature brings in unbuildable dependencies and can't be used. Signed-off-by: Joshua Watt <JPEWhacker@...> --- conf/machine-sdk/include/mingw32-common.
Disables debuginfod when using MingGW. This feature brings in unbuildable dependencies and can't be used. Signed-off-by: Joshua Watt <JPEWhacker@...> --- conf/machine-sdk/include/mingw32-common.
|
By
Joshua Watt
· #53889
·
|
|
Making a recipe that enables a systemd service it doesn't provide
It might be easier to manually enable the service with a symbolic link instead of using systemd.bbclass with something like: do_install() { install -Dm 755 ${D}${systemd_unitdir}/system/multi-user.tar
It might be easier to manually enable the service with a symbolic link instead of using systemd.bbclass with something like: do_install() { install -Dm 755 ${D}${systemd_unitdir}/system/multi-user.tar
|
By
Joshua Watt
· #53671
·
|