**** BEGIN LOGGING AT Thu Mar 11 02:59:57 2021 Mar 11 04:16:30 RP: a WIP patch for wrapping pmu-events.c in perf is in your inbox. what a pain. Mar 11 04:16:37 * zeddii calls it a day Mar 11 07:27:39 hello guys ! I've a question for you ! Mar 11 07:28:15 Which is, in your opinion, the best way to keep track of the software version of a yocto project ? Mar 11 07:28:46 Let's say, I need a way to know which is the "build number" of the custom yocto project from the linux user space Mar 11 07:34:33 thekappe: e.g. use the os-release recipe Mar 11 07:37:46 derRichardm thanks, never heard aboout that Mar 11 07:58:28 @thekappe: cat /etc/version might be what you want Mar 11 08:01:13 @thekappe: you can also add additional variables to /etc/build which might customized look like that:: https://pastebin.com/LVcjZx2E Mar 11 08:30:25 HI guys Mar 11 08:30:39 do_kernel_metadata: [NOTE]: defconfig was supplied both via KBUILD_DEFCONFIG and SRC_URI. Dropping SRC_URI defconfig Mar 11 08:31:14 how can i make sure that the kernel uses my defconfig file referred by the .bbappend file with SEC_URI ? Mar 11 08:36:15 RobertBerger, thanks ! Mar 11 08:54:21 RP: seeing https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/1028 on AB it seems pseudo might be aborting, is there a way to collect the pseudo logs ? I have seen this happen few times now on AB on this recipe Mar 11 09:10:28 hi all .. i have encountered a problem with the number of inodes Mar 11 09:11:21 i see that in the /tmp folder a lot of stuff is created and not deleted anymore Mar 11 09:11:26 is that a know behavior? Mar 11 09:11:39 can I configure somewhere to delete these files Mar 11 09:12:23 khem: there is a patch in master-next which is meant to do that? Mar 11 09:12:55 zeddii: thanks, I'll give it a try. It looks like it was painful! Mar 11 09:13:39 background .. I have a "small" tmp partion with 2GB and 131072 inodes. the default configuration for in local.conf for BB_DISKMON_DIRS for tmp is STOPTASKS,/tmp,100M,100K Mar 11 09:14:50 hthiery[m]: that sounds soemwhat wrong, placing a build on /tmp if you only got 2G there. Mar 11 09:15:57 LetoThe2nd: I do not know why in /tmp files are created Mar 11 09:16:04 my build dir is somewhere else Mar 11 09:16:27 hthiery[m]: then find out if somethign whacks your pathes. Mar 11 09:16:32 there are a lot of "_tmp2314130238628230366" folders Mar 11 09:18:37 medaliyou: override KBUILD_DEFCONFIG by setting it to "" ? Mar 11 09:19:22 thank you , @q helpful as ususal Mar 11 09:19:29 LetoThe2nd: can you confirm that yocto should not create files in /tmp Mar 11 09:19:41 qschulz_ Thank you Mar 11 09:28:19 hthiery[m]: it will create files in /tmp but they should be transient and not be too large or there for long Mar 11 09:37:58 RP: but in my case the STOPTASK will hit. I see that after a successful build with bitbake the files will stay Mar 11 09:38:53 hthiery[m]: any clue which piece of software is creating them? Mar 11 09:39:41 RP: your last build from the master-next branch raised lots of errors! Mar 11 09:39:57 RP: /tmp/_tmp995249292676025234# classes/com/google/devtools/ Mar 11 09:40:55 RP: does this give you any hint Mar 11 09:42:40 RP: I see around ~3500 directories like _tmp Mar 11 09:44:54 kmaincent: I think two issues, the createrepo-c upgrade had patch fuzz and the gnu-efi upgrade broken systemd-boot. I've dropped those two Mar 11 09:45:03 hthiery[m]: what is in them? Mar 11 09:45:18 hthiery[m]: I'm not aware of anything from just the name Mar 11 09:45:48 RP: https://pastebin.com/raw/2sD448c1 Mar 11 09:46:02 RP: this are just some few directories Mar 11 09:46:33 hthiery[m]: looks like modules of some kind but I don't recognise them Mar 11 09:48:50 RP: strange Mar 11 09:49:22 RP: but all are in classes/com/google/devtools Mar 11 09:50:05 maybe something in grpc going amok? what kind of build is this? Mar 11 09:50:46 LetoThe2nd: is this question to me? Mar 11 09:51:16 Are underscores fine in bbclass names? Mar 11 09:53:03 jmiehe: i think they are, but it seems that dashes are preferred: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes Mar 11 09:55:57 LetoThe2nd: I see, but I can't use EXPORT_FUNCTIONS with dashes ~ Mar 11 10:17:49 jmiehe: most likely you don't need EXPORT_FUNCTIONS Mar 11 10:17:57 do you know what it does? Mar 11 10:21:58 rburton: it packs a function, puts it on a truck, waits 2 or 3 weeks at customs and then goes on to a customer. Mar 11 10:22:08 only three? Mar 11 10:22:46 rburton: well, unless you're starting in the UK, obviously. Mar 11 10:29:05 jmiehe: underscores are fine Mar 11 10:29:27 jmiehe: dashes have problems with shell so underscores should really be preferred Mar 11 10:31:38 rburton: I have buildsystem.bbclass which defines do_compile. afaik, EXPORT_FUNCTIONS and defining buildsystem_do_compile instead resolves problems with multiple inheritance Mar 11 10:32:51 I had a look at cmake.bbclass for reference Mar 11 10:34:11 if you expect people to want to overlay and do multiple inheritance then yes. uncommon though. Mar 11 10:36:13 rburton: so it's preferred to just define do_compile and expect use of _append in recipes? Mar 11 10:37:41 jmiehe: the system was designed to let people avoid that by using EXPORT_FUNCTIONS but most people don't. I'm undecided if that is a good or a bad thing Mar 11 10:40:23 RP: "most people don't" is in this case reason enough for me to go with my gut: the class name feels more consistent using a dash, so I'll just define tasks in recipe and use _append where necessary. Mar 11 10:40:52 … define tasks in recipe → define tasks in class Mar 11 10:41:45 jmiehe: depends if you expect people to need to construct do_compile from bits. autotools does use export modules but almost nobody uses autotools_do_compile, and there's only a few users of do_compile_append. Mar 11 10:41:58 jmiehe: FWIW we're planning to start phasing out dashes in class names due to the shell issue Mar 11 10:42:17 jmiehe: I like dashes too but they don't work with shell Mar 11 10:42:41 seriously, whenever i read the word "undecided" my brain associates with "Undecided Adrian" from the Smoking Gnu https://discworld.fandom.com/wiki/The_Smoking_Gnu Mar 11 10:44:16 RP: what about poky/meta/classes as linked above? there's like an awful lot of dash-classes in there. Legacy? Mar 11 10:45:30 jmiehe: yes. There is a bug discussing a plan to list the ones we have and stop new ones Mar 11 11:11:44 I am coming back with my question about deactivating SELinux. I have made sure that selinux is not in the environment variables DISTRO_FEATURES and IMAGE_INSTALL. I only have it in DISTRO_FEATURES_FILTER_NATIVE=" selinux". But I can still see the folder /etc/selinux showing up in myimage/1.0-r0/rootfs-original. That is not what I expected. Mar 11 11:12:15 is there any other variable where I have to remove selinux? Mar 11 11:19:46 chrysh: https://docs.yoctoproject.org/ref-manual/variables.html#term-DISTRO_FEATURES_FILTER_NATIVE is not what you want Mar 11 11:19:51 it only applies to native recipes Mar 11 11:20:11 ah sorry, misread Mar 11 11:20:13 please ignore :) Mar 11 11:20:51 When I add those to lines to my local.conf, selinux is removed in my image: IMAGE_INSTALL_remove += "selinux" Mar 11 11:20:54 DISTRO_FEATURES_remove += "selinux" Mar 11 11:20:57 any idea why? Mar 11 11:22:43 RP: and others how have an idea on this. We are just discussing on SPDX headers for bb and bbappend files in our layer. This starts to make me wondering what the view from you is on that. I see them in scripts but not in bb recipes (even if they could contain python functions or more) Mar 11 11:22:47 chrysh: is selinux actually present or is it just some config from some individual piece of software? Mar 11 11:23:00 Was that discussed before and I have not found it? Happy for a pointer. Mar 11 11:23:10 oO( why do people add things in the first place just so they can remove them laters in local.conf? i'll never get it. ) Mar 11 11:23:31 LetoThe2nd: vendor distros/machines, you never know what's going on :/ Mar 11 11:23:33 stefan-schmidt[m: Not sure there was documented discussion, I have certainly thought about it and my worry was the meaning of it in a recipe isn't clear Mar 11 11:23:57 qschulz: copy the best, leave out the rest. Mar 11 11:24:04 * LetoThe2nd declares yocto chant #4 Mar 11 11:24:18 stefan-schmidt[m: it is unclear whether the license applies to the recipe itself, the patches or the whole piece of software. It isn't the latter but it could confuse things Mar 11 11:24:32 RP: yeah, we also are unclear on copyrightable or not. Really depends on the recipe. It should have no influence on the license of the handled code though, right? Mar 11 11:24:53 stefan-schmidt[m: well, yes and no :/ Mar 11 11:24:56 I would say it really only is about the meta build part Mar 11 11:25:06 patches and the original code are different Mar 11 11:25:09 stefan-schmidt[m: I think adding them will confuse a lot of people Mar 11 11:26:02 stefan-schmidt[m: I think a recipe is copyrightable and we probably should have copyright headers Mar 11 11:26:12 a minority of recipes do Mar 11 11:26:55 RP: we could clarify the meaning for these headers in a document. But I fully understand that this legal part is no joy. :-) Mar 11 11:27:20 stefan-schmidt[m: we probably do need to do that. I started with the easier bits (scripts and code) Mar 11 11:27:54 stefan-schmidt[m: adding license headers to much of the code in git.yoctoproject.org wasn't fun :/ Mar 11 11:28:08 RP: yeah :/ Mar 11 11:28:15 stefan-schmidt[m: fancy proposing a document? Mar 11 11:28:24 RP: but its good to understand your position on this Mar 11 11:28:41 I feared you would ask that. :-) A fair point :-) Mar 11 11:28:49 stefan-schmidt[m: I have given it a bit of thought, I just wish I had some good answers Mar 11 11:28:59 @RP/stefan-schmidt[m: isn't something like an SPDX header in a recipe only the license for the recipe, as in a .c file only for the .c file? Mar 11 11:29:04 Let me wrap my head around this for a little longer and I can try to come up with something Mar 11 11:29:30 RobertBerger: yes, it would be the license for the recipe itself. Mar 11 11:29:36 RobertBerger: in principle, yes. Just as in principle everyone shares the source for GPL binaries ;-) Mar 11 11:30:57 @RP: hehe I get you ;) But certainly it makes it more obvious when I sue somebody and the SPDX header is all over the .c and .h files Mar 11 11:32:35 Is it safe to create a non-standard directory in $WORKDIR while building, to contain build system metadata? Mar 11 11:33:10 jmiehe: probably, most of the time Mar 11 11:33:14 RP: I will think about it more and ping you about it again when I have cleared my thoughts on this Mar 11 11:33:29 stefan-schmidt[m: fair enough :) Mar 11 11:46:06 chrysh: bitbake -e your-image-recipe | less and look for IMAGE_INSTALL and DISTRO_FEATURES and check which recipe/conf files are adding what Mar 11 11:46:33 LetoThe2nd: I think it's almost time for YP to have actual songs like OpenSuse does :D Mar 11 12:03:23 RobertBerger: Nice domain name :D That's some serious SEO right there: http://yocto.training. Mar 11 12:04:29 @manuel1985: Hehe - how about embedded-linux.training ? Mar 11 12:07:07 hi when I list the layers with bitbake-layers show-layers I see a priority column. Is it the order of layers execution? Mar 11 12:07:23 Hello, two quick fetch error messages I get when compiling dunfell, no idea if you have looked at these already: Mar 11 12:07:39 RobertBerger: Seems you know your job ;) Mar 11 12:07:55 a.k.a you did your homework. Mar 11 12:08:22 WARNING: xz-native-5.2.4-r0 do_fetch: Failed to fetch URL https://tukaani.org/xz/xz-5.2.4.tar.gz, attempting MIRRORS if available <-- Said URL is a Sourceforge alias Mar 11 12:08:33 Not sure if that is the best source for it Mar 11 12:08:35 by the way I found the link to the screen capture of the Yocto Project Summit 2020 I asked you for via email, but am still in need for the slides, though Mar 11 12:08:50 WARNING: netbase-1_6.1-r0.spark1 do_fetch: Failed to fetch URL http://ftp.debian.org/debian/pool/main/n/netbase/netbase_6.1.tar.xz, attempting MIRRORS if available Mar 11 12:09:19 @manuel1985: I'll send you some more links ;) Stay tuned. Mar 11 12:09:44 netbase_6.1 has changed to netbase_6.1~bpo10+1.tar.xz Mar 11 12:10:45 wertigon: do you have errors when building or just the warnings? Mar 11 12:10:52 Neither give catastrophic errors Mar 11 12:11:04 qschulz: Only QoL warnings from fresh build :) Mar 11 12:11:06 yeah, it just uses mirrors then Mar 11 12:11:15 so nothing to worry about Mar 11 12:11:39 RobertBerger: Thanks! :) Mar 11 12:11:45 Yes, I know, just thought I should tell someone since it's easy to go months without downloading fresh sources Mar 11 12:11:52 it's just that the primary URL is not reachable for some reasons, but the mirrors hosted by YP usually can provide those as a fallback (and they are set as fallback by default in poky local.conf IIRC) Mar 11 12:12:06 wertigon: why would we want fresh sources? Mar 11 12:12:31 wertigon: we want reproducible builds with fixed versions of software Mar 11 12:12:55 gillesMMM: https://docs.yoctoproject.org/ref-manual/variables.html#term-BBFILE_PRIORITY Mar 11 12:13:09 wertigon: maybe I'm missing your point :/ Mar 11 12:13:45 qschulz: Just thinking from the perspective of a person new to Yocto Mar 11 12:14:01 Warnings are scary :) Mar 11 12:20:48 wertigon: I wish everyone was scared of warnings tbh :) Mar 11 12:24:45 wertigon: don't know how RP would feel about lowering the loglevel of that kind of warning, since anyway it'll fail the build if mirrors don't have the sources either Mar 11 12:24:59 but feel free to send patches and then we can discuss about them :) Mar 11 12:26:52 Yeah, I mean it's not a high priority bug or anything, and like you say it is important to keep code "stale" Mar 11 12:27:42 No idea what the solution is, maybe have a preference on a per-package basis for which fetch source to use? Mar 11 12:28:01 *per-recipe basis Mar 11 12:32:09 We do try and fix urls where we can so the warning is a reminder we need to do that Mar 11 12:32:19 * RP has found the parsing performance issue. Its silly :/ Mar 11 12:32:44 like the gta5 json one? Mar 11 12:33:21 kanavin: should we be thinking about xwayland now or post release? Mar 11 12:39:29 Don't you dare lowering loglevels to get less warnings. That's like rising the permissible blood alcohol level for driving a car. Mar 11 12:42:33 RobertBerger: But it works in the states? :D :P Mar 11 12:42:47 (Yes, being ironic here) Mar 11 12:51:33 RP: the final release of standalone xwayland is scheduled for March 17th, so I tagged this as RFC, as it packages a pre- snapshot. I am leaning towards the post release. Mar 11 12:57:19 kanavin: right, makes sense. Just checking :) Mar 11 13:01:24 hello ladies and gentleman, Im trying to run directfb on msm8909 from quectel with no success. While at yocto I have an impression i know enought to do it, I feel newbie in GPU, opengl and other display stuff. Can you suggest some materials to better understand the subject? Layer after layer, what do I need to include in image to make it work? Mar 11 13:02:26 Blackbetty: start at layer0: remove msm8909 and replace with a proper soc. Mar 11 13:02:30 Blackbetty: PROFIT Mar 11 13:02:37 * LetoThe2nd ducks and runs. Mar 11 13:02:43 damn, I wish I could Mar 11 13:03:10 That's the thing though, I looked at env variables DISTRO_FEATURES and IMAGE_INSTALL and they do not contain selinux Mar 11 13:03:32 LetoThe2nd: what are the chants #2 and #3? Mar 11 13:04:10 chrysh: #2: "it depends (TM)" #3: "cherry-pick the bsp and dump the rest" Mar 11 13:05:37 LetoThe2nd: Thanks, that was helpful Mar 11 13:07:33 but seriously, I do not understand where else to search for where selinux gets included. if bitbake -e does not show me that, it's impossible that it gets included, isn't it? Mar 11 13:08:22 IMAGE_INSTALL_remove part was only to see whether it compiles and boots at all without SELinux Mar 11 13:08:22 now I am wondering how to make it properly Mar 11 13:08:22 *do it Mar 11 13:21:13 RP: I just built a core-image-minimal where I had only added vim as a dependency, and got this: path mismatch [2 links]: ino 65115947 db '/home/pkj/dists/poky-master/builds/qemux86-64/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/oe-rootfs-repo/rpm/core2_64/glibc-localedata-es-pa-2.32-r0.3.core2_64.rpm' req Mar 11 13:21:14 '/home/pkj/dists/poky-master/builds/qemux86-64/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/usr/share/vim/vim82/lang/nb'. Mar 11 13:21:27 Are we missing some path in PSEUDO_IGNORE_PATHS? Mar 11 13:34:12 Saur20: incremental image generation? rootfs/ should be under pseudo control, not ignored Mar 11 13:34:28 Saur20: I've traced that performance regression btw, fix should be out shortly Mar 11 13:36:06 Yes, it was an image that I had built a while ago, where I now updated the layers, added the dependency on vim and rebuilt it. Mar 11 13:36:33 chrysh: we don't use selinux by default so it is definitely possible to remove it. It is a question of how you enabled it and undoing that. Perhaps something isn't rebuilding correctly? Mar 11 13:37:01 RobertBerger: warnings for "i couldn't reach the original URL but don't worry I'll try the mirrors" feels silly to me Mar 11 13:37:26 Saur20: perhaps we've now excluded oe-rootfs-repo but this was built before we did that? Mar 11 13:37:31 that was a more recent change Mar 11 13:38:05 Saur20: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=6066d67c216a3f475b5df262c9c89967a02e7834 Mar 11 13:38:38 chrysh: you have to figure out why adding IMAGE_INSTALL_remove and/or DISTRO_FEATURES_remove make it build without selinux support. I'm surprised that they don't change the actual value of DISTRO_FEATURES but it changes the behavior. Mar 11 13:39:18 Saur20: we don't have code to remove newly excluded paths from the db Mar 11 13:41:18 RP: Ok, that seems likely (it was longer since I built the image the last time). Thanks. Mar 11 13:41:31 qschulz: yea, but do you have any theory why that could be the case? Mar 11 13:44:37 the example poky build is for the qemux86-64 machine. where are machines defined? Mar 11 13:46:15 yates: poky/meta/conf/machine/qemux86-64.conf Mar 11 13:46:17 chrysh: seems like a user issue to me, it seems impossible that _remove for something that does not exist modify behavior of Yocto Mar 11 13:46:21 at least in my case Mar 11 13:46:51 chrysh: that's where the machine for the build is specified, i'm asking where it is defined Mar 11 13:47:04 or no, wait... Mar 11 13:47:48 Is there any update on https://lists.yoctoproject.org/g/linux-yocto/topic/78406640#9205? It is about the warning generated by the CONFIG_SERIAL_OF_PLATFORM addition on x86. Mar 11 13:47:53 qschulz: How do I rebuild the rootfs then? I thought bitbake myimage -c rootfs -f would rebuild my rootfs? Mar 11 13:49:41 zeddii: re CONFIG_SERIAL_OF_PLATFORM above ^ Mar 11 13:49:52 zeddii: wow - https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1959 - green - with the perf fix :) Mar 11 13:50:06 * RP had forgotten what a green master-next looked like Mar 11 13:51:10 wow! Mar 11 13:52:10 alephan: its still on my TODO list, it'll be fixed up before the current release goes out. Mar 11 13:52:40 RP: well spotted on pmu-events being evil :D Mar 11 13:52:41 chrysh: if DISTRO_FEATURES_remove actually does modify DISTRO_FEATURES, then removing it will trigger a rebuild. It's very rare to need to use -c -f and is not recommended. Mar 11 13:53:04 zeddii: thanks for fixing it, the fix is rather horrible but its a nasty probem Mar 11 13:53:10 Thanks zeddii . How should I fix this locally? I'd like to get rid of the warning in the meanwhile. Mar 11 13:53:32 if removing your two _remove does not trigger a rebuild, then they are not the changes you made that made selinux files disappear in your build and you need to check what else has changed in your layers which impacted selinux in your image Mar 11 13:53:39 zeddii: are you going to send the patch out? Mar 11 13:53:53 yep. I'll send it now. so people can revel in the horror. Mar 11 13:54:15 zeddii: at least we know where the issues are now and can try and push upstream to do something abotu it Mar 11 13:54:38 Hi o/ Mar 11 13:54:44 exactly. and I can point the devs looking at this upstream to our fix -> green builds as proof that it is worth it. Mar 11 13:54:58 zeddii: right, exactly Mar 11 13:56:26 I'm new to yocto and I wish to understand how layers are stacked. Is there a way to display a graph or something ? Mar 11 13:56:41 chrysh: so if i am creating my own machine, AKA a BSP of name bsp_name, i create a layer meta-bsp_name and provide a meta-bsp_name/conf/machine/bsp_name.conf there? Mar 11 13:56:59 RP: sent, "as-is" with only the WIP removed from the subject. I assume you have the perf removed from exclusions already Mar 11 13:57:03 I already tried bitbake -g image but there is too many information on it so I'm lost in it ... Mar 11 13:57:14 zeddii: I reused your last patch, yes, thanks Mar 11 13:57:25 hah Mar 11 13:57:28 wrong list Mar 11 13:57:33 I re-used my yocto-bsp commandline Mar 11 13:57:38 resending to oe-core now. Mar 11 13:57:40 sigh Mar 11 13:57:53 zeddii: I ended up setting git config on the checkouts to avoid that! Mar 11 13:58:23 (and then add that layer to my bblayers) Mar 11 13:58:24 yates: makes sense to me, the vendor of my board seems to have done exactly that Mar 11 13:58:26 yates: don't use underscores in machine names but yes Mar 11 13:58:33 ok Mar 11 13:58:54 notoriousPig: can you elaborate what ytou mean by "how layers are stacked"? Mar 11 13:59:12 qschulz: "Removing it will trigger a rebuild" ==> you mean if I do bitbake myimage, or when? Mar 11 14:00:13 chrysh: yes, and without the two _remove in your local.conf Mar 11 14:01:08 zeddii: I might hold perf in -next a bit longer just to get a few more builds before that one merges just in case there is something else lurking Mar 11 14:01:14 agreed. Mar 11 14:01:15 I Mar 11 14:01:46 zeddii: 24 hour rollover and other second run issues have been known (see ltp) Mar 11 14:01:56 I just followed up and added a bit of context to the patch so it can be captured in the mailing list archive. Mar 11 14:02:07 Yes qschulz, I wish to understand which layer is on top. I have a xinlinx board and I built a yocto image for it. Now, I need to make some change to the kernel and I need to show to my client (graphicly if possible) where in the yocto stack I made those changes. Mar 11 14:02:19 I don't want someone to try and bikeshed my python, since it was quick and dirty .. and not a forever kind of fix :D Mar 11 14:02:44 RP: I do expect one more blow up. but we are in good position to squash them now. Mar 11 14:03:20 zeddii: indeed. Getting to this point is the hard bit Mar 11 14:03:27 notoriousPig: it's not that easy unfortunately to explain, bbclasses and configuration files, if they exist in more than one layers are "first found is taken", in the order defined in BBPATH Mar 11 14:03:34 for recipes, see BBFILE_PRIORITY Mar 11 14:03:52 for bbappends, I don't know exactly in which order they are applied, I'd say BBFILE_PRIORITY too Mar 11 14:04:21 but in 99% of the cases, you don't really need to know how "layers are stacked" if you're adding stuff, because bbappends are always applied Mar 11 14:05:33 Okay, I will check those variables then. Mar 11 14:05:36 Thanks a lot ! =D Mar 11 14:23:03 zeddii: is there an easy way I can patch the kernel-meta clone from a recipe/bbappend? re to the config warning above Mar 11 14:28:36 using https://git.yoctoproject.org/git/meta-raspberrypi for a bsp reference, i'm seeing several conf/machine/raspberrypi_xyz.conf files. so in this case a single bsp layer provides several different machines/BSPs? Mar 11 14:29:09 yates: yup Mar 11 14:34:03 +1 Mar 11 15:03:55 alephan: you can always provide your own fragment in the SRC_URI and that will silence the warning. That being said, I just did a qemux86-64 build, as does the autobuilder, and I'm not seeing the warning. What exactly is your config ? have you bumped up the audit settings, etc ? Mar 11 15:08:45 zeddii: I'm using dunfell with an upgraded linux-yocto to 5.10 Mar 11 15:09:06 But the linux-yocto recipes are the ones in master Mar 11 15:11:19 I think an update just landed in master - trying it now Mar 11 15:12:32 same warning with the exact revisions in master Mar 11 15:13:45 Hmmm... Mar 11 15:15:52 But it should be reproducible on your side too zeddii It's not in 5.10 http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/log/?h=yocto-5.10 Mar 11 15:16:00 (the revert that is) Mar 11 15:16:57 right. That was on purpose. I didn't want to revert it. but the AB isn't showing the warning, so it fell off my radar. I'm trying to bump up my audit settings locally to see if I can make it show up. Mar 11 15:17:51 Gotcha. I'll go down the cfg route for now. Mar 11 15:18:02 Shoot me a CC when this is pushed. Mar 11 15:18:54 will do. I have a series of meetings coming up, and I'll poke at this in the background today Mar 11 15:22:21 Thanks. No rush. Local cfg will do for now. Mar 11 15:30:40 I just bumped everything up and forced the config audit. didn't warn. I'll force it to happen. but can you also pastebin your wrming for me, so I can reference it ? Mar 11 15:40:35 If linking to -lssl and -lcrypto (C), what are the corresponding yocto packages? Mar 11 15:44:45 Solution: Add "openssl" as buildtime dep Mar 11 15:52:23 * jmiehe bites his desk really hard. Mar 11 15:56:54 jmiehe: pics or it didnt happen. Mar 11 15:57:31 jmiehe: plus, manually setting linker flags is almost always a bad idea, use a build system to determine the needed packages instead :) Mar 11 16:13:46 @LethoThe2nd: Advanced topics ;) Makefile or even worse gets the right linker flags automagically. Oida! Mar 11 16:32:35 RP: available now for qemuarmv5 drop/fix discussion? Mar 11 16:35:56 jonmason: yes Mar 11 16:36:17 jonmason: my thinking was just to add something simple to the end of the qemuarm build - core-image-sato only with a testimage Mar 11 16:37:24 the problem with the testimage was "RESULTS - parselogs.ParseLogsTest.test_parselogs: FAILED (3.95s)" Mar 11 16:37:42 and thats because AMBA driver finds entries that are not used Mar 11 16:38:12 I can hack that out in a kernel patch...but that's super ugly Mar 11 16:38:44 jonmason: we can put that in the parselogs ignore list Mar 11 16:38:53 fair enough Mar 11 16:39:44 jonmason: meta/lib/oeqa/runtime/cases/parselogs.py, see the qemuarm section Mar 11 16:40:06 my concern was it was not used based on the issues found, but that seems not true (or at least we want it still). So, I'll fix it Mar 11 16:41:04 Thanks for putting me right. I'll see about finding better solutions per Andre's comments Mar 11 16:41:42 jonmason: I just have a feeling there is a small but definite group of people still using armv5 :/ Mar 11 16:43:01 RP: regarding QB_MEM, is your assumption that is a ceiling or a recommendation for optimal perf? Mar 11 16:43:56 I can add some warnings/errors in the places that override it, just want to know how hash to be Mar 11 16:45:13 jonmason: it was originally intended to be a "good starting value". the bigger images then increased it Mar 11 16:45:34 jonmason: there were discussions at the time about how I didn't like the increases :/ Mar 11 16:46:18 seems like you can predict the future, I need you to pick some lottery numbers for me Mar 11 16:47:09 I'd hate to make a unique variable just for the max (per khem's suggestion) but it seems like the best choice right now Mar 11 16:47:12 jonmason: the machines probably need to define a "standard" and a max value, then the images pick a value inbetween Mar 11 16:47:59 jonmason: maybe we change it to be "default,max,min" and require qemu to handle the -m bit ? Mar 11 16:48:07 remember brett was hitting this same issue a while ago Mar 11 16:48:50 I do sort of hate runqemu parameters taking in the command parts and not doing it in the script Mar 11 16:53:00 jonmason: there is a ton of history here and things being done sub optimally, originally due to shell script :/ Mar 11 16:53:28 I'll just rewrite it a piece at a time Mar 11 16:54:28 this SBSA/SystemReady work is sending me down a rabbithole Mar 11 16:55:06 jonmason: piece at a time is all we can do Mar 11 18:19:51 guys, there's something wrong in your doc https://www.yoctoproject.org/docs/1.8/bsp-guide/bsp-guide.html Mar 11 18:20:26 according to section 1.6.1, i should be able to "source oe-init-build-env build-dir" then run yocto-bsp help Mar 11 18:20:43 yocto-bsp gives command not found Mar 11 18:24:21 also, there is no /scripts/yocto-bsp Mar 11 18:25:44 that's the 1.8 docs Mar 11 18:25:51 yocto-bsp was removed after that Mar 11 18:26:06 1.8 of poky? Mar 11 18:26:09 yes Mar 11 18:26:16 what is the current poky ? Mar 11 18:26:26 3.2 Mar 11 18:26:29 1.8 is from 2015 Mar 11 18:26:33 is error.yp.org down ? Mar 11 18:26:50 holy #@!$. ok, soryr - i guess google just pulled this up Mar 11 18:26:50 khem: errors.yp, works for me Mar 11 18:27:01 yates: google is good at digging out old docs for no obvious reason Mar 11 18:27:05 just change the number to 'latest' Mar 11 18:27:37 k Mar 11 18:28:54 btw rburton systemd-boot fails on aarch64 see http://sprunge.us/H1XJUo Mar 11 18:28:54 I know you enabled it recently as dependency Mar 11 18:29:10 rburton: its on musl btw. Mar 11 18:32:48 rburton: I am seeing 10:31:22 ERROR: HTTP Error 500: Internal Server Error Mar 11 18:32:48 10:31:22 Preparing to send errors to: errors.yoctoproject.org Mar 11 18:35:33 oh systemd-boot is not musl only , I see it fail for on a qemuarm build too Mar 11 19:21:14 khem, Not down for me. However we are seeing some network weirdness with the GCE hosted servers right now. Might be related. Mar 11 19:21:18 khem, Is it back for you? Mar 11 19:57:46 not sure Mar 11 19:57:57 it was ok a day before Mar 11 19:58:06 its acting up since yesterday Mar 11 19:58:55 still seeing Mar 11 19:59:04 last was 30 mins ago Mar 11 20:52:16 hm having a weird time working on a kernel config - i have a working but minimal and somewhat wrong .cfg to tweak my kernel, and that stuff is definitely being applied, and what i want to do is split up what i have into multiple .cfg files, and then do a series of kernel_configme / menuconfig / diffconfig to incrementally create additional .cfg files to tweak different things Mar 11 20:53:03 but it seems like if split up my .cfg or rename it anything other than ${MACHINE}.cfg it doesn't get applied at all, despite each split .cfg being listed in SRC_URI Mar 11 20:53:31 and it definitely looks like it can find them: + merge_config.sh -O /work/build/tmp/work/sercomm_na503s-bantha-linux-gnueabi/linux-imx/5.4.24+gitAUTOINC+babac008e5-r0/build .kernel-meta/configs///defconfig .kernel-meta/configs//./xt-checksum.cfg .kernel-meta/configs//./ebtables.cfg .kernel-meta/configs//./vswitch.cfg .kernel-meta/configs//./lxc.cfg .kernel-meta/configs//./docker.cfg .kernel-meta/configs///no-can.cfg Mar 11 20:53:31 .kernel-meta/configs///bluetooth.cfg .kernel-meta/configs//./docker.cfg .kernel-meta/configs//./lxc.cfg Mar 11 20:53:48 (no-can.cfg and bluetooth.cfg being the ones in question, that's a line from kernel_configme output) Mar 11 20:54:04 but if i subsequently do a menuconfig i find that the options in those .cfg files aren't actually set Mar 11 21:01:05 i am having trouble with something very basic: when i clone poky, source the oe-init-build-env, and build the core-image-minimal target, what associates that target with the qemux86-64 machine? Mar 11 21:05:51 conf/local.conf -- look for MACHINE Mar 11 21:09:13 fray: that specifies the machine which will be used, where/how does "core-image-minimal" get picked up? yes, i know it is in /meta/recipes-core/images/core-image-minimal.bb; is it from there? Mar 11 21:13:07 also, is there a way to use a customized machine and bblayers.conf when running oe-init-build-env? of course i could modify the script, but is that what is intended? Mar 11 21:14:41 bitbake core-image-minimal instructs teh system to build core-image-minimal. The files are pulled based on bblayers Mar 11 21:15:19 you should bring in the environment with oe-init-build-env and configure the bblayers.conf yourself. Either by bitbake-layers add-layer or direct editing conf/bblayers.conf Mar 11 21:15:51 yates: bblayers.conf sets BBLAYERS which defines what layers are parsed, it parses conf/layer.conf for each layer. you should really just read hte yocto project docs, and possibly also the yocto chapter of the architecture of open source projects Mar 11 21:20:39 kergoth: in the ideal world, no one would have to ask any questions; everyone would read everything there is and discover the answers to their remaining questions through painstaking trials. Mar 11 21:20:48 problem is, that takes about 15 years. Mar 11 21:21:08 but thanks. i am certainly open to pointers to specific docs. Mar 11 21:22:06 out of curiousity, where is this "architecture of open source projects" doc? is that a yocto doc? Mar 11 21:22:10 curiosity Mar 11 21:24:37 it seems more sane to have a pre-defined build directory (e.g., in a repo, or built from a script in a repo), but you still need the yocto-specific setup part of oe-init-build-env. is there a "setup the yocto environment" subroutine for this purpose? Mar 11 21:25:03 pre-defined for my specific machine, layers, etc. Mar 11 21:26:32 https://www.google.com/search?hl=en&q=architecture%20of%20open%20source%20yocto first link Mar 11 21:28:03 huh, if i quit forcing a kernel_configme before menuconfig then it works as expected Mar 11 21:29:44 kergoth: thanks. i didn't know it was an actual book, and on-line. Mar 11 21:38:48 still looking for a Mar 11 21:39:07 yocto-specific setup of oe-init-build-env. Mar 11 21:39:24 does it exist? Mar 11 21:39:48 b Mar 11 21:46:13 khem: systemd-boot issue was the gnu-efi upgrade. I booted it from -next Mar 11 21:59:15 yates: don't really know what you mean. yocto's buildsystem is oe, oe-init-build-env works fine. there are plenty of alternatives if you don't like that method, see kas, etc Mar 11 23:35:52 kmaincent: For the buildtools failure on master-next, looks like an intermittent parallel make bug. I've rerun it and it looks to have got past that point Mar 11 23:50:39 hello, is there any work around building the esdk in dunfell with a linux-dummy kernel ? I'v only seen this https://www.mail-archive.com/yocto@lists.yoctoproject.org/msg03554.html Mar 12 00:58:38 I feel like I am chasing a failure of the compile-host-path WARN_QA check. Mar 12 00:59:04 I can get a very clear build failure if I delete an include file on my host, which should not happen. I see the same include file in the build sysroot. Mar 12 00:59:31 do_compile log, recipe, and Makefile -> https://gist.github.com/chuckwolber/152e63f37a515198d1ac4e75a1faa5a7 Mar 12 01:45:15 trying to run xinit as non-root on an rpi4... found the ROOTLESS_X config, added pam, built an image, and things seemed well. X won't start ofc, and after sorting some permission issues with the /dev/tty* it's trying to attach to, it looks like the xuser is getting pretty far along in the init... but it's failing when loading libfb Mar 12 01:45:37 https://pastebin.com/t1DBean1 Mar 12 01:47:01 Without having to dive into libfb internals... my guess is that it could be a permissions issue, creating a framebuffer in memory, and the xuser doesn't have permissions... no idea how to track that down currently Mar 12 01:49:00 It's worth mentioning that X runs as root just fine... so I'm near certain it's a permission issue Mar 12 01:49:11 RP: thanks, yeah I was wondering, I guess it disappeared before my attention :) Mar 12 01:58:19 Spooster: yes see in logs it says [ 1120.040] (EE) modeset(0): drmSetMaster failed: Permission denied Mar 12 01:58:53 so perhaps you have to let xuser be able to access drm device perhaps Mar 12 01:59:33 just do ls -l /dev/dri/card* Mar 12 01:59:39 and see what permissions do they have Mar 12 01:59:53 I don't have any /dev/drm* hiding anywhere... but I did check the /dev/dri entries, and unfortunately, those seem to line up with what I'd expect Mar 12 02:00:38 /dev/dri/card0 and card1 are in the video group, and xuser is as well... permissions are 660 Mar 12 02:01:12 hmm then it should work Mar 12 02:01:34 there IS a /dev/dri/renderD128 ... which is curiously in the render group... Mar 12 02:01:47 for tests change the perms to 777 and see if it helps Mar 12 02:01:54 ah Mar 12 02:02:03 will do... gonna also tinker with this renderD128... Mar 12 02:05:06 :( no dice Mar 12 02:05:06 try sudo chgrp video /dev/dri/renderD128 Mar 12 02:05:14 and see if that helps Mar 12 02:05:19 Oh, I just added xuser to the render group instead Mar 12 02:05:23 but sure Mar 12 02:05:29 I think they should be in same grp Mar 12 02:05:38 yeah that will work too Mar 12 02:06:05 I think you can perhaps control this via udev rules Mar 12 02:06:33 for sure... I'm already going to need to go there to fix /dev/ttyN group access from 640 to 660 Mar 12 02:06:40 look for *.rules files in /usr and /etc Mar 12 02:06:58 you already might have a rules file that you can edit Mar 12 02:07:37 I did scour /etc... we don't have much in /usr for udev right now on this image Mar 12 02:07:41 but that's a step 2... Mar 12 02:07:52 are you using systemd ? Mar 12 02:07:57 yes Mar 12 02:08:00 ook Mar 12 02:08:44 even after adding the user to the group, or 777'ing the renderD128 device... it's still throwing that Permission Denied Mar 12 02:09:05 I'll get around to the udev stuff once I figure out what I need to hit with a hammer... just want to know what to try Mar 12 02:09:46 the only thing left in there is /dev/dri/by-path ... no idea what these are honestly Mar 12 02:09:57 whats the perms now ? Mar 12 02:10:11 on reboot these perms will be lost Mar 12 02:10:53 (what's etiquette for console output in the 5-10 line range? pastebin still?) Mar 12 02:11:43 https://pastebin.com/HwiDKg9Z Mar 12 02:11:51 more than 4 lines perhaps pastebin it Mar 12 02:12:21 Yeah, I'm aware that I'll need to get this all down into udev rules... I've already added some for `/dev/ttyS0` Mar 12 02:12:25 ok this looks fine to me Mar 12 02:13:09 systemd is still hammering away every 15 seconds or so trying to run xinit... and it's still getting to the same point. modeset(0): drmSetMaster failed: Permission denied Mar 12 02:14:03 for what it's worth... I do see the screen seem to draw output from a different console for like... 1/2 a second Mar 12 02:14:20 it looks like colorized dmesg output... maybe 8 lines or so Mar 12 02:14:46 that might imply that it's not a video device related permissions error... if it's actually getting to the point where SOMETHING is on screen Mar 12 02:15:14 is there anything in /home/xuser/.local/share/xorg/Xorg.0.log Mar 12 02:15:31 I pasted that already, but I'll get a fresh copy Mar 12 02:15:35 ok Mar 12 02:16:11 https://pastebin.com/AwCAr9ei Mar 12 02:16:38 (For more information, please reread this message) Mar 12 02:20:19 I wonder if its racing with video driver Mar 12 02:20:35 would root be able to xinit if that was the case? Mar 12 02:20:47 because it definitely can... Mar 12 02:21:22 hmmm not sure root is special in many ways Mar 12 02:21:44 what happens if you move /usr/lib/xorg/modules/libfb.so out of way Mar 12 02:21:58 I'm tempted to walk through all remaining devices and 777 them for this boot Mar 12 02:22:37 whats the version of systemd you are using Mar 12 02:22:44 Not going to lie, I'm super green here... Are you suggesting I just straight up mv /usr/lib/xorg/modules/libfb.so to some other location for now? Mar 12 02:23:58 systemd 244 (244.5+) Mar 12 02:25:11 yes mv it Mar 12 02:25:19 just for tests Mar 12 02:26:31 after nabbing libfb.so: https://pastebin.com/EjZT7tBh Mar 12 02:26:32 atomics in modesetting can be troublesome see https://cgit.freedesktop.org/xorg/xserver/commit/?id=f0d78b47ac49977a6007f5fe081f00c6eb19a12e Mar 12 02:27:12 yeah move it back Mar 12 02:27:36 seems like this is the only driver available for now... Mar 12 02:28:16 do you have xorg.conf Mar 12 02:28:46 there are some rules in /usr/share/X11/xorg.conf.d/ Mar 12 02:28:56 i'll dump em now Mar 12 02:29:06 they're both pretty small Mar 12 02:29:41 what does cat /sys/kernel/debug/dri/0/clients say Mar 12 02:30:21 that's empty... likely because nothing's running Mar 12 02:31:10 even after moving fb driver back ? Mar 12 02:31:48 10-quirks.conf https://pastebin.com/75gFSVc2 40-libinput.conf https://pastebin.com/ZVfH5KrJ Mar 12 02:32:26 yeah... I was actually there from another forum post from earlier... because x is just straight up dying, I wasn't surprised to see that there weren't any entries Mar 12 02:32:58 surprisingly... there really isn't a top level xorg.conf anywhere Mar 12 02:33:57 /etc/X11/xorg.conf is just an empty file with a comment saying to put stuff in xorg.conf.d/ Mar 12 02:34:16 yeah Mar 12 02:34:35 try to put needs_root_rights=yes in /etc/X11/Xwrapper.config and see if this helps Mar 12 02:35:44 that file doesn't currently exist, but it can't hurt to make it, and see what sparks fly Mar 12 02:41:58 those files worked in old times not sure if they still work with new X but try it Mar 12 02:42:26 I did give it a go, no dice :( Mar 12 02:43:45 you might find this useful https://wiki.gentoo.org/wiki/Non_root_Xorg Mar 12 02:46:54 I get a pretty indecipherable message when I try to 'loginctl user-status' Could not get properties: Unknown object '/org/freedesktop/login1/user/self' Mar 12 02:48:17 one could presume that elogind is not properly configured, function, or present Mar 12 02:50:46 *functioning Mar 12 02:58:00 Might investigate the line systemd-logind: failed to get session: PID 1542 does not belong to any known session Mar 12 02:58:18 sounds like a thing for tomorrow Spooster... maybe they'll figure it out **** ENDING LOGGING AT Fri Mar 12 03:00:01 2021