13920 2020-05-25 10:05:06 +0000 uninative tarball license compliance in ESDK 2026-04-23 15:27:42 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 3.1 All Multiple NEW Medium+ normal 6.99 1 pokylinux unassigned meta.mr.watcher meta.watcher randy.macleod tgamblin --- --- Don't know oldest_to_newest 87328 0 pokylinux 2020-05-25 10:05:06 +0000 The uninative tarball is by default downloaded as a tarball to build the native SDK. e.g. here[1] we can see that that x86_64-nativesdk-libc.host.manifest contains something and that the x86_64-nativesdk-libc.target.manifest is empty. So I would assume that if you deliver an SDK the uninative tarball sources, license text and versions should be delivered as well as part of the open source license compliance. In deploy/sdk/xxx.host.manifest the packages from uninative seem to be missing. ... and ... I build a core-image-minimal and a core-image-minimal -c populate_sdk with this is my local.conf: # include license text in image COPY_LIC_MANIFEST = "1" COPY_LIC_DIRS = "1" # archiver class settings INHERIT += "archiver" ARCHIVER_MODE[src] = "original" ARCHIVER_MODE[diff] = "1" ARCHIVER_MODE[dumpdata] = "1" ARCHIVER_MODE[recipe] = "1" COPYLEFT_LICENSE_INCLUDE = "GPL* LGPL* hello*" COPYLEFT_LICENSE_EXCLUDE = 'CLOSED Proprietary' # if you don't release and SDK: #COPYLEFT_RECIPE_TYPES = 'target' # if you release the SDK: #COPYLEFT_RECIPE_TYPES += 'nativesdk' # all by default! # 9) Config the recipe type that will be archived, the type can be # target, native, nativesdk, cross, crosssdk and cross-canadian, # you can set one or more types. Archive all types by default. #COPYLEFT_RECIPE_TYPES = 'target' Same here: source code, and package information for uninative seem to be missing. [1] http://downloads.yoctoproject.org/releases/uninative/2.8/ 87329 1 pokylinux 2020-05-25 10:26:08 +0000 I tried to BitBake with the same settings my own uninative-tarball Now I got in deploy/licenses/uninative-tarball MIT license which comes from the recipe and I guess is WRONG. TOOLCHAIN_HOST_TASK = "\ nativesdk-glibc \ nativesdk-glibc-gconv-ibm850 \ nativesdk-glibc-gconv-iso8859-1 \ nativesdk-glibc-gconv-utf-16 \ nativesdk-glibc-gconv-cp1252 \ nativesdk-glibc-gconv-euc-jp \ nativesdk-glibc-gconv-libjis \ nativesdk-patchelf \ nativesdk-libxcrypt \ nativesdk-libxcrypt-compat \ nativesdk-libnss-nis \ " glibc: something like GPL/LGPL 2? patchelf: GPLv3 libxcrypt LGPLv2.1 libnss-nis LGPL-2.1 as a side note: now (after building the uninative-tarball) it looks like licenses and sources are available where they should be. What is the suggested workflow with uninative-tarball with respect to license compliance. According to the mega manual: "Alternatively, if you wish to build your own uninative tarball, you can do so by building the uninative-tarball recipe, making it available to your build machines (e.g. over HTTP/HTTPS) and setting a similar configuration as the one set by yocto-uninative.inc." Like this we loose again our license compliance artifacts. 95755 2 pokylinux 2023-06-20 15:06:30 +0000 The doc[1] says: The uninative class is also used unconditionally by the extensible SDK. When building the extensible SDK, uninative-tarball is built and the resulting tarball is included within the SDK. [1] https://docs.yoctoproject.org/singleindex.html#uninative If that's the case we can probably close this bug. 96080 3 randy.macleod 2023-07-26 21:22:02 +0000 Bulk move of 64 bugs to 4.3 M3 after a quick review. If a bug is actually fixed, please add a commit link and resolve it. -- Randy for YP bug team. 96462 4 tgamblin 2023-09-14 16:36:04 +0000 Moved to M4. 97075 5 randy.macleod 2023-10-30 15:29:13 +0000 Bulk move to 5.0 M1. -- Randy 97688 6 randy.macleod 2023-12-21 23:28:32 +0000 Bulk move of 52 5.0-M1 bugs to M2. 97998 7 randy.macleod 2024-01-25 14:28:47 +0000 Bulk move of bugs owned by "unassigned" from 5.0-M2 to 5.0-M3. 98288 8 randy.macleod 2024-02-22 19:53:20 +0000 Bulk move of bugs from 5.0-M3 to 5.99. The bugs in this list are all unassigned and are ones that I consider to be nice to do some time but not essential track from milestone to milestone in 5.0 or 5.1. We agreed on this bug handling approach in the YP bug review on Feb 22, 2024. If you disagree, please move back to a 5.[012...]-M* milestone.