|
Canceled: OpenEmbedded Happy Hour December 29
Denys Dmytriyenko
Hi,
The next OpenEmbedded Happy Hour is being canceled due to the Holidays and since we had the last one on December 3. The next Happy Hour will take place on January 26 2022: https://www.openembedded.org/wiki/Calendar -- Regards, Denys Dmytriyenko <denis@...> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964
|
||
|
|
||
|
Minutes: Yocto Project Weekly Triage Meeting 12/16/2021
Trevor Gamblin
Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage Attendees: Armin, Jon, Joshua, Michael, Randy, Richard,
Ryan, Saul, Stephen, Steve, Trevor, Valerii ARs: - Randy to bump the M1s in the AB-INT list - Randy to remove AB-INT tempfs from the whiteboard field - Randy to move Medium+ M1s to later milestones - Everyone to review their Old Milestone bugs and move to new
milestones or close Notes:
No triage meeting on December 30th Medium+ 3.5 Unassigned Enhancements/Bugs: 76 (Last week
75) AB Bugs: 73
(Last week 67)
|
||
|
|
||
|
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.13.rc1)
Teoh, Jay Shen
Hi all,
toggle quoted messageShow quoted text
Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.13.rc1. We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1. OE-Core 2. BSP-hw Runtime auto test for following platforms: 1. MinnowTurbot 32-bit 2. Coffee Lake 3. NUC 7 4. NUC 6 5. Edgerouter 6. Beaglebone ETA for completion next Monday, Dec 20. Thanks, Jay
-----Original Message-----
|
||
|
|
||
|
Yocto Technical Team Minutes, Engineering Sync, for December 14, 2021
Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for December 14, 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, Bruce Ashfield, Daiane, Jan-Simon Möller, Jon Mason, Joshua Watt, Saul Wold, Steve Sakoman, Randy MacLeod, Richard Purdie, Scott Murray, Rephael C, Peter Kjellerstedt, Ross Burton, Michael Opdenacker, Armin Kuster, Nathan Glimsdale, Ryan Eatmon == project status == - 3.5 M1 (kirkstone) in QA - 3.1.13 (dunfell) to be built this week - maintenance for AB, updating SSDs and updating distros, next week (Dec 20-24) - significant improvements to patch count, some changes might affect other layers - CVE metrics improved for dunfell and master - rising AB-int issues (new high!) == discussion == RP: looked at more patches last week. removed some patches related to a MIPS platform (support for which was also removed from the latest kernel, see https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.16-Drops-MIPS- Netlogic). these patches were never added to upstream binutils. an SH4 gdb patch was also removed, not sure if it even works anymore. if users need these things, they can be re-introduced in separate layers if required, but not appropriate for oe-core going forward. Ross wins the award for most invasive change, and changes most likely to require changes in other layers, but these are good changes. seeing good trends: 50 patches removed, and 50 patched moved out of pending state. i’m still working with upstream gcc to get some patches merged and am still hoping to get some libtool patches upstream too. RP: re: AB-int issues: there is a recurring bitbake selftest issue with the runqueue tests that does have a fix ready. also lttng: there appear to be a number of tools issues going on but all logged as one bug. upstream has fixed some of the original bugs we reported, but there are some other things. it all appears to have started around june RP: AB downtime next week. there’s never a good time to do it. reimaging of most of the cluster. Michael has permission to replace all the OSes on all the workers (bring in new ones, remove old ones). it’s a good time to bring in new distros and get rid of older versions. for all we know the AB may never work again! (lol). if you have anything that needs to be preserved make sure to let us know. RP: it also means that if we’re going to have a 3.1.13 release, it has to be this week. SS: i’m ready, there is a small set of patches RP: so the plan is to get those in, then do the build? SS: yes. i don’t think there’s anything controversial there at all RP: there’s a chance the parts might not arrive in time, so the update to the AB might get delayed Randy: if we upgrade all the AB to SSDs then we won’t have a control to see how things go, other than historical data? does everyone only use SSD? are magnetic disks still important? SS: i’ve been SSD-only for a couple years now RP: conversely i only use spinning rust JPEW: i would expect that the intersection of people doing things as extreme as the AB and still using spinning disks is confined to just the AB Randy: you would be wrong (lol). at least half of WR is still using magnetic disks. however we do plan to upgrade. RP: i understand the desire to have a control, but that would add to the maintenance burden. we’ll have to see how it goes. we have 2 performance testing workers as well, one is running CentOS 7 and the other is running Ubuntu 16.04; those will also need upgrading as well (we’ve been putting it off for too long now). so we might end up with 2 more performance workers (that will run in parallel with the existing 2) or the existing ones might just get replaced. it’s up to Michael Randy: what about the ARM worker, any sign of that machine arriving? RP: there’s talk of it, but getting stuff into the US is not easy Saul: is anyone talking to Ampere? RP: the people involved are the ARM people, so they know what they’re doing Randy: will the ARM worker get an SSD as well? RP: it think it already has one. if it doesn’t then it will Ross: the ARM worker is pretty old hardware, unfortunately RP: we have 2, one is older but bulletproof. the other one is faster but has a tendency to report CPU temps that are high JPEW: i sent an RFC to switch the bitbake-worker to asyncio RP: i had a look. i hadn’t thought of using asyncio in bitbake-worker because generally it is one of the more self-contained bits of bitbake that generally actually works and i had wanted to leave it alone. the patch adds more lines than it removes. is it an improvement? JPEW: given what it’s doing, i don’t think it’s going to be more efficient. most of the time it sits waiting for things. the big advantage would be the maintainability. asycnio is easier to read than the polling loop it was doing. the adding of lines might just be my way of writing code. RP: i don’t object to it as such. if *i* had done the conversion then i could read that code more easily, however, since i didn’t do the conversion, it makes maintainability harder for me. that’s not a criticism of the work itself. the diff is too big, maybe easier to just look at the updated code JPEW: yes the diff is worthless. also, we could simplify it even more if we slightly changed the protocol between bitbake-worker and bitbake-server. would fit better with how asyncio works and what’s already included in asyncio (i.e. asyncio already knows how to hande reading text line-by-line, but we do a tagged XML thing, which i had to write explicitly). if we change it to be more like the hashserv protocol (newline-delimited JSON) then that would fit very well with asyncio. that would reduce the size RP: i think the data (that goes over the bitbake-worker to bitbake-server link) can have newlines in it, so we’d need an escape mechanism JPEW: yes, it’s pickled data. it wouldn’t have to be newlines, you could split on any character RP: also, there are some lines removing some multiprocessing locking, is that still safe for workers that call into multiprocessing? JPEW: the lock was never used in bitbake-worker itself, just the child processes. so i moved it to the child processes. the child processes have a pipe to bitbake-worker and i left the lock in the child process. so if they’re multithreaded (or whatever) they still have a lock when they write into the parent process. but each of them has a dedicated pipe into bitbake-worker parent process, so that doesn’t need locking RP: yes, fair enough. i need to look at the final code and think about it some more RP: i’m worried about the bitbake server process (i.e. not the worker but the cooker). i have a pile of bugs but the general theme is: someone presses Ctrl-C and bitbake is off doing something else and doesn’t respond. in general (by design) we tend to defer things off (tasks are run by bitbake-worker and not bitbake itself) the trouble is once the parsing occurs in sub-processes it can can starve the connection handling. i’m worried about the threading model (or lack thereof) in our design. there are 2 types of commands that can be run against the server: synchronous and asynchronous. but if something goes wrong in some of those synchronous commands then you can’t even send a stop event to the server. asyncio doesn’t necessarily help us with any of this stuff JPEW: in order for asycio to help, everything has to be done asynchronously. e.g. long-running tasks have to punt it to a thread (if it’s not I/O bound) RP: asyncio probably isn’t going to be the answer here, we might have to push some of this out to a separate cooker thread with the server running in its own thread and handling the actual UI and commands (etc) separately JPEW: we’ll probably need a hybrid approach: asyncio for the main loop, and long-running stuff in a thread RP: it’s one of the bigger problems we have with bitbake right now. if anyone has any ideas… RP: re: meetings over the holidays. i’m guessing we’ll cancel meetings on the 28th, and most will be back by the 4th of January? will enough people be around for a meeting on the 21st? <several>: i’ll be around RP: okay, we’ll cancel the 28th and keep the others Randy: i heard that someone got the terminal working in phosh? has anyone else played with phosh and got it working? JPEW: yes, mostly working. you can download the daily build Randy: i’ll give it a try shortly. is it something we’ll keep until after 3.5? or are we going to rip out sato and replace it with phosh for this release? JPEW: oh no, not this release RP: that’s a bad idea. we’ll run with sato for the LTS RP: any other patches in oe-core that we should be doing things with? we have some good success cases (e.g. the puzzles app in sato, binutils, gdb). tcp-wrappers is appearing on my radar; upstream is dead and we’re carrying about 15 patches. also the musl systemd patches need attention ScottM: the two people who would care are not on this call Ross: i think there’s been some improvement to systemd accepting musl patches ScottM: maybe alpine would drive this issue, but maybe not RP: there are 2 sets of issues with systemd and musl: 1) headers issue (which i think is relatively work-around-able) and i think systemd is willing to negotiate on some of those patches 2) pieces of c library are missing and by patching them out causes security holes, therefore we probably won’t see systemd accepting those. systemd has made it quite clear that they want to rely on those libc features and they’re simply not there in musl (as is my understanding) ScottM: they’re quite vocal about being fine with being very linux-centric RP: i want to get this done early in the cycle, rather than waiting for the week before feature-freeze
|
||
|
|
||
|
Re: spdx: Extending SPDX SBOMs for SDKs
Joshua Watt
On Wed, Dec 15, 2021 at 3:33 PM Andres Beltran
<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:do_create_spdx I don't know enough about the clang recipes to be able to help you much beyond that however
|
||
|
|
||
|
Re: spdx: Extending SPDX SBOMs for SDKs
Andres Beltran
+ Joshua, Saul
On 12/6/2021 6:54 PM, Andres Beltran
wrote:
|
||
|
|
||
|
Re: [meta-rockchip] [PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf
Trevor Woerner
On Wed 2021-12-15 @ 04:20:47 PM, Quentin Schulz wrote:
Hi Khem,I don't have strong feelings either way, but it does feel more like a patching operation than a configuration one.
|
||
|
|
||
|
[dunfell] hidden files/folders in WORKDIR
Joel Winarske
I'm finding that if I create files/folders (prefixed with '.') in WORKDIR, they don't get cleaned up with INHERIT += "rm_work". Is this a feature or a bug?
|
||
|
|
||
|
Re: [oe] Help with Inclusive Language in OpenEmbedded/Yocto Project
Saul Wold
On 12/6/21 17:01, Jon Mason wrote:
This email is a follow-up from the session held on Friday at theI am interested in helping out also. Another low hanging item might be changing the names of patches that include the offensive terms like the following (which I will add to the wiki: meta-openembedded/meta-oe/recipes-graphics/lxdm/lxdm/0001-lxdm.conf.in-blacklist-root-for-release-images.patch meta-openembedded/meta-oe/recipes-support/multipath-tools/files/0022-RH-Remove-the-property-blacklist-exception-builtin.patch oe-core/meta/recipes-extended/tcp-wrappers/tcp-wrappers-7.6/11_tcpd_blacklist.patch oe-core/meta/recipes-core/udev/udev-extraconf/mount.blacklist Can't really rename this one or we rename it in oe-core but it gets named back on the installed system. meta-secure-core/meta-integrity/files/ima_signing_blacklist Same as above meta-secure-core/meta-efi-secure-boot/recipes-bsp/efitools/efitools/Fix-the-wrong-dependency-for-blacklist.esl.patch We would have to re-generate the patches to have the subject match the fixed language. Sau! We will document the roadmap and everything else on the YP wiki page above.
|
||
|
|
||
|
Re: [meta-rockchip] [PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf
On Wed, Dec 15, 2021 at 7:20 AM Quentin Schulz
<quentin.schulz@...> wrote: sounds good.
|
||
|
|
||
|
QA notification for completed autobuilder build (yocto-3.1.13.rc1)
Richard Purdie
A build flagged for QA (yocto-3.1.13.rc1) was completed on the autobuilder and
is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.1.13.rc1 Build hash information: bitbake: f18b65d0b9a6b983d53bde491e1bf2ca56949444 meta-agl: 6d1ab9f3bb270a773ec5d2f7c8c856796833b559 meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c meta-aws: 9979cfa676105cb68cfadfdaeabf044d7c919319 meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac meta-intel: 87984115eb6ed1a4c17204629dcb100f6b76fe82 meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7 meta-openembedded: 69f94af4d91215e7d4e225bab54bf3bcfee42f1c oecore: 90a07178ea26be453d101c2e8b33d3a0f437635d poky: 795339092f87672e4f68e4d3bc4cfd0e252d1831 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.purdie@...
|
||
|
|
||
|
Yocto Technical Team Minutes, Engineering Sync, for December 7, 2021
Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for December 7, 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, Jasper Orschulko, Trevor Gamblin, Steve Sakoman, Philip Balister, Richard Purdie, Randy MacLeod, Peter Kjellerstedt, Jan-Simon Möller, Scott Murray, Alexandre Belloni, Tim Orling, Jon Mason, Bruce Ashfield, Ross Burton, Joshua Watt, Michael Opdenacker == project status == - 3.5-m1 (kirkstone) to be built this week - 3.4.1 (honister) out of QA and to be released - changes to check-layer script leads to improvements to layer README files - thanks to all for YPS last week - continue to remove local patches by sending upstream - rising intermittent issues with AB - SWAT faltering, large backlog of un-triaged issues == discussion == RP: Ross created graphs related to the changing number of patches and their state (from 2015 to now) http://www.burtonini.com/yoctometrics/ The patch status is clearly improving over time both in number and that they are generally moving upstream. 5 years ago we peaked at 1900 patches, today we’re at 1270-ish. It’s nice to note how much progress we can make when we put our resources towards it. Sometimes looking at a patch shows us that it is no longer required. Upstream is usually receptive, sometimes it’s just a matter of poking again. JPEW: i was working on meta-phosh and noticed that libsoup is all messed up now. there are 2 versions (v2 and v3) and you’re not supposed to mix-and-match. libsoup2 and 3 were both updated so that if they noticed the other one, they both hard fail (they call abort() on the process to kill it). previously things wouldn’t function correctly, now things won’t run at all. biggest offender is webkitgtk was upgraded to use libsoup3 but nothing else has been upgraded so anything links in webkitgtk crashes on startup. there are a surprising number of things in gnome that crash e.g. settings panel. Ross: probably easiest to add a packageconfig on webkit so distro maintainers get to pick JPEW: it looks like most things will probably switch to libsoup3 when they update to gtk4 (and won’t switch before then), but for now pretty much everything in meta-gnome is completely broken. currently libsoup3 is not used by anything other than webkitgtk Ross: probably should make libsoup2 the default for now to regress the breakage RP: sounds reasonable to me JPEW: at OEDVM we were talking about open-source projects getting Yocto compliance. i was working on meta-phosh but not sure what to do next. maybe next thing is to talk to the board? RP: not the board, talk to Nico. Nico is the gatekeeper for the compatibility process, and it goes to the TSC if required after. there are forms on the website, but the website is iffy, so if you fill in the forms and nothing happens, then reach out to Nico directly. it’s probably best to just reach out to Nico directly. RP: something that may be landing in the next few days, Ross is recommending that we remove libtool prefix. libtool is prefixed with an architecture prefix. this is something that OE and buildroot did early on and we’ve been carrying this for decades. there was a time when it looked like autoconf was going to mandate that build tools had the cross-compiler triplet prepended, but autotools looks dead now-a-days. ironically libtool rejected the patches Ross: everything it was trying to solve is now solved with recipe-specific sysroots, and host tools, etc. so everything should just work. any recipe that has to hand-code libtool work-arounds can all be removed now. i expect the fallout to be substantial, but the fixes will be to just remove stuff from recipes. does buildroot still do this? RP: not sure Ross: i don’t see any patches for libtool at all (in buildroot) RP: the cross-compile support in upstream libtool is broken; well, not broken but inefficient. but, as Ross says, it is obsolete now. Ross: lots of diffstat lines removed, but it will make the AB explode AlexB: buildroot has patches for libtool, even multiple versions (see support/libtool, not package/libtool) Ross: ah, i was looking in the wrong place RP: is supporting multiple versions of libtool not a path to madness? supporting one version is bad enough… Ross: it looks like it’s doing the same as our patches (i.e. fixing the relink thing) RP: yes, buildroot is patching for the the relink thing (which is something we do as well) but the prefix patch isn’t in buildroot Ross: i’ll clean this up and post it as an RFC at least RP: sounds good Ross: going back to the chart thing, there was talk a while ago about the LF having a centralized git monitoring/metrics thing? RP: LFX Ross: ah yes! is it still going? can we add our stuff into it? it would be nice to inject out patch data stuff there RP: they are still doing it, and there are developers actively working on it, but the people working on it have more pressing things to work on. so the answer is yes, but not now. there are lots of stuff i’d like to do this with, e.g. CVE metrics is another. it would be nice to find someone who would be interested in generating dashboard data for the project from what we’re producing. we have the ability to inject this stuff, we just need to generate it TimO: we need a data scientist Jon: i sent out an email about inclusive language, please read and respond RP: where? Jon: main yocto, oe-devel, oe-core. trying to get the ball rolling to see if it can land this release MO: i’m interested, it ties in with documentation RP: me too RP: Quentin sent a patch to rename… core-image-master (?) to golden instead. this is part of the QA test framework and was from a time when we had ideas about test controllers etc. i checked with the QA team and they aren’t using it. i did a double-take on that name, it’s not something i’ve used recently and there haven’t been any patches for it in ages. i had completely forgotten about its existence, despite being listed as the maintainer! is anyone using this code? JPEW: core-image-test-master ScottM: i had never heard of it before Ross: i almost ripped it out a few weeks back when i was doing a cleanup of the QA code. there is someone who is either using that code, or a derivative of it. i’ll copy them in on that thread so they can have an opinion. but if it’s not being used then it can probably be deleted. RP: rather than rename, i’m very tempted to just delete it. it’s not used and likely broken. even if someone is using it, there are probably better things they should be doing RP: there’s another breaking change to one of the tunes that we should probably fix before M1… Jon: A72? RP: yes, thanks. the crypto extension is enabled by default in the tune, but there’s now an rpi4 that has an SoC that doesn’t enable it. there are 2 ways to fix this: 1) leave the current tune as-is and create a -nocrypto variant 2) change the current tune to remove the crypto, then add a -crypto variant. not sure what path to take; i’m leaning towards the latter since that fits in better with the rest of the framework even if it is more disruptive. tune stuff is already complicated, i’d rather we keep the framework consistent. i also would prefer a better commit comment Jon: should i respin their patch with the updated wording? or comment on it to have them updated it? RP: either way; preferred to have it before -m1 Jon: just to be clear, this won’t break anything, it’ll just make it slightly less performant RP: right, and i think that’s reasonable ScottM: only meta-raspberrypi is affected by this? Jon: meta-raspberrypi is broken by this ScottM: oh right, after this change everyone else will have this off Jon: right. meta-raspberrypi, meta-rockchip, and possibly a freescale layer will be affected JPEW: so just manually re-enable it? Jon+RP: exactly Jon: yes, change to cortex-a72 + crypto RP: anyone using SH4? or anyone know of someone using it? Randy: nobody we know of (WindRiver) ScottM: nobody that I know of (AGL) MO: it’s an SoC for settop boxes (?) ScottM: maybe Khem would know RP: Khem is the one who patched it in the past, but not sure if he’s doing it because he’s using it (or knows someone using it) or if he’s just doing it because he’s aware of the patches RP: I came across this as part of the patch clean up exercise; there are some SH4 patches we’re carrying for glibc. we need to decide if we’re going to support this going forward. i’m under the impression that if someone wanted to get SH4 working, they would need more than these glibc patches. it would probably be better as an external architecture port/layer rather than odd, random hacks in oe-core ScottM: if Khem signs off on it then it sounds reasonable to me RP: i’ll talk to Khem Peter: i’ve noticed a problem with debug packages with honister. in june there was a change to remove the attempt-only for complimentary packages, so they are no longer called with skip-broken complimentary packages. this hid issues in our packaging. in our case we use gstreamer plugins (bad maybe) for srtp. the thing is we also have our own plugin for srtp. so we build the gstreamer plugin for srtp both as part of the gstreamer-bad package and from our own package. this works fine for the product images (since each plugin is put in its own package) but the debug symbols are all put in one package. meaning there is a clash for installing the debug symbols for both gstreamer and our package. is there any support for splitting the debug packages (similiar to how the main package is split), or are debug packages expected to all be all in one package? JPEW: are you asking if you can split? currently there is one debug package per recipe Peter: exactly. but because we are mixing plugins between 2 packages, the debug symbols clash. i would like the debug packages split just like the plugin packages are split. and i don’t know how the complimentary stuff works; and how it knows, for each plugin, that it should pick up the common debug package rather than the debug package that has the same name as the plugin package RP: it’s a good question. i’ve wondered about this in the past. yours isn’t the only scenario where you can hit this problem. the downside is the extra impact on the build. generating all these extra packages, and putting these extra packages into the package feed, etc.. will have an impact on the overall build and i’m not sure it will make anything more usable. it would fix some things, but cause other things. i also wouldn’t underestimate the amount of work involved to get this to work. RP: the easier fix is to make the files non-overlapping (by renaming) Peter: the problem is that our srtp is a drop-in replacement, so the plugins (files) are called exactly the same (they have to be) so you get the same file in both packages RP: you could make it a symlink (the debug symbols will be based on the original file, not the symlink), if you rename the file but made a symlink that might get around the issue Peter: interesting idea… RP: we’ve moving the goal-posts, but i think the symlink path would be easier TrevorW: honister-specific? Peter: yes, there was a change (june 28) in the package manager. previously, the complimentary packages were built attempt-only=true so dnf was called with the skip-broken option which ended up hiding the issue. it would ignore installing one of the packages at random. so previously there was a chance that symbols wouldn’t be there, and nobody would notice unless they were specifically needing those symbols. the honister change is an improvement since it makes it obvious when an issue comes up. ScottM: it would be nice to have the debug packages setup the same way other distros do, but if it blows up the build times, then that would probably not be worth it. it would be nice if someone had the cycles to prototype it so we’d have the data RP: it’s probably optimizable to some extent. we have some crazy build times for things like packaging ltp. for ltp it probably doesn’t matter, but for perl-modules it probably does. if you add more packages the build time scales badly. one of the implications would be separate debug symbols for each kernel module, which would at least double the number of packages in a kernel build Peter: for us we’d just do it for gstreamer, since that’s the only one causing us issues. in an ideal world everything would be handled the same RP: you can do that and the system will let you do that, but that’s not a change i’d take into core. currently the policy is to have 1 debug package per recipe, and that’s not something we’re about to change. separate debug packages will work, but will affect build times Peter: i could just remove the debug symbols for one of the packages, and hope nobody ever needs to debug it RP: separate debug packages will work, but we’re not going to change the policy Peter: i also have a similar problem with hardknott (which still has the keep-broken option enabled) so i can’t figure that out. similar, but not the same TrevorW: there was discussion around having more of a presentation + discussion style meeting each month at the OE happy hour Jon: possible, we have done it in the past, we’re open to it, but it’s hard to get people to do it (and having them do the prep). but having a YPS gives people something to shoot for. lots of work to do a presentation, OEHH is more informal. it would need someone or something to drive it and make it more formal. Paul Barker has done a couple show-and-tells informally at some OEHHs TimO: i like the spontaneous show-and-tell Jon: most people are trained to think in terms of conferences and doing presentations there. trying to do it informally might make it less likely to happen. we can take it to the board RP: i’ve been chatting with Khem and he says the SH4 patches are there because i wanted them in, so i guess i’ll remove them
|
||
|
|
||
|
Re: Using FreeRadius project on Yocto
On Tue, Dec 14, 2021 at 11:34 AM Rakesh Kumar <rakeshkumar0815@...> wrote:
just adding layer is not enough, you have to add it to your image as well via IMAGE_INSTALL or some other way as indirect dependency
|
||
|
|
||
|
Re: Yocto BUILD ENV
Monsees, Steven C (US)
So, I ran SDK build using “bitbake sbcb-defaults-full –k –c populate_sdk_ext”
Everthing builds under the SDK except 1 component … the intel-graphics-compiler-native/1.0.11-r0, which fails a few times for the header file reference shown below.
It also appears as though :
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/g++
Is pointer to the correct devtoolset-8 version
I feel as though I am missing something with regards to the EXT SDK env, but not sure what,,,
I have tried adding the “source /opt/rh/devtoolset-8/enable” to /etc/bashrc, /etc/profile, and have tried running “scl enable devtoolset-8 bash” prior to build… (all of which work correctly building the standard SDK, and my kernel image which are building in the IGC…
Sample error output:
| [63/565] /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/g++ -DCL_KHR_FP64_EXT -DGHAL3D=USC -DICBE_LINUX -DIGC_CMAKE -DIGC_EXPORTS=1 -DIGC_SPIRV_ENABLED -DINSIDE_PLUGIN -DISTDLIB_UMD -DLINUX -DNDEBUG -DNOMINMAX -DSTD_CALL -DUSC_EXPORTS=1 -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -DUSE_SSE3 -DUSE_SSSE3 -D_AMD64_ -D_COMPILER_DLL_ -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_IGC_ -D_SCL_SECURE_NO_WARNINGS -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/WrapperLLVM/include -IIGC/autogen -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../Common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/API -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../visa/include -IIGC/Release -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/ocl_igc_shared/executable_format -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/cif/cif/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler -isystem/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include -pipe -fno-exceptions -fdata-sections -ffunction-sections -O2 -fmessage-length=0 -march=corei7 -mstackrealign -fms-extensions -Werror -Wno-unused-parameter -Wno-missing-field-initializers -Wwrite-strings -Wno-long-long -Wswitch -Wno-sign-compare -Wno-unused-result -Wno-enum-compare -Wno-type-limits -Wno-ignored-qualifiers -Wformat -Wformat-security -Wno-extra -Wno-write-strings -finline -fno-strict-aliasing -msse -msse2 -msse3 -mssse3 -msse4 -msse4.1 -msse4.2 -Wno-unknown-pragmas -fPIC -D_FORTIFY_SOURCE=2 -fstack-protector -finline-functions -funswitch-loops -Wno-maybe-uninitialized -lrt -fno-rtti -fvisibility=hidden -fvisibility-inlines-hidden -std=c++14 -DNDEBUG -g -std=gnu++14 -MD -MT IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o.d -o IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -c /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/CShader.cpp | FAILED: IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o | /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/g++ -DCL_KHR_FP64_EXT -DGHAL3D=USC -DICBE_LINUX -DIGC_CMAKE -DIGC_EXPORTS=1 -DIGC_SPIRV_ENABLED -DINSIDE_PLUGIN -DISTDLIB_UMD -DLINUX -DNDEBUG -DNOMINMAX -DSTD_CALL -DUSC_EXPORTS=1 -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -DUSE_SSE3 -DUSE_SSSE3 -D_AMD64_ -D_COMPILER_DLL_ -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_IGC_ -D_SCL_SECURE_NO_WARNINGS -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/WrapperLLVM/include -IIGC/autogen -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../Common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/API -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../visa/include -IIGC/Release -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/ocl_igc_shared/executable_format -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/cif/cif/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler -isystem/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include -pipe -fno-exceptions -fdata-sections -ffunction-sections -O2 -fmessage-length=0 -march=corei7 -mstackrealign -fms-extensions -Werror -Wno-unused-parameter -Wno-missing-field-initializers -Wwrite-strings -Wno-long-long -Wswitch -Wno-sign-compare -Wno-unused-result -Wno-enum-compare -Wno-type-limits -Wno-ignored-qualifiers -Wformat -Wformat-security -Wno-extra -Wno-write-strings -finline -fno-strict-aliasing -msse -msse2 -msse3 -mssse3 -msse4 -msse4.1 -msse4.2 -Wno-unknown-pragmas -fPIC -D_FORTIFY_SOURCE=2 -fstack-protector -finline-functions -funswitch-loops -Wno-maybe-uninitialized -lrt -fno-rtti -fvisibility=hidden -fvisibility-inlines-hidden -std=c++14 -DNDEBUG -g -std=gnu++14 -MD -MT IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o.d -o IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -c /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/CShader.cpp | In file included from /usr/include/sys/stat.h:106, | from /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common/iStdLib/File.h:47, | from /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.hpp:42, | from /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/CShader.cpp:44: | /usr/include/bits/stat.h:106:31: error: expected unqualified-id before ‘[’ token | __syscall_slong_t __unused[3]; | ^ | /usr/include/bits/stat.h:164:31: error: expected unqualified-id before ‘[’ token | __syscall_slong_t __unused[3]; | ^
From: yocto@... <yocto@...>
On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, December 14, 2021 2:23 PM To: yocto@... Subject: [yocto] Yocto BUILD ENV
I am using a pre-installed tools on my linux development box for centos7, that being devtoolset-8…
Running “source /opt/rh/devtoolset-8/enable” allows me to build my bootapp, kernel, and the standard SDK without issues…, but there seems to be a problem when I go to build the extended SDK.
It appears to end up referencing the wrong/default tool set.
Is the something I need to set in my sdk-extra.conf (or one of the vcarious other configuration files) to make the extended SDK build aware of the environment dependency ?
/opt/rh/devtoolset-8/enable script does the following:
# General environment variables export PATH=/opt/rh/devtoolset-8/root/usr/bin${PATH:+:${PATH}} export MANPATH=/opt/rh/devtoolset-8/root/usr/share/man:${MANPATH} export INFOPATH=/opt/rh/devtoolset-8/root/usr/share/info${INFOPATH:+:${INFOPATH}} export PCP_DIR=/opt/rh/devtoolset-8/root # Some perl Ext::MakeMaker versions install things under /usr/lib/perl5 # even though the system otherwise would go to /usr/lib64/perl5. export PERL5LIB=/opt/rh/devtoolset-8/root//usr/lib64/perl5/vendor_perl:/opt/rh/devtoolset-8/root/usr/lib/perl5:/opt/rh/devtoolset-8/root//usr/share/perl5/vendor_perl${PERL5LIB:+:${PERL5LIB}} # bz847911 workaround: # we need to evaluate rpm's installed run-time % { _libdir }, not rpmbuild time # or else /etc/ld.so.conf.d files? rpmlibdir=$(rpm --eval "%{_libdir}") # bz1017604: On 64-bit hosts, we should include also the 32-bit library path. if [ "$rpmlibdir" != "${rpmlibdir/lib64/}" ]; then rpmlibdir32=":/opt/rh/devtoolset-8/root${rpmlibdir/lib64/lib}" fi export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32:/opt/rh/devtoolset-8/root$rpmlibdir/dyninst$rpmlibdir32/dyninst${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} # duplicate python site.py logic for sitepackages pythonvers=2.7 export PYTHONPATH=/opt/rh/devtoolset-8/root/usr/lib64/python$pythonvers/site-packages:/opt/rh/devtoolset-8/root/usr/lib/python$pythonvers/site-packages${PYTHONPATH:+:${PYTHONPATH}} export PKG_CONFIG_PATH=/opt/rh/devtoolset-8/root/usr/lib64/pkgconfig${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}
|
||
|
|
||
|
Using FreeRadius project on Yocto
Rakesh Kumar <rakeshkumar0815@...>
Hi Team, I am trying to build radius server with the use of Yocto project and looks like freeradius recipe is already included in meta-openembedded/meta-networking/recipes-connectivity/freeradius I have included meta-openembedded layer in my conf/bblayers.conf file and built core-image-base image. But I couldn't see anything related to radius server in my <workspace>/tmp directory "tmp/work/ccimx6ul/core-image-base/1.0-r0/rootfs/etc/init.d" Could you please let me know do I need to add anything specific to build radius server apart from using meta-openembedded recipe? I apologize if this is the wrong mailing list. Thanks much! Best Regards Rakesh kumar
|
||
|
|
||
|
Yocto BUILD ENV
Monsees, Steven C (US)
I am using a pre-installed tools on my linux development box for centos7, that being devtoolset-8…
Running “source /opt/rh/devtoolset-8/enable” allows me to build my bootapp, kernel, and the standard SDK without issues…, but there seems to be a problem when I go to build the extended SDK.
It appears to end up referencing the wrong/default tool set.
Is the something I need to set in my sdk-extra.conf (or one of the vcarious other configuration files) to make the extended SDK build aware of the environment dependency ?
/opt/rh/devtoolset-8/enable script does the following:
# General environment variables export PATH=/opt/rh/devtoolset-8/root/usr/bin${PATH:+:${PATH}} export MANPATH=/opt/rh/devtoolset-8/root/usr/share/man:${MANPATH} export INFOPATH=/opt/rh/devtoolset-8/root/usr/share/info${INFOPATH:+:${INFOPATH}} export PCP_DIR=/opt/rh/devtoolset-8/root # Some perl Ext::MakeMaker versions install things under /usr/lib/perl5 # even though the system otherwise would go to /usr/lib64/perl5. export PERL5LIB=/opt/rh/devtoolset-8/root//usr/lib64/perl5/vendor_perl:/opt/rh/devtoolset-8/root/usr/lib/perl5:/opt/rh/devtoolset-8/root//usr/share/perl5/vendor_perl${PERL5LIB:+:${PERL5LIB}} # bz847911 workaround: # we need to evaluate rpm's installed run-time % { _libdir }, not rpmbuild time # or else /etc/ld.so.conf.d files? rpmlibdir=$(rpm --eval "%{_libdir}") # bz1017604: On 64-bit hosts, we should include also the 32-bit library path. if [ "$rpmlibdir" != "${rpmlibdir/lib64/}" ]; then rpmlibdir32=":/opt/rh/devtoolset-8/root${rpmlibdir/lib64/lib}" fi export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32:/opt/rh/devtoolset-8/root$rpmlibdir/dyninst$rpmlibdir32/dyninst${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} # duplicate python site.py logic for sitepackages pythonvers=2.7 export PYTHONPATH=/opt/rh/devtoolset-8/root/usr/lib64/python$pythonvers/site-packages:/opt/rh/devtoolset-8/root/usr/lib/python$pythonvers/site-packages${PYTHONPATH:+:${PYTHONPATH}} export PKG_CONFIG_PATH=/opt/rh/devtoolset-8/root/usr/lib64/pkgconfig${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}
|
||
|
|
||
|
Re: [meta-rockchip] [PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf
On Tue, Dec 14, 2021 at 3:39 AM Quentin Schulz
<quentin.schulz@...> wrote: perhaps applying the sed expression via do_configure:prepend() is simple ? and maybe make it rk3399 specific with do_configure:prepend:rk3399 --
|
||
|
|
||
|
Yocto Project Status WW50`21
Stephen Jolley
Current Dev Position: YP 3.5 M1 Next Deadline: 6th Dec. 2021 YP 3.5 M1 build
Next Team Meetings:
Key Status/Updates:
Ways to contribute:
YP 3.5 Milestone Dates:
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@...
|
||
|
|
||
|
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.5_M1.rc2)
Teoh, Jay Shen
Hi everyone,
toggle quoted messageShow quoted text
Intel and WR YP QA is planning for QA execution for YP build yocto-3.5_M1.rc2. We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1. OE-Core 2. BSP-hw Runtime auto test for following platforms: 1. MinnowTurbot 32-bit 2. Coffee Lake 3. NUC 7 4. NUC 6 5. Edgerouter 6. Beaglebone ETA for completion this Friday, 17th of December. Thanks, Jay
-----Original Message-----
|
||
|
|
||
|
Re: echo and read shell script functions in post install script doesn't display messages
Alexander Kanavin
The postinst scriptlets are script fragments and not standalone scripts. Putting an interpreter to their first line will not work. Also, they are not running on an interactive console, but by a helper executor, so they have to be entirely automated. What is the problem that you would like to solve? Alex
On Tue, 14 Dec 2021 at 13:01, <sanjaycvr35412@...> wrote:
|
||
|
|