|
Re: [meta-security] [dunfell] [PATCH 0/3] Backport several IMA fixes to LTS dunfell
merged.
toggle quoted messageShow quoted text
thanks
On 4/18/21 11:41 PM, liu.ming50@... wrote:
From: Ming Liu <ming.liu@...>
|
|
|
|
Grub embedded config not useful
jbouchard@...
When I am looking at the grub embedded configuration I not fully sure I understand how this patch, https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c981ebba29001b8684e9805515576c2350a4e22b. In most case the search.file ($cmdpath) will only not find anything since cmdpath will contains something like this, (hd0,gpt1)/EFI/BOOT.
Thanks
|
|
|
|
#yocto opencl
#yocto
Monsees, Steven C (US)
Can someone tell me is this supported under Yocto in any way?
meta-beignet/recipes-opencl at ross · rossburton/meta-beignet · GitHub
Any docs, or updates ?
Wanted to know if this would work under Zeus, with meta-clang ? Looking to build opencl shared library support…
Thanks, Steve
|
|
|
|
Re: [meta-mingw] [PATCH] mingw-w64: Check for __builtin_ia32_rdtsc
ping^1
toggle quoted messageShow quoted text
On Tue, Apr 13, 2021 at 7:01 PM Khem Raj <raj.khem@...> wrote:
|
|
|
|
[PATCH yocto-autobuilder2 2/2] meta-arm doesn't use meta-kernel anymore
Ross Burton <ross@...>
Signed-off-by: Ross Burton <ross.burton@...>
--- config.py | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/config.py b/config.py index a723e3f..520de47 100644 --- a/config.py +++ b/config.py @@ -10,14 +10,14 @@ buildertorepos =3D { "a-quick": ["poky", "meta-intel", "oecore", "bitbake", "meta-mingw", "meta-gplv2"], "a-full": ["poky", "meta-intel", "oecore", "bitbake", - "meta-mingw", "meta-gplv2", "meta-arm", "meta-kernel"], + "meta-mingw", "meta-gplv2", "meta-arm"], "non-gpl3": ["poky", "meta-gplv2"], "meta-mingw": ["poky", "meta-mingw"], "qa-extras": ["poky", "meta-mingw"], "meta-oe": ["poky", "meta-openembedded"], "meta-virt": ["poky", "meta-openembedded", "meta-virtualization"], "meta-intel": ["poky", "meta-intel"], - "meta-arm": ["poky", "meta-arm", "meta-kernel"], + "meta-arm": ["poky", "meta-arm"], "meta-agl-core": ["poky", "meta-agl"], "meta-aws": ["poky", "meta-aws", "meta-openembedded"], "qemuarm-oecore": ["oecore", "bitbake"], @@ -54,7 +54,6 @@ repos =3D { "meta-gplv2": ["git://git.yoctoproject.org/meta-gplv2", "master"], "meta-openembedded": ["git://git.openembedded.org/meta-openembedded"= , "master"], "meta-virtualization": ["git://git.yoctoproject.org/meta-virtualizat= ion", "master"], - "meta-kernel": ["https://gitlab.com/openembedded/community/meta-kern= el.git", "master"], "yocto-docs": ["git://git.yoctoproject.org/yocto-docs", "master"] } =20 --=20 2.25.1
|
|
|
|
[PATCH yocto-autobuilder2 1/2] meta-arm has a hardknott branch now
Ross Burton <ross@...>
Signed-off-by: Ross Burton <ross.burton@...>
--- schedulers.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/schedulers.py b/schedulers.py index 8b166e0..93b8f34 100644 --- a/schedulers.py +++ b/schedulers.py @@ -206,7 +206,7 @@ def parent_scheduler(target): 'branch': 'hardknott', 'branch_poky': 'hardknott', 'branch_bitbake': '1.50', - 'branch_meta-arm': 'master', + 'branch_meta-arm': 'hardknott', 'branch_meta-gplv2': 'hardknott', 'branch_meta-intel': 'hardknott', 'branch_meta-mingw': 'hardknott', --=20 2.25.1
|
|
|
|
Re: Bitbake build failures?
Ross Burton <ross@...>
Because your networking is broken in some way and you cannot fetch
from downloads.yoctoproject.org. Outside of bitbake, try: wget http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz Ross On Tue, 27 Apr 2021 at 23:01, jchludzinski via lists.yoctoproject.org <jchludzinski=vivaldi.net@...> wrote:
|
|
|
|
Re: AppArmor with BusyBox
Quentin Schulz
Hi Khem,
On Tue, Apr 27, 2021 at 08:33:08PM -0700, Khem Raj wrote: On Tue, Apr 27, 2021 at 3:34 PM Konstantin Aladyshev <aladyshev22@...>Not sure to really understand the question, but the -d option of xargs is for specifying a delimiter different than the default space. There is no support for such a thing in Busybox implementation of xargs. Usually options for tools in Busybox are specified at the beginning of the C file: https://git.busybox.net/busybox/tree/findutils/xargs.c Line 17 to 71. If one looks for delimiter keyword in the file, nothing configurable is available, it's either space or EOF that is matched. I'm naive enough to think it might be not too hard to add this option to\ Busybox implementation. Cheers, Quentin
|
|
|
|
Re: AppArmor with BusyBox
On 4/27/21 8:33 PM, Khem Raj wrote:
You are using systemd. There is a comment regarding coreutils and findutils |# Add coreutils and findutils only if sysvinit scripts are in use Patches welcome. - Armin |
|
|
|
|
Re: [OE-core] [PATCH 6/7] default-distrovars.inc: add wayland/opengl to default distro features
Kevin Hao
On Tue, Apr 27, 2021 at 12:09:51PM -0400, Randy MacLeod wrote:
Cross-posting to yocto since this is of general interest.Thanks for the notice. Hmm, it seems that we have done little validation for the weston image on the Yocto BSPs, I got a boot failure with the weston image on my beaglebone black board. I will try to figure out what is wrong there. But I don't think it should block the change in this patch. Thanks, Kevin
|
|
|
|
Yocto Technical Team Minutes, Engineering Sync, for April 27, 2021
Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for April 27, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == announcements == The upcoming Yocto Project Summit is taking place May 25-26 2021 details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/ registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501 == 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 Jolly, Trevor Gamblin, Jan-Simon Möller, Steve Sakoman, Joshua Watt, Richard Purdie, Bruce Ashfield, Jere Kiikari, Scott Murray, Randy MacLeod, Armin Kuster, Saul Wold, Michael Opdenacker, Michael Halstead, Alejandro H, Jon Mason, Tim Orling == notes == - 3.1.7 released last week - patches flowing into master 3.4-m1 - added checking for key layers on AB (i.e. member layers) - libseccomp moved to oe-core - add opengl to default DISTRO_FEATURES proposal - 2 OE positions available on TSC == general == TW: OEHH is tomorrow RP: adding more layers and layer checks for heavily-used layers (e.g. meta-virtualization). we’re currently testing 8 layers, last week only 2 passed, now (i believe) they’re all passing the various checks TW: what tests? RP: yocto check-layer test, e.g. is there a README file, e.g. pass through the metadata without the layer, add the layer, repass through the metadata and verify that sstate checksums don’t change TW: any building? RP: no, just parsing. also does sub-layer testing too (e.g. meta-openembedded). led to finding a bug in the script RP: adding libseccomp in core unblocks meta-virtualization RP: AlexK is pushing hard to drop x11. not seeing any objections on the mailing list (hard to believe) Randy: are we covered if we switch? RP: i don’t think that’s entirely possible ScottM: software rendering is painfully slow (e.g. testing) Randy: okay, performance is slow, but full support? JPEW: isn’t this change just changing package building options? ScottM: mostly. i think it should be okay, what if someone enables both wayland and x11? RP: i’m concerned that there are BSP layers that don’t support opengl, this makes it a requirement for all BSP layers TW: i believe there a case in meta-raspberrypi if the user chooses VC graphics Armin: what do you mean “dropping x11”? removing x11 entirely? RP: if AlexK gets his way Armin: can we move it to meta-oe? RP: i don’t think removing it is on the table? Randy: so removing x11 server and replacing it with wayland-x11 server ScottM: it’ll have to happen sooner or later. many desktop distros are moving to wayland and away from x11 TimO: so a good drop before the next LTS? ScottM: that’s what i was thinking, maybe a tsc decision RP: opengl is a requirement for wayland? JPEW: not a hard requirement, but in practice… RP: uncomfortable about making opengl a default RP: uncomfortable with making this a DISTRO_FEATURE when maybe “graphics” is a BSP question TW: what about headless builds? J-SM: shouldn’t a headless build not need graphics things? TW: there’s probably some package that builds differently with opengl on or off but would be pulled into a headless build JPEW: opengl DISTRO_FEATURE is not the right thing to check for this RP: dbus builds differently depending on x11 ScottM: i’d like to look at how AlexK has implemented it, need to make sure the wayland features support the existing x11 features RP: nobody’s commented on the mailing list. the change has already been made in poky and nobody said anything and nothing blew up ScottM: are you going to switch away from core-image-sato to something weston RP: we’ll have to come up with something Armin: i know the mali stuff is hard to get working. Khem does a lot of builds with graphics stuff, so he’ll probably be the first one to say something if we switch. the blob drivers lag so far behind ScottM: true, there were some cases where we couldn’t update for a long time because we had to wait for vendor blobs to catch up and release weston things Randy: is remote desktop possible (ssh -X)? ScottM: there’s nothing built-in, but there are things that are being worked on, there are a couple options, mostly over pipewire JPEW: weston has an RDP backend ScottM: not as easy as the old ssh -X, but it works JPEW: with weston there’s the possibility to just forward 1 app instead of the entire server (rootless) TimO: we’re in an intermediate phase and vendor support is hard Armin: it’s like the python2 → python3 change TW: does that mean a meta-x11? Armin: probably, not sure if it’ll be public, but somebody’s going to have to solve that problem (MV, WR, …) RP: client vs server JPEW: depends on what you’re trying to do. if an app does crazy things with the server (e.g. send key events to another app) then wayland doesn’t permit that TimO: sato and matchbox are looking clunky these days JPEW: phosh might be a possibility. i built it recently and it seems good. uses a lot of gnome (meta-gnome) but it does build and work TrevorG: i played with it recently too, seemed okay TW: any umn patches? RP: actually i did check, didn’t see anything Saul: qmp. i think there’s a delay in the socket being created on CentOS RP: i checked and tested your patch and it seemed to work, so i merged it into master. Thank you for getting it there Saul: now we’ll see if it triggers, and if it does, then we can add to what it does. ping me when you see a failure and we’ll look at it Randy: do we have to pick up the logs manually? Saul: yea, they’re dumped into a directory (same place as other logs) Randy: hook it up to the latency monitoring things? Saul: possibly RP: there’s an env var set to a path for reproducible build pages generated. same place Randy is putting some logging and dd test. so we should teach qmp about that path as a place to put things if’when things go wrong Saul: part of OE-qa? RP: yes, the env var makes it into the datastore as a place to put things if set (OEQA_DEBUGGING_SAVED_OUTPUT). the only tricky part is we’re not setting it for all builds, but we can look into it Randy: with this last release (hardknott) the timing for when the branches were created (hardknott) in various layers was different this time around and it messed up our (WR) release schedule. could we have a policy on it RP: individual layers are up to individual maintainers, can’t create a policy Randy: i think the one for meta-oe got created a bit too early. could we make sure that doesn’t happen again? Armin: maybe ask Khem RP: with core we start the release branch early but then it only splits when there’s a diverging commit. then we also tag releases Armin: it was quite early with meta-oe this time TimO: it was noticed Bruce: we had to do some dancing this time Armin: there are lots of layers that don’t branch, so you just have to qualify against a specific SHA of their master, but then that can break when things move on RP: we have a tagging policy that has a “yocto” prefix and the hope was that layers would use those tags and that it would be uniform over the ecosystem Armin: use the yocto- ones or the hardknott-25 one? RP: not the hardknott-25 one, that’s linked to poky. it's something i've wanted to clean up for a while TW: couldn’t we link all layers _and_ bitbake too? why isn’t there a hardknott layer in bitbake? i thought i had asked about this in the past and was told that it couldn’t be done because they’re independent projects RP: you're thinking poky release numbering vs bitbake versioning. i’d like to get rid of the poky version numbers, that’s true, but we have been keeping up with separate between the layers and the tool (bitbake). Randy: there are tags between them RP: not sure why the point releases aren’t there in the bitbake tags. MichaelH maybe we could look into this? MichaelH: okay, we’re still following procedures from a while ago, so there’s no reason the procedures can’t be updated. we’ll look into adding the point release yocto tags into bitbake RP: then you'll find that there are "yocto-"-prefixed tags throughout the ecosystem (e.g. oe-core, bitbake, etc) i'm hoping all layers follow suit
|
|
|
|
Re: AppArmor with BusyBox
On Tue, Apr 27, 2021 at 3:34 PM Konstantin Aladyshev <aladyshev22@...> wrote: I've added `IMAGE_INSTALL += "findutils"` to my `conf/local.conf` I think it will be useful to dig a bit further and find out what option does it need from findutils package sometimes this could be solved by using compatible options etc If we find out that it has hard dependency on findutils then it should be added to apparmor recipe RDEPENDS
|
|
|
|
Re: Can layer maintainers add yocto-X.Y tags for yocto-3.3 and later?
Adding Robert, Hongxu and Qi who are likely interested in this topic
for future releases. On 2021-04-27 3:03 p.m., akuster808 wrote: On 4/27/21 9:48 AM, Randy MacLeod wrote:Yes. It's always bothered me that the tag wasn't there and nowHi,So the official starting point is what you are looking for? that oe-core/bitbake/... have been doing it, it would be nice to see other layers add the start-of-release tag. Usually, it's clear since you can find the first commit that is unique to the branch. It's often an update to a README or a layer.conf file that you can find using 'git merge-base' but the tag will make it simple to locate and in the case of meta-oe, where the branch came well before the oe-core release, the tag may not be the first commit on the 'hardknott' branch. Is there anyIt would be really nice to have but it's less important to me at least. What do you think of tagging dot upcoming releases for meta-oe/dunfell Armin? I don't expect 100% of layers to do this but hopefully maintatiner willOf course it's up to users to decide if they are going to followWhat's more important, tag or branch? Many layers hosted on git.yp.org listen users/submitters we'll get some traction. Also for those layers that don't want to maintain a branch they *might* not mind adding the tag to at least record where they were when Yocto branched. I suppose but once people are around for a while, they'll come toTagging in Poky has a meaning of a fully QA set of sources at a given understand how other layers don't go through the same QA cycle. Right.I think you mean 'Yocto Compatible'. Branching is already a requirementYes, this would be an additional requirement or request. The benefits that I see I've mostly already explained but I also like having a numerical uniform string that I can us to remember the pseudo-random branch names! :) Thanks for the comments Armin. ../Randy -arminShould it be a feature tested by the yocto compliance script? -- # Randy MacLeod # Wind River Linux
|
|
|
|
[PATCH yocto-autobuilder-helper] config.json: update variable for change in buildstats.bbclass
sakib.sajal@...
Signed-off-by: Sakib Sajal <sakib.sajal@...>
--- config.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.json b/config.json index fc83012..f82664c 100644 --- a/config.json +++ b/config.json @@ -59,7 +59,7 @@ "RUNQEMU_TMPFS_DIR = '/home/pokybuild/tmp'", "BB_HEARTBEAT_EVENT = '60'", "BB_LOG_HOST_STAT_ON_INTERVAL = '1'", - "BB_LOG_HOST_STAT_CMDS = 'oe-time-dd-test.sh 100'" + "BB_LOG_HOST_STAT_CMDS_INTERVAL = 'oe-time-dd-test.sh 100'" ] }, "templates" : { -- 2.25.1
|
|
|
|
Re: [OE-core] [PATCH 6/7] default-distrovars.inc: add wayland/opengl to default distro features
Otavio Salvador <otavio.salvador@...>
Em ter., 27 de abr. de 2021 às 13:10, Randy MacLeod
<randy.macleod@...> escreveu: Adding wayland seems Ok but forcing the opengl support doesn't seems a good default. Especially because we just also ensure software rendering is also wrong (slow or not). -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
|
|
|
|
Re: AppArmor with BusyBox
Konstantin Aladyshev <aladyshev22@...>
I've added `IMAGE_INSTALL += "findutils"` to my `conf/local.conf`
file, and it seems like it was enough. There weren't any build conflicts. Should the AppArmor recipe be upgraded in some way to indicate that it needs a full-featured findutils package instead of a busybox one? Best regards, Konstantin Aladyshev On Mon, Apr 26, 2021 at 5:08 PM Quentin Schulz <quentin.schulz@...> wrote:
|
|
|
|
Bitbake build failures?
jchludzinski
When I trying using bitbake to build openembedded Linux kernel, it dies with these download failures:
NOTE: Fetching uninative binary shim http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b (will check PREMIRRORS first)
WARNING: Failed to fetch URL http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b, attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"; export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export PATH="/home/jski/poky/scripts:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot/usr/bin/crossscripts:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/sbin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/sbin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/bin:/home/jski/poky/bitbake/bin:/home/jski/poky/build/tmp/hosttools"; export HOME="/home/jski"; /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P /home/jski/poky/build/downloads/uninative/5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b 'http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz' --progress=dot -v failed with exit code 4, output:
--2021-04-27 01:49:09-- http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz
Resolving downloads.yoctoproject.org (downloads.yoctoproject.org)... failed: Connection timed out.
wget: unable to resolve host address ‘downloads.yoctoproject.org’
WARNING: Disabling uninative as unable to fetch uninative tarball: Fetcher failure for URL: 'http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b'. Unable to fetch URL from any source.
WARNING: To build your own uninative loader, please bitbake uninative-tarball and set UNINATIVE_TARBALL appropriately.
|
|
|
|
Re: [OE-core] [PATCH 6/7] default-distrovars.inc: add wayland/opengl to default distro features
On 4/27/21 9:09 AM, Randy MacLeod wrote:
Cross-posting to yocto since this is of general interest.Randy, We (Wind River) already drop the x11 DF from some of our distros andThanks for bring this issue up. Err, are they going to check my BSP ; ) The layer index BSP list is long so waiting for feedback may not be practical. I think it may be more of an awareness and how can the BSP maintainers work around the default if there are issues rather than stopping this progress in core. I personal would rather see my layer break so that I will be forced to take action. I see this as being no different than when we update u-boot or the kernel. - armin ../Randy
|
|
|
|
Re: OpenEmbedded Happy Hour April 28 9pm/2100 UTC
Denys Dmytriyenko
Reminder, next Happy Hour is in one day - everyone is welcome to meet with
toggle quoted messageShow quoted text
fellow developers and chat about any interesting topics over Zoom. BYOB - bring your own beverage.
On Wed, Apr 21, 2021 at 04:04:25PM -0400, Denys Dmytriyenko wrote:
Hi, --
Regards, Denys Dmytriyenko <denis@...> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964
|
|
|
|
Re: Can layer maintainers add yocto-X.Y tags for yocto-3.3 and later?
On 4/27/21 9:48 AM, Randy MacLeod wrote:
Hi,So the official starting point is what you are looking for? is there any expectation to tag for dot release alignment? Of course it's up to users to decide if they are going to followWhat's more important, tag or branch? Many layers hosted on git.yp.org don't have the 'hardknott' branch. If the discipline to create a new branch is not their, I have a hard time believing 'tagging' will be high on their list. Tagging in Poky has a meaning of a fully QA set of sources at a given point of time. It may be interpreted by users that if a tag showed up in other layers, those layers are also fully tested. I think you mean 'Yocto Compatible'. Branching is already a requirement IIRC as the program is against a specific branch. -armin Should it be a feature tested by the yocto compliance script?
|
|
|