**** BEGIN LOGGING AT Fri Mar 12 03:00:02 2021 Mar 12 03:29:41 alephan: the fix for the configuration warning is pushed to the 5.10 kernel meta data. i tested on master and a hacked-up dunfell. Mar 12 05:04:21 zeddii: qemuppc64 defconfig needs some fixing seeing these warnings http://sprunge.us/fQS4Mq Mar 12 05:04:37 this is 5.10 kernel Mar 12 07:15:22 I want to use the MACHINE_FEATURES to be able to change the behavior for some features (enable/disable) between different builds. But for some reasons I cannot get get it to work when setting MACHINE_FEATURES += " myfeature" in local.conf. When debugging, I can see that the MACHINE_FEATURES list will not include myfeature. Assuming this is expected Mar 12 07:15:23 behavior, can I append MACHINE_FEATURES dynamically between different builds in some other way? Mar 12 07:50:06 good morning Mar 12 07:53:20 how can I include a specific driver for hardware in yocto? Mar 12 07:55:47 tralla: MACHINE_FEATURES is expected to be used in a machine configuration file, not local.conf Mar 12 07:56:14 mcburger: specific driver? please elaborate Mar 12 07:56:51 for example I have a sensor that communicates over spi, numbered m238.c and I want to include that driver Mar 12 07:56:55 mckoan Mar 12 07:57:04 just an example Mar 12 08:08:32 mckoan yeah, that makes sense, just that I thought I managed to use it from local.conf in the past. DISTRO_FEATURES seems to work better.. Any drawbacks of using DISTRO_FEATURES to dynamically change behavior between builds using the same sstate? Mar 12 08:17:45 mcburger: https://wiki.koansoftware.com/index.php/Howto_build_a_kernel_module_out_of_the_kernel_tree Mar 12 08:17:52 for example Mar 12 08:19:12 mcburger: https://youtu.be/gFSbwspPvTU Mar 12 08:19:55 even I'd avoid eSDK though Mar 12 08:23:33 mckoan Got the procedure, thank you! Mar 12 11:24:57 Thanks! Mar 12 11:47:10 does this ring a bell, anybody? Mar 12 11:47:19 https://www.irccloud.com/pastebin/VwoqgnFn/ Mar 12 11:47:35 (blocking io error / wakeup fd) Mar 12 12:06:23 is there a way to create a recipe skeleton with SUMMARY do_install() LICENCE etc with a commannd like recipetool ? Mar 12 12:10:24 jdrol: devtool add ? Mar 12 12:11:18 qschulz, thanks .. I don't understand is the odc I read devtool are from eSDK but without eSDK I have it installed Mar 12 12:11:54 jdrol: maybe http://yoctoproject.net/ Mar 12 12:12:16 has been passed to me, i'm not exactly convinced of it, but it has use cases. Mar 12 12:16:13 LetoThe2nd, yes it is nice ... but it is not exists with command lines ? Mar 12 12:17:42 jdrol: obviously not. Mar 12 12:17:54 Hi, I"m a member of the ELISA Linux Foundation project and am trying to build an ELISA demo system that is based on an agl platform.  For reasaons that i don't want to discuss, I'm using an OpenSuse Tumbleweed machine with glibc 2.33.  The pseudo build craps out with failed compiles because _STAT_VER has not been defined.  After a bit of Mar 12 12:17:55 investigation, I've found out that io/sys/stat.h has eliminated references to _STAT_VER in 2.33 (it was in 2.32).  The pseudo source code is littered with references to _STAT_VER, and according to the overview in the documentation in the overview, this is intentional. Note that OpenSuse Tumbleweed may be a bit obscure, but Ubuntu 21.04 is Mar 12 12:17:55 scheduled to upgrade to glibc 2.33. Questions: a) Is there an bug  tracking system where I can register this and b) any suggestions for work-arounds (I've already thought about using a virtual machine or chroot OS...) thc Mar 12 12:18:38 Johnmacgregor: theres a bugzilla, yes. Mar 12 12:18:49 uh, where Mar 12 12:19:27 Johnmacgregor: bugzilla.yoctoproject.org Mar 12 12:19:33 Johnmacgregor: as i would have to open google now and type "yocto project bugzilla", then pass the result to you, i'm convinced that you are totally competent to do it yourself :)= Mar 12 12:19:36 Johnmacgregor: otherwise you could use containers Mar 12 12:19:37 qschulz: hrhr Mar 12 12:19:48 https://github.com/garmin/pyrex/ is one example Mar 12 12:19:58 yeah, build in container is a standard approach these days. Mar 12 12:20:36 BTW diff 2.32 2.33 https://fossies.org/diffs/glibc/2.32_vs_2.33/io/sys/stat.h-diff.html Mar 12 12:32:37 Johnmacgregor: container as proposed or a buildtools tarball from yocto can help. the 2.33 changes need to be worked into pseudo and YP (master and also dunfell) Mar 12 12:46:53 >  i'm convinced that you are totally competent to do it yourself :)= ... Rumours of my competence have been greatly exaggerated, but I did find that a bug has been issued (and closed) in bugzilla. (14229).  Didn't find any helpful description or work-arounds, however.  OK, I'll try using the container or the buildtools tarball and try to rely Mar 12 12:46:54 on my ELISA / agl colleagues for further assistance.  Thx. Mar 12 12:49:40 Johnmacgregor: sometimes the Bugzilla number is in commit log so that might help you figure out what was needed Mar 12 12:52:28 RP ttps://www.irccloud.com/pastebin/VwoqgnFn/ Mar 12 12:52:32 oopsie. Mar 12 12:52:55 RP/rburton: https://www.irccloud.com/pastebin/VwoqgnFn (i guess this is related to my stuck build) Mar 12 12:54:06 LetoThe2nd: not seen that before... Mar 12 12:54:53 its docker-in-lxc and i guess its some combination issue. Mar 12 12:56:30 maybe also JPEW as our containerized build guru :) Mar 12 13:20:33 RP: Is there any problems with the patch I sent a month ago (pinged a week ago) to the openembedded-core list adding nativesdk-glibc-dbg to the uninative tarball? I have not seen it in master-next, and I have nor received any comments. Mar 12 13:35:20 Saur: I understand why you're asking for it, I don't really like it and I don't know what to do Mar 12 13:46:48 ndec: RP: I'm not sure if we want to manually document the bb.utils functions in the docs??? How do we make sure we keep them in sync with the actual code? Mar 12 13:47:08 i wondered about that.. Mar 12 13:47:13 ndec: RP: can't we just extract the Python documentation for those functions and have everything automatic? Mar 12 13:47:24 with sphinx we should be able to move docs closer to the code.. Mar 12 13:47:59 the problem is that the doc is not in the main repo.. Mar 12 13:48:58 qschulz: generally we'd consider those utils to be "API" so documenting them is probably reasonable but the "how" TBD Mar 12 13:49:34 RP: oh no, I'm convinced they should be documented. It's just that for me they should absolutely be documented where they are implemented. Which is usually (always?) the case right now Mar 12 13:50:03 but since they are documented there, why not get their documentation from the python docstring directly and use this so we're always up to date Mar 12 13:55:30 qschulz: question of someone making that all work nicely I guess Mar 12 14:01:08 RP: Well, it is necessary to be able to use uninative and be able to debug/memcheck native applications. And it is just a few % size increase, so to me it should not be controversial. Mar 12 14:10:18 Saur: how many times have I heard "just a few % increase" with that tarball. It used to be about 5MB :( Mar 12 14:15:27 'Morning everybody Mar 12 14:17:06 RP: Well, I obviously cannot say how many times you have heard that. ;) But what I do know is that it is not possible to use it and still use valgrind on native applications as valgrind requires that some of the glibc symbols are available to even start the application. Mar 12 14:22:26 I'm bit confused: i'm a happy user of a SDK that uses GCC for crosscompilation. I woud like to have available also Clang (just to have a second opinion on my code), so i added to my sdk nativesdk-clang, but the resulting clang executable produce x86_64 executables. Am I missing the right package? Mar 12 14:23:22 LetoThe2nd: I've never seen that before that I can recall... I suspect that means that the thread handling the signal is blocked/starved and can't handle the queue in a timely manner Mar 12 14:25:08 Saur: If I accept the patch, we'll get people moaning about the size, people will complain there is no way to configure it, we'll need to create split binaries and a mechanism to turn on/off debug symbols and so on. I appreciate your problem. I just also know where the path leads Mar 12 14:25:26 Saur: I can't win :( Mar 12 14:30:18 RP: ndec: I should have commented on the ML, will do Mar 12 14:33:33 RP: I honestly have a hard time seeing that a 200 kB increase to a 5 MB tar ball would cause a huge raucous, but I may be naive. Instead the focus should be on possibilities it opens up that were previously blocked. Mar 12 14:34:45 It's not as anyone has complained about the suggested patch on the ML. Mar 12 14:44:43 Saur: it would be an interesting experiment to propose some really bad patches and see if they do get review feedback Mar 12 14:47:19 RP: True, it is easy to ignore patches on the list if they are not directly related to what you do yourself, so maybe the lack of comments cannot be taken as acceptance of a patch. On the other hand, it is all we have. Mar 12 14:48:20 And I did state in the patch mail that the size increases by 4% (200 kB), so it was not like I tried to hide the fact. Mar 12 14:48:51 Saur: I'm not claiming it was hidden Mar 12 14:48:56 I know. Mar 12 14:49:29 But I meant that if anyone cares about the size of the tarball, the facts were out in the open. Mar 12 14:50:28 Saur: Well, I can't really reject it so I'll just have to merge it Mar 12 14:51:42 RP: Well, I guess the worst that can happen is that someone actually complains about it, and then brings arguments as to why it was a Bad Idea(tm) to do this. Mar 12 14:53:08 Saur: well, there is work this change triggers as we'll need a new uninative release (which doesn't currently have automated testing), and it will end up backported to all the stable branches as we need to keep uninative in sync Mar 12 14:53:22 Saur: so I'm not sure that is the worst Mar 12 14:53:51 Saur: not your problem though, becomes mine and the stable maintainers Mar 12 14:54:50 RP: Sure, not much I can do to help you there, I'm afraid. Mar 12 14:56:51 Saur: I think I have wider concerns that a growing number of people are just relying on me to get a lot of things right and I'm not sure I'm going to, I'm stretched too thin Mar 12 15:03:50 Saur: Is it only glibc-dbg in the SDK because that's the only meaningful library in uninative? (e.g. why wouldn't you want the debug symbols for everything in uninative?) Mar 12 15:04:33 JPEW: I'm not following you? Mar 12 15:07:21 Saur: nativesdk-glibc-dbg seems specific; are the rest of the -dbg packages for things in uninative unnecessary? Mar 12 15:09:51 JPEW: Well, my goal was to make it possible to run valgrind on native applications, and valgrind requires that some of the debug symbols from glibc exist to even start. Mar 12 15:10:52 Saur: Right. I guess I'm wondering if its possible to publish a separate -dbg tarball (like we can do with a rootfs) for uninative that includes all the debug symbols for it Mar 12 15:11:11 fair warning: I don't even know if that's possible or practical Mar 12 15:11:39 Saur: Then you could get everything, not just glibc symbols Mar 12 15:12:04 JPEW: Me neither. I just know there is a lot of magic going on behind the uninative support. Mar 12 15:15:16 JPEW: definitely possible, would be a bit of work to pull together Mar 12 15:51:35 ah, mailing list roulette, how I love thee. Where does this poky .gitignore update go? https://paste.debian.net/1189059/ Mar 12 15:56:53 paulg: poky@lists.yoctoproject.org I think Mar 12 16:04:54 bitbake does have its own .gitignore as an independent repo outside of poky, so I was leaning towards making the change there, and letting RP do the path munging as part of a pseudo cherry pick... Mar 12 16:06:27 paulg: I frequently find it unfortunate that .gitignore doesn't let you include other files Mar 12 16:06:56 paulg: should go to the bitbake list Mar 12 16:06:57 paulg: Although.... I think bitbake could have it's own .gitignore and it would be respected Mar 12 16:11:55 JPEW: Well, you can have a .gitignore file in any directory in a repository, so the .gitignore from bitbake could just as well have been left there when merging it into the poky repository. Mar 12 16:13:06 (Which is basically what you said in your last sentence...) Mar 12 16:15:34 bitbake/doc/.gitignore managed to find its way from bitbake into poky (69ed72025ad poky / 84ccba0f4a BB) Mar 12 16:17:23 anyway - sent. https://lists.openembedded.org/g/bitbake-devel/message/12101 Mar 12 16:21:11 Hi, does anyone here use go.bbclass and know if it is up-to-date? I am having troubles with getting it to work. Mar 12 16:31:32 Hi team Mar 12 16:32:07 have questions in adding user/group through yocto recipe file Mar 12 16:49:25 re: Running rootless X on a raspberry pi 4. I was able to narrow down the issue, drmSetMaster runs an ioctl that requires root, so either xinit needs root here, or some other mechanism needs to call drmSetMaster on our behalf... and it looks like systemd-logind has a mechanism to be able to intercede in such a manner. Mar 12 16:50:20 but the logs indicate an issue when a non-root user runs xinit... and the systemd-logind integration isn't healthy Mar 12 16:52:52 Spooster: I run wayland, not X, but still rootless... when I was doing it I had to have systemd allocate a TTY for compositor service Mar 12 16:53:25 Spooster: Which was broken when not use polkit with systemd, and we had to subsequently patch Mar 12 16:54:02 Look at meta-graphics/wayland/weston-init/weston.service Mar 12 16:54:08 paulg: merged, thanks Mar 12 17:04:36 What I'm hearing, is that I should consider switching to wayland Mar 12 17:07:54 JPEW: Do you run Wayland in x? DISTRO_FEATURES_append = " wayland x11" Mar 12 17:08:01 or just Wayland proper somehow? Mar 12 17:08:40 Spooster: just wayland Mar 12 17:09:19 We run weston in the fullscreen shell, and they our "special sauce" application runs as a fullscreen client Mar 12 17:09:19 RP, \o/ Mar 12 17:09:56 Spooster: Our application can also run in the normal weston desktop for development, but we don't do that in production :) Mar 12 17:10:08 I mean... our app is mostly chromium --kiosk... with some python behind the scenes so that sounds sufficient for what we're after as well Mar 12 17:10:45 Spooster: Ya, I'd give it a try. Last I looked, chromium wayland support was spotty, but that was a few years ago. It may be better Mar 12 17:11:38 Spooster: Ya we actually run WebKit as a wayland client of our "special sauce" application (our app is both a client of weston, and a compositor for it's own clients.... wayland is awesome!) Mar 12 17:12:14 Just trying to parse "How to do a Wayland instead of an X" in our kas.yml... it's been a fun two weeks moving to Yocto over pi-gen Mar 12 17:12:23 everything is a bit... "nuanced" we'll say Mar 12 17:13:18 Spooster: DISTRO_FEATURES += "wayland" IMAGE_INSTALL += "weston-init" is a start Mar 12 17:14:08 I think that should "just work" on at least gatesgarth.... but YMMV as always Mar 12 17:15:46 dunfell >~> Mar 12 17:16:30 Spooster: It *might* work there (we use dunfell, but I backport stuff regularly) Mar 12 17:16:37 * Spooster queues Startrek's opening Mar 12 17:17:30 Spooster: More data needed.... which Star Trek? TOS? TNG? DS-9? Animated series? Voyager? Lower Decks? Mar 12 17:18:03 Was thinking TOS... Mar 12 17:18:43 I'm unfortunately not much of a trekkie... just know enough to know that I'm in some sort of unexplored final frontier Mar 12 17:41:10 we have the poke/meta layer available, which provides recipes-graphics... but bitbake can't seem to find any recipes that provide weston-init Mar 12 17:41:19 poky/meta* Mar 12 17:42:54 ope... just flopped names of things... wayland-init doesn't exist... weston-init does... /ignore Mar 12 19:47:13 is meta-darwin (http://git.yoctoproject.org/cgit/cgit.cgi/meta-darwin/) a layer to create the "toolchain" for the darwin processor family? Mar 12 19:48:40 it's description is given as an "SDK". is SDK == toolchain (at least in this case)? Mar 12 19:49:50 darwin is the name of the Open Source components of MacOS X. Mar 12 19:50:14 https://en.wikipedia.org/wiki/Darwin_(operating_system) Mar 12 19:50:47 yates: I beleive it's supposed to make an SDK that can run on MacOS X, but I'm pretty sure it's unmaintained and defunct Mar 12 19:51:23 correct Mar 12 19:52:21 what's the difference between the terms "SDK" and "toolchain"? Mar 12 19:52:36 ok, thanks fray/JPEW Mar 12 19:52:44 Software Development Kit. things that run an on OS to produce software to target 'something' Mar 12 19:52:54 toolchain, binutils, gcc, gdb, and maybe libc Mar 12 19:53:22 An SDK usually includes a toolchain, but a toolchain may not have everything required to build working osftware Mar 12 19:53:33 ok that is making more sense Mar 12 19:54:47 would an SDK provide a native toolchain? e.g., in the case of darwin, it's native, right? Mar 12 19:55:46 and SDK can include one or more toolchains. So a darwin SDK MIGHT include a native toolchain for Darwin, but would likely include a toolchain and other software used to build 'stuff' on a darwin OS host machine.. Mar 12 19:56:00 i guess where i'm going with this is, where do the toolchain definitions belong? in a layer entitled the SDK? or in a BSP layer? or some other way? Mar 12 19:56:42 Most toolchain definitions are in the core, since they are fundamental to the system. Overriding the core, belongs in a layer.. sometimes BSP, sometimes are specific, sometimes something else.. Mar 12 19:57:00 at Xilinx, we have a meta-xilinx (repository) with a meta-microblaze layer that provides the microblaze compiler support Mar 12 19:57:12 before meta-microblaze existed, it was part of the layer meta-xilinx-bsps Mar 12 20:03:30 fray: what do you mean by "the core"? Mar 12 20:03:56 everything in the meta layer? Mar 12 20:13:57 stupid question? Mar 12 20:15:22 is "toolchain" largely equivalent to binutils? Mar 12 20:24:18 btw, these aren't willy-nilly. i'm defining such terms in my kb-yocto (yocto knowledge-base) document for my own sanity and future reference. Mar 12 20:34:54 Do we have a patch info/metadata gathering tool in oe-core yet? Thinking show filename, modified files, plus the patch metadata, subject, sign offs, etc Mar 12 20:46:23 could someone please define what "the core" means? Mar 12 20:50:12 that doesn't mean anything without context Mar 12 21:07:05 kergoth: re: fray's statement at 14:56 (EST) Mar 12 21:10:21 yates: I think that's referring to OE core Mar 12 21:19:49 JPEW: ok - thank you. Mar 12 21:52:54 Given an upstream Makefile with CC=gcc in it, is there any guidance on the "right way" to override CC? Using EXTRA_OEMAKE += 'CC=${CC}' breaks make because of the arguments. Mar 12 21:53:07 I can patch the Makefile, but was hoping it could be solved more simply in the recipe itself. Mar 12 21:59:30 mouser_: What arguments? Mar 12 22:04:26 mouser_: just quote it. EXTRA_OEMAKE += 'CC="${CC}"' for example Mar 12 22:15:54 kergoth: Thanks, that solved it. Mar 12 22:16:40 JPEW: In my case, the extra arguments (beyond the compiler) were: -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/redacted/yocto/tmp-glibc/work/core2-64-redacted-linux/redacted-recipe/1.1.1-r0/recipe-sysroot Mar 12 22:17:33 The disconcerting thing about this is that doing a "CC=gcc" in a Makefile does not (appear to) trip any of the insane.bbclass validators. Mar 12 22:19:12 So you end up using the host's /usr/include, etc instead of the build sysroot. Mar 12 22:37:18 the compiler you used doesn't have include poisoning Mar 12 22:37:36 ohh sorry read that wrong.. CC=gcc -- ya not a lot that can be done if you are targeting same as the host Mar 12 22:38:13 this is part of the reason why any time I build stuff, I always target an architecture tht doesn't match my builder for verification of the packaging Mar 12 22:38:30 True. If I was targeting som eother architecture, it would have broken earlier. Mar 12 22:39:29 I feel like CC=gcc may be an anti-pattern for Makefiles, but I am sure there are good reasons why I am wrong. Mar 12 22:40:13 most of the time we end up with Makefiles that have CC = gcc, but the makfile is called with make CC=mygcc Mar 12 22:40:30 so you can't just search the Makefiles, as they can be (and usually are) overridden on the command line Mar 12 22:40:51 Fair. Overriding is easy. It was not obvious to me when I was packaging something upstream. I know better now of course... Mar 12 22:41:38 Is it worth a new type of insane.bbclass check of the compiler if BUILD_CC is not being used? Or does that get us into a tarpit? Mar 12 22:42:08 likely into a tarpit. There are resaons why build_cc isn't used occasionally.. i..e building a smaller host helper app Mar 12 22:42:51 searching logs or output and warning is certainly an option -- but I'd suggest the warning would be off by default or if on, needs an easy way to disavble Mar 12 22:45:26 I am bumping us up from thud to gatesgarth (or hardknott depending on a number of other factors) here in a few weeks, so I may drop that idea into the backlog and play around with it. If it works, I can see about submitting a patch. Mar 12 22:46:04 sounds good.. Mar 12 23:08:16 I am patching the dts used by u-boot, but it has no effect, at the point where I suspect u-boot may not be using it after all. Would somebody have insights on how I could figure that out? I tried a clean build (removed build/tmp and cache-sstate and rebuilt the image) and it did not have any effect Mar 12 23:22:52 is there a manufacturer database for yocto? i need to check if my layer name is in-use: meta-apex-semi-usa Mar 13 00:15:45 yates: that's no official registration or the like that I've ever heard of. There's a database at layers.openembedded.org that you can submit your layer to for people to be able to look up Mar 13 00:19:14 halstead: I am stills seeing error.yp.org isse Mar 13 00:19:28 * khem < https://matrix.org/_matrix/media/r0/download/matrix.org/MvGjPxdvnGldHuozrjpaOeJo/message.txt > Mar 13 00:19:46 Thanks khem looking now Mar 13 00:20:42 I just uploaded my error file here https://uclibc.org/~kraj/error_report_20210312175543.txt Mar 13 00:20:51 it worked well few days ago Mar 13 00:22:28 btw. I am carrying a patch https://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-11&id=159cb9fcca93bd53a0bfc4f7ec2617acce71c20d Mar 13 00:23:10 which fixed similar issue in past but this patch is not applied upstream so I was carrying it locally, but now same error with this patch included is happening so something else changed too Mar 13 00:32:13 halstead: I am seeing it from several machines from different networks Mar 13 00:32:26 but my distro is common Mar 13 00:36:48 khem, I was not testing the receipt of errors. I can probably reproduce with this. Mar 13 00:37:36 ok. are you able to reproduce with my errors.txt ? Mar 13 00:46:46 khem, Yes. I believe I've found the issue (space and open file handles) and resolved it. Thank you for the additional information. Mar 13 00:47:28 cool should I retry on my end ? Mar 13 00:48:21 ah cool its working !! thanks halstead Mar 13 00:48:34 khem, Yes. Please retry if you can. Mar 13 00:48:51 % send-error-report -y error_report_20210312175543.txt Mar 13 00:48:51 Preparing to send errors to: errors.yoctoproject.org Mar 13 00:48:51 Your entry can be found here: https://errors.yoctoproject.org/Errors/Build/118398/ Mar 13 00:52:02 Great. Thank you again khem. Mar 13 00:52:20 np thanks for fixing it, now Mar 13 00:52:35 I can send the links back to developers :) **** ENDING LOGGING AT Sat Mar 13 03:01:36 2021