|
Sysvinit recipe with custom package group Build ERROR
#dunfell
Abdelrahman El-Gammal <a.elgammal2019@...>
Hello there,
I am building a sysvinit recipe for a startup app. And add into the image using custom package groups. Both the package group and recipe when built on their own, the build succeeds. But, when building the image, I got error in do_rootfs task. Here is the error msg:
The following packages have unmet dependencies: packagegroup-custom-apps : Depends: demoappstartup but it is not installable
E: Unable to correct problems, you have held broken packages. Here is the Sysvinit recipe: SUMMARY = "startup_script"
DESCRIPTION = "This recipe builds startup applications"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://demoapp_startup.sh"
INITSCRIPT_NAME = "demoapp_startup.sh"
INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ."
inherit update-rc.d
S = "${WORKDIR}"
do_install () {
install -d ${D}${sysconfdir}/init.d/
install -c -m 755 ${WORKDIR}/${INITSCRIPT_NAME} ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
}
Here is the shell script for the app, demoapp_startup.sh: #! /bin/sh
# /etc/init.d/start_sample_app
#
# Carry out specific functions when asked to by the system
case "$1" in
start)
echo "Starting sampleApp "
exec /opt/trial1/bin/trial1 -s &
;;
stop)
echo "Stopping sampleApp"
start-stop-daemon --stop --name trial1 --quiet
;;
(*))
echo "Usage: /etc/init.d/start_sample_app {start|stop}"
exit 1
;;
esac
exit 0
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-rockchip][PATCH] rock-pi-e: update preferred kernel
Trevor Woerner
The latest updates to linux-yocto-dev now include support for the rock-pi-e so
do away with our custom recipe and use the one from oe-core. Signed-off-by: Trevor Woerner <twoerner@...> --- conf/machine/rock-pi-e.conf | 2 +- .../linux/linux-stable-bleeding_5.11.bb | 18 ------------------ recipes-kernel/linux/linux-yocto%.bbappend | 1 + 3 files changed, 2 insertions(+), 19 deletions(-) delete mode 100644 recipes-kernel/linux/linux-stable-bleeding_5.11.bb diff --git a/conf/machine/rock-pi-e.conf b/conf/machine/rock-pi-e.conf index 7afe143..9cd3ed4 100644 --- a/conf/machine/rock-pi-e.conf +++ b/conf/machine/rock-pi-e.conf @@ -7,7 +7,7 @@ require conf/machine/include/rk3328.inc MACHINEOVERRIDES =. "rock-pi-e:" -PREFERRED_PROVIDER_virtual/kernel = "linux-stable-bleeding" +PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev" KERNEL_DEVICETREE = "rockchip/rk3328-rock-pi-e.dtb" MACHINE_EXTRA_RRECOMMENDS += "kernel-modules" diff --git a/recipes-kernel/linux/linux-stable-bleeding_5.11.bb b/recipes-kernel/linux/linux-stable-bleeding_5.11.bb deleted file mode 100644 index 508ddae..0000000 --- a/recipes-kernel/linux/linux-stable-bleeding_5.11.bb +++ /dev/null @@ -1,18 +0,0 @@ -# the rock-pi-e is very new -# it's exciting that support has already been added upstream -# but it's so new that even linux-yocto-dev doesn't have it yet -# -# in time we should see the need for this recipe going away - -inherit kernel -require recipes-kernel/linux/linux-yocto.inc - -LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46" - -SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git" -SRCREV = "c03c21ba6f4e95e406a1a7b4c34ef334b977c194" -LINUX_VERSION = "5.11" -LINUX_VERSION_EXTENSION = "" -PV = "${LINUX_VERSION}" - -COMPATIBLE_MACHINE_rock-pi-e = "rock-pi-e" diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/linux/linux-yocto%.bbappend index 3789c72..c2fe9ad 100644 --- a/recipes-kernel/linux/linux-yocto%.bbappend +++ b/recipes-kernel/linux/linux-yocto%.bbappend @@ -9,6 +9,7 @@ COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4" COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4" COMPATIBLE_MACHINE_nanopi-m4-2gb = "nanopi-m4-2gb" COMPATIBLE_MACHINE_rock64 = "rock64" +COMPATIBLE_MACHINE_rock-pi-e = "rock-pi-e" FILESEXTRAPATHS_prepend := "${THISDIR}/files:" -- 2.30.0.rc0 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-rockchip][PATCH] remove LINUX_VERSION_EXTENSION
Trevor Woerner
Adding "-rockchip" to the Linux kernel name implies, to me anyway, that this
is a vendor kernel. The PREFERRED_PROVIDERs of all kernels specified in this BSP are upstream linux-yocto kernels, not vendor kernels. Therefore remove the version name extension to avoid confusion. Signed-off-by: Trevor Woerner <twoerner@...> --- conf/machine/include/rockchip-defaults.inc | 1 - 1 file changed, 1 deletion(-) diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc index 0666119..905b2a6 100644 --- a/conf/machine/include/rockchip-defaults.inc +++ b/conf/machine/include/rockchip-defaults.inc @@ -3,7 +3,6 @@ # kernel PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" KCONFIG_MODE ?= "alldefconfig" -LINUX_VERSION_EXTENSION ?= "-rockchip" # xserver PREFERRED_PROVIDER_virtual/xserver = "xserver-xorg" -- 2.30.0.rc0 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Technical Team Minutes, Engineering Sync, for July 13, 2021
Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for July 13, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == disclaimer == Best efforts are made to ensure the below is accurate and valid. However, errors sometimes happen. If any errors or omissions are found, please feel free to reply to this email with any corrections. == attendees == Trevor Woerner Stephen Jolley Scott Murray Joshua Watt Peter Kjellerstedt Michael Halstead Jasper Orschulko Steve Sakoman Tony Tascioglu Trevor Gamblin Saul Wold Armin Kuster Randy MacLeod Richard Purdie Angolini Ross Burton Bruce Ashfield == project status == - an eSDK issue has been resolved and this should resolve a number of eSDK bugs - the prserv rewrite is still pending on resolving the issues with python asyncio - continuing to see AB-INT improvements - multiconfig needs simpler test cases to reproduce issues == discussion == RP: it was a good week for AB improvements! ptests are growing in number RP: we are lacking official maintainers for various subsystems. there are a number of unofficial ones (e.g. Bruce - kernels, Khem - toolchains, etc) but nothing official. we have a “bus” problem. Randy: people can adopt packages, but i’m curious about an outline of what you think is lacking RP: pseudo, devtool, extensible sdk, eclipse plugin (maybe not), recipetool, a backup maintainer for bitbake, test suites, QA frameworks, reporting system… Randy: it could be a question of corporate mandate for some RP: i’ll be raising this with the members TrevorW: in one case there was a problem with a certain subsystem that had been going on for a long time with no signs of life from the “active maintainer”. after a period of time i decided i would get involved and step forward and say i’d take it over. then suddenly the AWOL maintainer shows up, declares the subsystem has a maintainer and no change in maintainership is needed. in another case i found what i thought was a bug in an unmaintained subsystem, worked on a fix/patch but when i submitted it, the previous maintainer (who had stepped down at this point) spoke up to say there was no bug, pointed out that my “fix” didn’t preserve the existing behaviour (which i felt was broken, so of course it didn’t maintain it) therefore my patch shouldn’t go in. so we have subsystems whose active maintainers aren’t heard from for long periods but then show up once someone steps forward to take over, and we have other subsystems where previous maintainers who have given up their roles are still controlling the subsystem. if i were to maintain a subsystem, i would expect some sort of control over the subsystem i was maintaining. For example with U-Boot a person agrees to maintain, for example, an SoC so Tom gives them full control over the code related to that SoC. they don’t wake up the next day to find a whole bunch of SoC-specific patches have been merged by the benevolent dictator while they were sleeping and then have to deal with the consequences. The same happens in the kernel: people are given an area to maintain and they do so. RP: a maintainer doesn’t get to make all decisions. for example: recently i wanted to make a change to bitbake but was shot down, so even the benevelent dictator can be ruled down ;-) there’s no free choice. being a maintainer isn’t a binary switch, you don’t become a maintainer then suddenly get full control of some part of the project and get to make any decisions you want. another example: a kernel submaintainer isn’t absolute either, when i maintained a kernel subsystem sometimes you win some discussions and sometimes you lose some. one has to work into a maintainer role, not just take it over. and it’s good to retain a connection to a former maintainer for continuance. TrevorW: having code change “underneath the maintainer” can get frustrating RP: we will never have a system whereby i will only grab a patch after maintainer sign-off. the maintainer leaves for a 2 week vacation and the patch queue comes to a halt for that subsystem, that’s not right TrevorW: having more distributed maintainership might require fundamental changes to how the project is managed (e.g. how we do releases). some other projects with more distributed maintainership will have times when things get added (-rc1, -rc2) with integration windows and during that time it’s up to maintainers to do their own things with the patches. with our project (yocto) patches that show up on the mailing list today are added to next and even master in huge batches and run on the AB. so I don’t see what the role of a maintainer would be in that case if patches are being moved about without their intervention Scott: yocto is different because we’re dealing with the timelines of lots of sub projects so it might not fit into easy merge windows like it does for individual projects (-rc1, -rc2 etc merge windows) RP: getting patches in quickly helps keep people engaged. how would people feel if they submitted a patch then 3 weeks later got a reply saying “your patch failed on the AB, please re-spin”? TrevorW: if you submitted a patch for the linux kernel today it would show up… 3 (?) releases from now (provided it was “immediately” accepted)? so that would be the same as other projects Randy: we do have maintainers for every layer and we have Bruce and Khem, but there is a gap RP: wrt pseudo, i still haven’t merged things to master, so i’ve held off because the original maintainer doesn’t like some of my changes. it’s a difficult balancing act Randy: TrevorW would you still be interested in taking over pseudo TrevorW: I think i’d aim for devtool instead, i think pseudo is “complicated” (not from a technical point of view, but from a social standpoint) RP: the problem with pseudo is that anyone taking it over would most likely start over and solve the problem in a completely different way. there are a lot of newer kernel features that we would use instead JPEW: i would rather have a devtool maintainer than a pseudo maintainer. as a project we strongly push people towards using devtool on a daily basis, i would prefer to see that subproject have an active maintainer Randy: we’re a week away from -m2, anyone have anything else to discuss? Randy: i’m hoping to update things i’m working on. RP: there are some things that are broken in sato (icons not generated correctly) so i’m looking forward to those updates (icons depends on librsvg, which depends on rust) Ross: maybe we should revert now until the fix is ready? RP: if you know which bits to reverse then go ahead Ross: oh… i think the reverse is already in RP: okay, maybe there’s something else that needs revert. every week the AUH reports not being able to move forward on this Scott: i have a work tree setup for read-only PR server. so i’m hoping to be able to take that over at some point RP: ping me if you need help, i can help with historical context JPEW: i can help too, with some technical issues as well RP: MichaelH is probably not excited about the webserver stuff JPEW: where is it running MH: google compute JPEW: do we have a kubernetes cluster MH: no RP: we would like to share hash equiv on a read-only port, which might give MH a heart-attack ;-) MH: currently we’re running on a google computer node, but based on it’s resources, we could move it to something cheaper Randy: JPEW: do you need a kubernetes cluster? JPEW: no. i brought it up because it might be a way to load balance the demand, but that would require a re-write on some of the internals of the hash equiv server (e.g. move to a full, separate SQL database for example) MH: btw, irc logs now being saved again JPEW: my sstate patch is now ready RP: does it use compression? JPEW: originally yes, but then i noticed that it makes sstate not reproducible, so i dropped it RP: why? that shouldn’t be the case? JPEW: it wouldn’t if it were single thread compression, but the way zstd does parallel compression makes it give different results based on the compression factor PR: we use parallel compression for a lot of other stuff and i’ve never seen such an issue JPEW: i’ll do more investigation. i think there might be an option to pass to make it reproducible even under parallel compression RP: yes, that sounds right JPEW: also if we’re going to use zstd and pzstd they require those tools to be available in the host RP: cmdline (i.e. not libraries)? JPEW: yes, so we can include it in the buildtools tarball RP: yes and we can detect it in the host easily JPEW: okay, i will work up the patch RP: you can send the patch as-is now and we can add compression later Scott: any updates to “make jobserver” TrevorG: are you referring to the patch based on some changes RP made a couple years back Scott: yes TrevorG: i don’t think that patch is doing much for us. i didn’t find anything conclusive to say that patch is helping. we moved to another approach (passing a “-l” option to ninja to limit parallel). we’ve run a couple builds and collected some data, but we don’t have any results to publish yet. i have a couple hundred log files to look at to see if we’re on the right track. on the surface i think we’ve already seen a couple instances of things taking more parallel than they should (despite our changes) so we still have more things to dig into |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Per recipes simple smoke tests
Hi Samuel
toggle quoted message
Show quoted text
Please look at insane.bbclass and perhaps a new check can be added there ? On Tue, Jul 13, 2021 at 12:42 AM Samuel Dolt <samuel.dolt@...> wrote:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [meta-spdxscanner] Question about meta-spdxscanner
On 13/07/21 10:57, leimaohui@... wrote:
Hi Marco.snip. By the way, why not try fossology? It is really good that you can browse the compliance information on fossology server after you get spdx files by bitbake of YP. Hi Lei, I tried the latest meta-spdxscanner with a Docker version cof Fossology but the entire process fails with errors on the Yocto bitbake side. I'd like to have a minimal proof of work of this toolkit. Would you mind sharing the version and the configuration you are using successfully (for both meta-spdxscanner and Fossology)? Thank you -- Marco |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Project Status WW28`21
Stephen Jolley
Current Dev Position: YP 3.4 M2 Next Deadline: 12th July 2021 YP 3.4 M2 build
Next Team Meetings:
Key Status/Updates:
Ways to contribute:
YP 3.4 Milestone Dates:
Planned upcoming dot releases:
Tracking Metrics:
The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at: https://wiki.yoctoproject.org/wiki/TSC
The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status
[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
M+ & H bugs with Milestone Movements WW27
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Enhancements/Bugs closed WW28!
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Current high bug count owners for Yocto Project 3.4
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Project Newcomer & Unassigned Bugs - Help Needed
Stephen Jolley
All,
The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.
Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 360 unassigned or newcomer bugs.
We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.
Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[yocto-autobuilder-helper] [PATCH] config.json: Use pregen-hostkeys on all qemu targets
Richard Purdie
Rather than just ppc/mips, use the pregen-hostkeys on all the qemu targets
since this is using a lot of time on the autobuilders when we don't really need to. This should avoid some of the testing failures seen on qemuarm recently. Signed-off-by: Richard Purdie <richard.purdie@...> --- config.json | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/config.json b/config.json index 4f6044e..1c52d60 100644 --- a/config.json +++ b/config.json @@ -71,6 +71,9 @@ "arch-qemu" : { "BUILDINFO" : true, "BUILDHISTORY" : true, + "extravars" : [ + "IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'" + ], "step1" : { "BBTARGETS" : "core-image-sato core-image-sato-sdk core-image-minimal core-image-minimal-dev core-image-sato:do_populate_sdk", "SANITYTARGETS" : "core-image-minimal:do_testimage core-image-sato:do_testimage core-image-sato-sdk:do_testimage core-image-sato:do_testsdk" @@ -91,6 +94,9 @@ "DISTRO" : "poky-altcfg", "BUILDINFO" : true, "BUILDHISTORY" : true, + "extravars" : [ + "IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'" + ], "step1" : { "BBTARGETS" : "core-image-full-cmdline core-image-sato core-image-sato-sdk", "SANITYTARGETS" : "core-image-full-cmdline:do_testimage core-image-sato:do_testimage core-image-sato-sdk:do_testimage" @@ -383,16 +389,10 @@ }, "qemumips" : { "MACHINE" : "qemumips", - "extravars" : [ - "IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'" - ], "TEMPLATE" : "arch-qemu" }, "qemumips-alt" : { "MACHINE" : "qemumips", - "extravars" : [ - "IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'" - ], "TEMPLATE" : "altcfg-qemu" }, "edgerouter" : { @@ -409,16 +409,10 @@ }, "qemuppc" : { "MACHINE" : "qemuppc", - "extravars" : [ - "IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'" - ], "TEMPLATE" : "arch-qemu" }, "qemuppc-alt" : { "MACHINE" : "qemuppc", - "extravars" : [ - "IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'" - ], "TEMPLATE" : "altcfg-qemu" }, "qemux86" : { -- 2.30.2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [meta-spdxscanner] Question about meta-spdxscanner
On 13/07/21 10:57, leimaohui@... wrote:
Hi MarcoI see that meta-spdxscanner has been moved to http://git.yoctoproject.org,Yes, you can contact me or contribute to meta-spdxscanner to this ML. Hi Lei, thank you for answering. Considering the problems I encounter with scancode-tk and that the artifacts it produces are simple text files that need further analysis, I was just deciding to migrate to Fossology with "fossology-rest". The only drawback is having to install the server, but I don't think it will be a problem. Thanks again, I will contact you again if you have any problems with this mode. Best, -- Marco Cavallini | KOAN sas Bergamo - Italia embedded software engineering https://KoanSoftware.com |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [meta-spdxscanner] Question about meta-spdxscanner
leimaohui
Hi Marco
I see that meta-spdxscanner has been moved to http://git.yoctoproject.org,Yes, you can contact me or contribute to meta-spdxscanner to this ML. I'd like to have advice from you to understand if is it possible to test it withoutI have not maintained scancode-tk for long time. And recently there are somebody else asked me about scancode-tk. Yes, I planned to make scancode-tk.bbclass work without external service. But there are always issues because environment. The problem of scancode-tk.bbclass that scancode must work with specify a version of python(latest requires 3.6), but you know that for YP or your host, it is hard to meet the requirement. I found the newest version of scancode-tk support running in docker. So I plan to make scancode-tk.bbclass work with scancode command by docker next. Of course, if you have good ideas, please tell me, or contribute to meta-spdxscanner directlly. By the way, why not try fossology? It is really good that you can browse the compliance information on fossology server after you get spdx files by bitbake of YP. Best regards Lei -----Original Message----- |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Per recipes simple smoke tests
Hi everyone,
I was asked to add some basic tests to an internal recipe in order to improve our CI system. The purpose would be to produce an error if some check doesn't pass like - a file is not present - the generated file is of size 0 - the generated file is bigger than x bytes I'm thinking to add the functionality to a class, in order to be able to use these tests in more than one recipe. Something like that: https://gist.github.com/samdolt/cf1c557f73f4f2098a19ba7ad6bc092f Does something like that already exists? And if not, would it be useful to have this contributed upstream? Maybe as an addition to insane.bbclass? Cheers, Samuel |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: #yocto Preferred development workflow
#yocto
We have many recipes appended to IMAGE_INSTALL in our image recipes and it works just fine. From your description, it sounds like you could go either way. I personally prefer to keep my image recipes as clean as possible, so I push as much as I can to individual recipes. This helps with debugging later on as your project (inevitably) gets more complex. Also... Experience has shown that the following form is a lot more readable: IMAGE_INSTALL = "recipe_1" IMAGE_INSTALL += "recipe_2" IMAGE_INSTALL += "recipe_3" IMAGE_INSTALL += "recipe_4" IMAGE_INSTALL += "recipe_5" Than this: IMAGE_INSTALL = "\ recipe_1 \ recipe_2 \ recipe_3 \ recipe_4 \ recipe_5" When your repository grows large, a recursive grep for recipe_2 will make a lot more sense if "IMAGE_INSTALL += "recipe_2"" is returned instead of "recipe_2 \". The latter form gives no clue as to how recipe_2 is being referenced. ..Ch:W.. sorry about that, right now the config files are placed in the files directory of the recipe which builds the module. -- "Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: #yocto Preferred development workflow
#yocto
ivin.lim@...
sorry about that, right now the config files are placed in the files directory of the recipe which builds the module.
Sample snippets of the recipe concerning this config file, I removed the rest of lines. SRC_URI = " \
file://config.json \
" do_install_append() {
install -m 0644 ${WORKDIR}/config.json ${D}/etc/directory/
}
If I were to have the config files placed on a separate recipe, would that mean making multiple of these recipes depending on the number of projects? I did thought also of adding it in the image recipe but probably this wouldn't look well if more things get added. Thanks |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: #yocto Preferred development workflow
#yocto
You left a few details out about how the configuration files are managed. Ideally you could just make bitbake recipes for the config files themselves. This way you can create an image recipe for each project and use the IMAGE_INSTALL variable to append whatever configs and modules you want on a per-project basis. ..Ch:W.. Hi everyone, -- "Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
#yocto Preferred development workflow
#yocto
ivin.lim@...
Hi everyone,
I'm curious on a good approach when dealing with multiple projects I've just started out yocto and have already created our own meta-layer which contains our modules. Now these modules would sometimes have config files and this could vary when each project that we have would use these recipes. I'm thinking of a way to control this. And I don't think having one branch per project is a good style. Right now the best way I can think of is creating seperate "project layers" (ex. meta-project1, meta-project2) and from there create those .bbappends which would point to the project-specific conf files. But I was wondering if there is a better way of handling it. Thanks. Cheers. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [layerindex-web][PATCH] models.py: extend max_length of name in YPCompatibleVersions to 100
Changqing Li
add Paul Eggleton On 7/13/21 10:44 AM, Changqing Li
wrote:
From: Changqing Li <changqing.li@...> Now, YPCompatibleVersions's name is only designed for using version like 2.0 3.0, the max_length is 25. but we mostly use Codename for layer compatibility, eg: LAYERSERIES_COMPAT_dpdk = "dunfell gatesgarth hardknott", in this case, it's not enough to save the compatible version. so extend it to 100. Signed-off-by: Changqing Li <changqing.li@...> --- .../migrations/0045_yp_compatible_extend.py | 24 +++++++++++++++++++ layerindex/models.py | 2 +- 2 files changed, 25 insertions(+), 1 deletion(-) create mode 100644 layerindex/migrations/0045_yp_compatible_extend.py diff --git a/layerindex/migrations/0045_yp_compatible_extend.py b/layerindex/migrations/0045_yp_compatible_extend.py new file mode 100644 index 0000000..3544b4b --- /dev/null +++ b/layerindex/migrations/0045_yp_compatible_extend.py @@ -0,0 +1,24 @@ +# Generated by Django 2.2 on 2021-07-13 02:43 + +from django.db import migrations, models +import django.db.models.deletion + + +class Migration(migrations.Migration): + + dependencies = [ + ('layerindex', '0044_extendedprovides'), + ] + + operations = [ + migrations.AlterField( + model_name='classicrecipe', + name='cover_layerbranch', + field=models.ForeignKey(blank=True, limit_choices_to={'branch__name': 'master'}, null=True, on_delete=django.db.models.deletion.SET_NULL, to='layerindex.LayerBranch', verbose_name='Covering layer'), + ), + migrations.AlterField( + model_name='ypcompatibleversion', + name='name', + field=models.CharField(help_text='Name of this Yocto Project compatible version (e.g. "2.0")', max_length=100, unique=True, verbose_name='Yocto Project Version'), + ), + ] diff --git a/layerindex/models.py b/layerindex/models.py index 329cc33..2317740 100644 --- a/layerindex/models.py +++ b/layerindex/models.py @@ -217,7 +217,7 @@ class LayerRecipeExtraURL(models.Model): class YPCompatibleVersion(models.Model): - name = models.CharField('Yocto Project Version', max_length=25, unique=True, help_text='Name of this Yocto Project compatible version (e.g. "2.0")') + name = models.CharField('Yocto Project Version', max_length=100, unique=True, help_text='Name of this Yocto Project compatible version (e.g. "2.0")') description = models.TextField(blank=True) image_url = models.CharField('Image URL', max_length=300, blank=True) link_url = models.CharField('Link URL', max_length=100, blank=True) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|