**** BEGIN LOGGING AT Wed Nov 25 02:59:57 2020 Nov 25 07:54:08 moto-timo: i think that must have been the 5 minutes in my life with the most hilarious tweeting so far. you beat me to it! Nov 25 07:54:25 oh and yo dudX Nov 25 08:00:58 yo Nov 25 08:04:28 yo morning :-) Nov 25 08:59:38 * qschulz waves Nov 25 09:27:41 how can I check the env BSPDIR ? Nov 25 09:27:54 ? Nov 25 09:29:06 I don't get why it's not finding the folder https://bpa.st/677Q Nov 25 09:29:34 LetoThe2nd, I thought when I use `bitbake -e` it prints the whole environment Nov 25 09:30:36 wyre: hm, almost. it prints the final result of the recipe evaluation, which includes all variables and their evaluation that have happened in there. Nov 25 09:31:40 LetoThe2nd, well, then how can I figure out why it's failing? Nov 25 09:32:09 i have no idea what is failing? Nov 25 09:35:22 wyre: just checked: BSPDIR is not something that exists in poky Nov 25 09:35:48 wyre: so i have the strong feeling that you are battling some craziness by your BSP vendor. Nov 25 09:36:05 BSPDIR is something that the freescale layers are using Nov 25 09:36:36 * LetoThe2nd is out then. Nov 25 09:36:45 LetoThe2nd, https://bpa.st/677Q it's not finding the directory '${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-bsp' but it's there Nov 25 09:37:16 like i said, BSP vendor suplied craziness. i do not intend to support this. Nov 25 09:37:30 (other might have different opinions, of course) Nov 25 09:37:40 :)) Nov 25 09:38:09 LetoThe2nd, you mean in this repo? https://github.com/toradex/meta-fsl-bsp-release Nov 25 09:38:18 wyre: you need to source their environment setup script, not poky/oe-init-build-env Nov 25 09:38:31 mihai, I've done that Nov 25 09:38:44 fsl-setup-release.sh in fact Nov 25 09:38:53 from what layer is that? Nov 25 09:39:13 mihai, meta-fsl-bsp-release Nov 25 09:39:17 wyre: i will not even look that up. one time you refer to engicam, another time you refer to toradex. if they sell you hardware, then also please contact their support. Nov 25 09:39:32 * LetoThe2nd will be silent then and refer to mihai Nov 25 09:39:55 :)) Nov 25 09:40:54 mihai, then what do you think is not finding the layer directory? πŸ€” Nov 25 09:42:33 looking now, there was a gimmick there that defined that variable Nov 25 09:44:09 in fact I also think the vendor is not a good one, I think the meta-engicam has a lot of dependencies that I don't need Nov 25 09:44:12 hm, you should have this in your bblayers.conf Nov 25 09:44:13 like meta-qt5 Nov 25 09:44:15 BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../..')}" Nov 25 09:45:41 mihai, should I include that in the bblayers.conf? Nov 25 09:46:19 mihai, why is not this generated? πŸ€” Nov 25 09:46:39 afaik. meta-fsl-bsp-release should be based on the freescale layers, and that's what they do Nov 25 09:47:04 wyre: https://github.com/Freescale/fsl-community-bsp-base/blob/master/setup-environment Nov 25 09:47:44 it uses a template containing bblayers.conf which defines it, https://github.com/Freescale/fsl-community-bsp-base/blob/master/conf/bblayers.conf Nov 25 09:49:32 Is anyone using kas for yocto projects and has setup a CI pipelin with it? Even better if someone has done it with gitlab CI :) Nov 25 09:52:09 dleppich: yes, no and no :) Nov 25 09:52:30 respectively, we're kicking it off with jenkins, but thats about it. Nov 25 09:52:54 mihai, for some reason when I run fsl-setup-release.sh I'm not having the bblayers.conf template with BSPDIR := ... Nov 25 09:54:16 LetoThe2nd: Hmm, I haven't worked with CI that much before.. But in my imagination it shouldn't be that hard, right? I just need to have a docker image with python and do the kas setup there (venv, install kas) and start the build afterwards, right? Nov 25 09:54:27 wyre: well... Nov 25 09:55:08 * mihai shrugs Nov 25 09:55:24 dleppich: it depends a bit on the use case i think. where the artifacts are being put, if there are additional parameters to be piped into the build. Nov 25 09:55:30 when I source, I mean, mihai 😊 Nov 25 09:56:05 dleppich: paulbarker has done a presentation on ci pipelines at ELC-NA, let me see if i can find the video Nov 25 09:56:49 LetoThe2nd: I'm in the stage of trying out stuff, so my only usecase is to make GitLab CI build something (e.g. a core-image-minimal) with kas + yocto. Nov 25 09:57:30 dleppich: best inspiration i can offer is https://youtu.be/RSjQjPFFWig Nov 25 09:57:37 wyre: Instead of continuing to make changes without knowledge of the facts I suggest you start over with a new installation, document all the steps you take and if necessary put them on pastebin so that we can understand what you are doing. Nov 25 09:57:50 LetoThe2nd: Thanks! I'll have a look at it :) Nov 25 09:57:57 dleppich: have fun! Nov 25 09:58:11 mckoan, that's exactly what I was trying Nov 25 09:58:46 but I have better results with the bsp provided by engicam, the point is the sources are not git repos, I think they made their changes Nov 25 09:59:02 wyre: FYI We are working on several projects based on Engicam MicroGea MX6ULL and STM32. Apart from a few minor fixes everything works out-of-the-box. Nov 25 09:59:08 wyre: period. Nov 25 10:05:00 mckoan, you mean with the bsp provided by Engicam? Nov 25 10:09:22 mckoan, remember that I'd like to build warrior while bsp ships pyro Nov 25 10:13:28 * LetoThe2nd is angry. coffee maker at office is broken. Nov 25 10:18:03 wyre: depending on what you need from the BSP vendor, just take the recipes you want and ditch the vendor BSP Nov 25 10:18:57 qschulz, that's what I'm trying, πŸ˜† so I don't need the meta-engicam layer? πŸ€” Nov 25 10:19:13 you mean could I just build warrior and boot it in the board? Nov 25 10:28:56 wyre: BBMASK away everything that you don't need from a BSP layer Nov 25 10:29:44 some BSP layers come with a kitchen sink of SW modifications which tie them heavily to a yocto release Nov 25 10:31:42 mcfrisk, I don't actually know what I don't need πŸ˜† Nov 25 10:32:07 mcfrisk: i actually could need a new kitchen sink. mine's clogged. Nov 25 10:34:12 LetoThe2nd: there must be a video for "plunging new depths" to answer that comment :) Nov 25 10:36:25 RP: took a while to sort, but world reproducibility patchset is now being built by a-full http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/world-repro Nov 25 10:36:26 RP: i should create meta-pΓΌmpel. too bad it translates badly, e.g. it doesn't sound half as funny in english (meta-plunger) Nov 25 10:36:34 mcfrisk, how can I identify what I don't need from here? https://github.com/engicam-stable/meta-engicam/tree/warrior Nov 25 10:37:11 I'd say I just need the recipes-core Nov 25 10:37:25 RP: I spent an awful amount of time getting go and its consumers to reproduce, and got there, but not happy with the currently hacky nature of the fixes. So that's taken out, and will be handled later Nov 25 10:37:39 RP: and as there is no metallic element named after it in the periodic system so far, i unfortunately am not permitted to do so :( Nov 25 10:39:08 kanavin_home: that is quite an achievement getting the list down to that, nice work! Nov 25 10:39:51 kanavin_home: go sounds a pain. Is there interest in that upstream? Nov 25 10:40:13 LetoThe2nd: some things don't translate so well, for better or worse :) Nov 25 10:40:27 wyre: you need to check, remove, re-test, iterate over this. start by checking what is currently in your product images. been there too, but after BBMASKing 90% stuff away, life suddenly becomes much easier with yocto updates etc Nov 25 10:41:34 kanavin_home: zeddii will have perf fixed in no time ;-) Nov 25 10:41:52 (we're usually lucky if it builds :/) Nov 25 10:41:56 todays lesson learnt: trimming/recoding the live coding session recordings in openshot is a stupid idea. Nov 25 10:42:34 mcfrisk, by now I'm building just yocto Nov 25 10:43:54 wyre: you said the bsp vendor only supports pyro but you send one that supports warrior, you're confusing us :) Nov 25 10:44:53 qschulz, well, for this board the BSP shipped comes with pyro, the branch warrior is what I'm trying to use to build a minimal warrior version Nov 25 10:45:05 without qt, gnome, or layers like that Nov 25 10:45:19 wyre: you are likely not building yocto, e.g. world. you build an image. like core-image-minimal. Nov 25 10:45:48 mcfrisk, core-image-saato Nov 25 10:45:52 RP: there is some interest, but a lot of the pain comes from go tooling writing buildid hashes into the output, and those hashes being extremely sensitive to anything in the build environment. E.g. if ldflags contains full build paths (which it does), that will affect the hash. Nov 25 10:45:57 s/saato/sato/ in fact Nov 25 10:46:32 wyre: ok, then do you need all of that, and which ones of the SW components need BSP adaptations. that depends on target HW and machine config and use cases with sato image. Nov 25 10:46:58 kanavin_home: hmm, I can imagine how that becomes painful :( Nov 25 10:47:29 kanavin_home: I just ran a build of your branch on fedora33 btw. That runs with a different host umask and uncovered a load more reproducibility issues :( Nov 25 10:47:39 RP: also, it's just plain difficult to debug hash issues like that as the toolchain wasn't designed for it, and it's supposed to be something go users never have to worry about Nov 25 10:48:02 kanavin_home: it does sound like the kind of thing the go people need to be made aware of Nov 25 10:48:15 mcfrisk, what's the difference between -sato, -minimal and -base images? Nov 25 10:48:37 kanavin_home: reproducible-builds people also probably have an interest Nov 25 10:48:49 RP: yeah, I have no idea how receptive they would be to something coming from the yocto project. Google tends to do everything in a self-contained manner. Nov 25 10:49:03 (the go folks) Nov 25 10:49:28 kanavin_home: right, you'd think they'd want to try and support reproducibility but who knows... Nov 25 10:50:16 RP: at the moment go is at the fringes of dependency tree, so its non-reproducibility is not a major item, but that could change quickly Nov 25 10:50:36 kanavin_home: right, that is a worry :/ Nov 25 10:50:45 wyre: look at the recipes and packages that get installed to them. sato is a gnome image, minimal is rally minimal to boot into a shell. Nov 25 10:51:03 kanavin_home: it is really nice to have the list trimmed down to a definitive set of packages though :) Nov 25 10:51:38 wyre: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#usingpoky-extend-customimage Nov 25 10:52:31 RP: yes, let's see if a-full run reveals any additional items Nov 25 10:52:59 RP: I fixed the biggest items (in size) at least - webkit, llvm, etc Nov 25 10:53:50 RP: quite often it's full build paths somehow leaking into target, especially the source code in -src often refers to them when it's generated Nov 25 10:56:36 kanavin_home: right, I remember starting this journey and thinking it was near impossible :) Nov 25 10:57:17 kanavin_home: nice work on webkit and llvm, they're big beasts Nov 25 10:58:17 RP: it's tedious indeed, best taken in smaller chunks Nov 25 10:58:32 kanavin_home: right, that is how we end up here today :) Nov 25 10:58:41 kanavin_home: but having a target list is a big win Nov 25 11:14:36 mcfrisk, the point is when I use meta-engicam (the bsp layer) I have to use a different target from core-image-minimal, which is the one that I'd like to build πŸ€” Nov 25 11:16:57 wyre: no, for your product, you need to define an image. for a proof of concept and with limited use cases, one of the default images like core-image-minimal (boot to shell) or core-image-sato (boot to a GUI shell) can work. even without a BSP layer, you need to pick and choose what you want to be in your image. Nov 25 11:18:47 mcfrisk: hint: https://youtu.be/o-8g0TPVVGg Nov 25 12:26:30 Does somebody know the status of the poky tests in meta/lib/oeqa/sdk/cases/? I tried to run them via oe-test but this imediatly failed with an error: ModuleNotFoundError: No module named 'bb'. Is there another way to run these tests that I'm not aware of? Nov 25 12:36:24 bachp: bitbake -c testsdk Nov 25 12:37:17 RP: Thanks, is the oe-test scripts not intended to run directly? Nov 25 12:40:14 RP: When I run -c testsdk I get: Task do_testsdk does not exist for target core-image-sato Nov 25 12:44:52 I was missing INHERIT += "testsdk" Nov 25 12:51:49 bachp: ah, yes, you need that. autobuilder does run them all the time so they do work/pass Nov 25 12:59:40 training time, bye Nov 25 13:14:29 For development Purpose i need to comile the Programms static. So I let yocto build a SDK and added libstdc++-staticdev and ind SDKIMAGE_FEATURES i added staticdev-pkgs. When I install the SDK Compiing works but at Link time I get 'cannot find -lcrypt / -lpcre' I assume that these libs are not in the statsic form. Is the a chance to get all Libs Nov 25 13:14:30 also as Static into the SDK? Nov 25 13:35:19 schu-r: poky turns off static libraries, so that might be the problem Nov 25 13:35:56 Hi, I am trying to change the hard assigned KERNEL_IMAGETYPE from upstream machine config without having to create a fork. So I though I could do a `KERNEL_IMAGETYPE_append = " uImage-gzip"` and a `KERNEL_IMAGETYPE_remove = "zImage"` in my local config, as it is not weak assigned. This however gives me a QA Issue: `kernel-image-uimage-gzip is listed in PACKAGES multiple times`. What would be the proper way to deal with this? Nov 25 13:36:00 schu-r: if you need static libraries you should create your own distro that doesn;t disable static libraries Nov 25 13:37:02 rburton: I already have the glibc static. But not the others. Nov 25 13:39:38 RP: I've sent patches now for the problems I've seen with symbolic links and PSEUDO_IGNORE_PATHS. Nov 25 13:57:45 * zeddii reads and chuckles Nov 25 14:16:07 So I changed KERNEL_IMAGETYPE to a weak assignment for test purposes and tried to overwrite it in my local config, resulting in the same error. So it seems you cannot simply overwrite this variable? Nov 25 14:19:10 JaBen1: it depends (TM) Nov 25 14:19:58 JaBen1: the one true way (TM, too) is to look at the full evaluation history of the variable (bitbake -e) to actually understand whats going on. Nov 25 14:25:24 zeddii: do you have plans to move linux-yocto to 5.10 when it comes out? Nov 25 14:26:05 yep. -dev already has it cooking. 5.10 will become the LTS in master, and probably 5.11 as the "newer" kernel in the release. Nov 25 14:26:22 awesome, thanks Nov 25 14:29:46 zeddii: what was the phrase you had in lyon? "a system is always one level up from your own knowledge?" or something similar Nov 25 14:31:08 yes. I do recall saying something like that, as part of my containers thing. or was it the binary distro stuff. Nov 25 14:31:16 better than saying "it makes me feel dumb" Nov 25 14:31:25 which is true as well :) Nov 25 14:32:01 zeddii: but it was something made up on the spot, not a commonplace saying? Nov 25 14:32:24 Has anyone setup nodejs with pm2 on top of Yocto? I have a nodejs developer wanting this functionality added into our BSP, and I was wondering if anyone had any tips that I could leverage. Nov 25 14:32:37 it is something that I've heard locally to me, but that definitely doesn't make it common :D Nov 25 14:32:50 zeddii: i see Nov 25 14:33:50 Hey everyone, I just posted another question on SO just wanted to say hi to have the possibility to shed some light on that issue interactively :) https://stackoverflow.com/questions/65006727/configuring-the-bootloader-with-fw-env-config-and-config-env-offset Nov 25 14:33:52 of course from where I'm from, there's both unique dialects of english, french and combination of the two. Nov 25 14:34:06 rob_gries: other than pm2 having quite a number of dependencies and therefore maybe being problematic to package, i don't think it sustantially differes from other npm things. Nov 25 14:36:28 LetoThe2nd: I see... I just asked him to add the npm package into his package.json to see if we can get it in that way. Nov 25 14:40:12 rob_gries: the two main problems with npm generally are 1) nondeterministic behaviour, like things being fetched outside the fetches and not using the DL_DIR and 2) licensing woes, as its close to impossible to set your recipes license correctly if it actually pulls in a tree of dependencies. Nov 25 14:43:40 @LetoThe2nd: hm... looking at this, I am not quite sure how to read it :D but for some reasons `# override[kernel-image-uimage-gzip]:set kernel.bbclass:96 [__anon_108__mnt_poky_meta_classes_kernel_bbclass]` appears twice... Nov 25 14:44:04 which seems of to me Nov 25 14:44:21 JaBen1: put the evaluation history into a pastebin, then we can have a look Nov 25 14:45:02 @LetoThe2nd https://bin.snopyta.org/?226920870f06942f#7oPk4JpPn99rrAuGEN56S16Gzyg6kB63q5mMPpEAmhse Nov 25 14:47:01 JaBen1: too secure for me, browser stuck on "decrypting" Nov 25 14:47:20 emrius: those are just addresses in the storage medium Nov 25 14:47:29 you put the env more or less wherever you want Nov 25 14:47:42 provided it's not overwritting or overwritten by something else Nov 25 14:47:52 yes they need to be sync'ed Nov 25 14:48:07 (fw_conf and CONFIG_ENV_OFFSET) Nov 25 14:48:15 you might want to define CONFIG_ENV_SIZE also IIRC Nov 25 14:48:16 qschulz: Thanks! That helped a lot! Nov 25 14:49:13 @LetoThe2nd: give it some time... the document is just pretty huge :D Nov 25 14:49:19 Defining CONFIG_ENV_SIZE appears reasonable. Great :) Nov 25 14:49:25 Thanks! Nov 25 14:49:32 JaBen1: I gave until the tab crashed Nov 25 14:50:04 @LetoThe2nd: hm... worked for me... give me a sec. will try a different service Nov 25 14:50:13 beer counter: qschulz += 1. Let me know if you are ever around in Berlin ;) Nov 25 14:50:17 JaBen1: the some-ten-ish-lines of the variable evaluation would probably enough. Nov 25 14:50:46 emrius: bitbake += or python += :p? Nov 25 14:51:04 emrius: pleasure to help, no beer needed :) Nov 25 14:51:07 qschulz: VHDL += Nov 25 14:51:21 :) python Nov 25 14:51:31 LetoThe2nd: *sigh* the joke being qschulz = 2 in python but qschulz = 11 in bitbake :) Nov 25 14:51:42 actually qschulz = 1 1 but eh Nov 25 14:52:07 qschulz: thou shalt prefer bitbake then! Nov 25 14:52:28 ... Ah... python was just a dummy guess. Didn't get that one either. Another pythonic `+= 1` for clarification Nov 25 14:52:58 @LetoThe2nd: https://fancydomain.eu/f/65f3368baef14697873a/ Nov 25 14:55:30 @LetoThe2nd: Should mention I'm currently still stuck on thud Nov 25 14:57:43 JaBen1: i don't think that it makes a difference, but of course it can't hurt if you diff meta/classes/kernel.bbclass between thud and dunfell Nov 25 14:59:25 JaBen1: i see that there actually has been quite some changes. maybe even https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/classes/kernel.bbclass?id=9c800996e546bb67e8df77926b3378723e504808 Nov 25 14:59:54 JaBen1: so yes, i take back my last post and conclude it might be caused by thud. Nov 25 14:59:59 zeddii: maybe can comment. Nov 25 15:02:53 @LetoThe2nd hm... that would suck, as I don't see myself being to upgrade in the near feature, as ADI only supports thud atm. Was the log able to provide any useful info? Nov 25 15:05:12 JaBen1: to me it seems like the function in kernel.bbclass misbehaves and duplicates the setting. but for what reason i cannot tell, nor if the current state also exhibits this behaviour. if it is still present on dunfell you are invited to file a bugreport, in any other case, well, bad luck for you. then you'll have to pester ADI or figure it out yourself. Nov 25 15:06:05 JaBen1: what do you need from ADI? Nov 25 15:06:30 if it's just a BSP, then migrate to newer stuff by cherry-picking only what you need (kernel, bootloader, a few patches here and there) Nov 25 15:06:33 ditch the rest Nov 25 15:07:11 qschulz: it think that starts to qulify as yocto chant #2: "cherrypick the bsp, ditch the rest." Nov 25 15:08:43 LetoThe2nd: yeah, it's just *recipes* and kernel and bootloader are so independent from the rest of the system (heck it's usually not even part of the rootfs) that you can just take them out of your vendor crappy BSP layer Nov 25 15:09:12 @LetoThe2nd: Ok, I'll try to reproduce the problem on dunfell Nov 25 15:09:25 qschulz: you don't hear me disagreeing, do you? ;-) Nov 25 15:10:11 LetoThe2nd, why don't you run an image inside tmp/deploy/images/quemuarm in here https://youtu.be/ThTl4FItfMI?t=1827 ? Nov 25 15:10:32 @qschulz: That is the long term plan, working on it :D Nov 25 15:10:34 qschulz: but i still keep the position that its not my duty to handhold everybody burned by vendor bsps through the process. Nov 25 15:11:54 wyre: you men, why i don't pass the path to the image? Nov 25 15:12:11 LetoThe2nd, that's it Nov 25 15:12:51 wyre: because magic https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/runqemu.README#n24 Nov 25 15:13:13 JaBen1: honestly, sometime the layer is so bad that it might take you less time to just cherry-pick whatever you need Nov 25 15:13:31 JaBen1: FYI, we don't even try anymore, we just pick the kernel, bootloader, optee and atf and that's it Nov 25 15:13:37 heck, we even write the recipes ourselves :p Nov 25 15:14:07 wyre: in a nutshell - if you don't give runqemu stuff, it mostly can figure out from the last build. Nov 25 15:14:08 but tbf, we don't use any proprietary blob from our vendor so that helps Nov 25 15:14:18 (.e.g no gpu, vpu, etc...) Nov 25 15:16:17 @qschulz: yeah we have to include blob drivers for DSP... no fun Nov 25 15:17:35 I hoped to streamline the whole process and use more upstream to reduce maintenance work... but it seems like that won't be happening :( Nov 25 15:18:18 JaBen1: the thing is, if you invest time and money now, it should be relatively easy to upgrade in the near future Nov 25 15:18:36 JaBen1: the longer you wait, the more it'll cost and the more painful it'll be Nov 25 15:20:44 @qschulz: yep... that's what I'm trying to do. We are currently stuck on a yocto build environment that effectively hasn't been touched in 2 years and now I have taken up the ungrateful task to improve the situation... :/ Nov 25 15:21:08 JaBen1: I'll put you in my prayers Nov 25 15:21:41 thanks :D Nov 25 15:23:05 JaBen1: honestly that's the best way to learn things :) Nov 25 15:23:13 (not pray, upgrade :) ) Nov 25 15:40:05 so you say I need to define a custom image? I mean, .. cannot I use the recipes in the BSP? Nov 25 15:42:59 wyre: you don't WANT to use pre-made images. thats basically yocto rule #2 Nov 25 15:43:16 (#1 is recipe data is local, conf data is global!) Nov 25 15:43:43 LetoThe2nd, where can I read the yocto rules? Nov 25 15:43:56 wyre: here :) Nov 25 15:44:01 lol Nov 25 15:44:49 LetoThe2nd, so then the point is to take advantage of the BSP layer to make my own layer? πŸ€” Nov 25 15:45:13 wyre: not really no Nov 25 15:45:23 you build a system by having a collection of layers Nov 25 15:45:49 and building one specific image for a specific machine using specific distro settings Nov 25 15:45:50 wyre: no, you still don't get it. a BSP layer shall give you the infrastructure to use a board. and its your duty to add a layer on top that make the now booting board do what you want. Nov 25 15:46:04 BSP layer is for the "for a specific machine" part Nov 25 15:46:26 LetoThe2nd, but then I need all layers which the BSP depends on Nov 25 15:46:41 the BSP layer depends on, I mean Nov 25 15:46:53 wyre: a BSP layer should depend on almost nothing Nov 25 15:46:55 wyre: but again - i strongly advise to get some proper training to explain stuff in a coherent, curated manner. i feel you are wasting a lot of time and effort, (including that of helpful people here), just because you're basically cheap. Nov 25 15:47:23 and you can take only the parts you're ihterested in (kernel, bootloader, optee, atf, whatever) Nov 25 15:47:37 those usually don't depend on anything else than openembeded-core or at worst poky Nov 25 15:48:34 wyre: we have tried to explain the use cases and proper, working usage of a BSP layer at least 5 times now. i really think the community duty is fulfilled here. (shame on me letting myself be pulled in again, despite better knowledge) Nov 25 15:54:15 qschulz, I feel that layer has dependencies that I don't need https://github.com/engicam-stable/meta-engicam/tree/warrior Nov 25 15:54:18 like meta-qt5 Nov 25 15:54:29 I don't need qt5 for a minimal image Nov 25 15:55:28 LetoThe2nd, I'm reading the Rudolf Streif's book and watching your recommended playlist on youtbe Nov 25 15:55:38 but I've questions that's all .. Nov 25 15:55:49 wyre: worst case scenario, the layer is there but nothing from it is pulled Nov 25 15:56:02 also nowhere does it say that qt is needed in that layer Nov 25 15:56:34 @wyre: having the layer lying around is not an issue. especially when using kas which basically pulls all this dependencies automatically Nov 25 15:57:20 qschulz, https://github.com/engicam-stable/meta-engicam/blob/warrior/base/conf/bblayers.conf#L18 what about this? Nov 25 15:57:38 JaBen1, what's 'kas'? Nov 25 15:57:41 wyre: rudis book is massively outdated, and my videos are really the bare bones minimum. they are more like geared towards total newbie students. using whateve $VENDORBSP strongly suggests that you are doing this for a living, and i apply a whole different set of expectations then. but anyways. i'm out for today. have fun eerybody. Nov 25 15:58:36 @wyre https://github.com/engicam-stable/meta-engicam/blob/warrior/base/conf/bblayers.conf#L18 just tells yocto to include the layer. this does not necessarily mean that stuff from there is used during your build. Nov 25 15:58:40 wyre: never seen base/conf directory before, only conflayer.conf matters Nov 25 16:00:23 qschulz, so you think the layer is wrong designed? Nov 25 16:00:24 base/conf/bblayers.conf is the "Example" bblayer.conf you can use in your own build conf/ directory (AFAICT) Nov 25 16:00:28 @wyre: kas is basically a wrapper around bitbake projects (such as yocto): kas.readthedocs.io/ @LetoThe2nd made a good video on the topic: https://www.youtube.com/watch?v=KJHJlOtTdaE Nov 25 16:01:09 wyre: You are correct though; that layer does depend on meta-qt5 (although they forgot to explicitly list in LAYERDEPENDS) Nov 25 16:01:15 JaBen1, I think is better if I understand properly yocto before using a wrapper Nov 25 16:01:27 JPEW: vendor BSPS *le sigh* Nov 25 16:01:42 JPEW, you mean here? https://github.com/engicam-stable/meta-engicam/blob/warrior/conf/layer.conf#L27 Nov 25 16:01:55 wyre: yes Nov 25 16:02:02 wyre: ya Nov 25 16:02:49 wyre: The problem is they've written *at least* one recipe that does "inherit qmake5" which will not parse if you don't have meta-qt5 Nov 25 16:02:51 so you think could I extract from that BSP layer actually the minimal necessary to get a bootable image? Nov 25 16:03:01 Is there a local.conf variable for specifying the amount of memory for runqemu to boot with? Nov 25 16:03:27 @wyre: you can use kas basically like a normal bitbake project if you want (kas shell). but it removes the pain of manually having to prepare your build environment Nov 25 16:03:29 tgamblin: QB_MEM Nov 25 16:03:45 JPEW: thanks! Nov 25 16:04:07 JPEW, qschulz what do you think about freescale-layer and fsl-demos dependencies? Nov 25 16:04:28 I know meta-freescale, meta-freescale-distro or meta-freescale-3rdparty but I dont know freescale-layer Nov 25 16:04:35 and fsl-DEMOS? Nov 25 16:04:44 I don't want any demo 😠 Nov 25 16:05:17 wyre: Sure.... it depends on what you are going for.... if you just want something that boots, I would pull in everything you need as a first pass Nov 25 16:05:24 freescale-layer == meta-freescale, that's it's layer name in its layer.conf Nov 25 16:05:36 wyre: don't know any of those and as I said sometime ago, I don't use vendor BSPs for avoiding being in your situation :) Nov 25 16:05:48 to avoid* Nov 25 16:05:54 :D Nov 25 16:06:16 wyre: Ya, It's a little confusing but the layer "name" it not always the same as what most people call it "meta-foo" Nov 25 16:06:18 JPEW: I think they managed already, but want to use warrior instead of pyro for some pytho dependency Nov 25 16:07:39 wyre: Ah, so you are past the "have it booting" stage and are at the "want to customize it" part? Nov 25 16:12:36 JPEW, exactly Nov 25 16:13:44 wyre: Ok, well in that case, you have a few options: Nov 25 16:14:57 1) use the BSP as-is with all the dependencies. You may want to audit what ends up in your final image, but well-written BSP layers shouldn't be inserting stuff you don't *actually* need, so you don't really need to worry about the layer dependencies so much Nov 25 16:15:31 (e.g. the BSP may depend on the freescale demo layer, but that doesn't mean it's going to throw a bunch of demo crap in your images) Nov 25 16:16:12 2) Tear down the BSP existing BSP to remove things you don't want (usually with some surgical BBMASK) Nov 25 16:16:27 3) Build up your own BSP using theirs as a starting point Nov 25 16:18:52 wyre: That BSP in particular doesn't look very good. It's changing a lot of things that it shouldn't (busybox, init-ifupdown, etc.) so #1 isn't a good option Nov 25 16:20:53 I managed to bash meta-fsl-bsp-release into AGL at one point earlier this year, but decided it wasn't worth the hassle and threw that work away Nov 25 16:21:16 wyre: I suspect you don't *actually* need that much from the engicam BSP layer, so if it were me, I'd probably make my own BSP layer Nov 25 16:22:08 smurray: Ya, we always just end up using meta-freescale Nov 25 16:22:42 JPEW, thank you very much, you were so helpful 😊 Nov 25 16:23:09 wyre: np Nov 25 16:23:11 I think is a good idea to use the current BSP as a starting point Nov 25 16:23:37 but what would you say are the most important parts in this BSP? Nov 25 16:23:51 I mean, is there something that depends on the actual hardware? Nov 25 16:24:03 wyre: you'll have to figure that out Nov 25 16:24:45 wyre: if engicam have a machine conf for their board, look at what it configures Nov 25 16:24:47 wyre: It's hard to say *exactly* without digging and know your use case, but a BSP should be providing the stuff you need to get the hardware up (and not much else)... kernel, device drivers, that sort of thing Nov 25 16:25:08 JPEW, so I guess freescale-layer is needed Nov 25 16:25:24 wyre: BSP stands for Board Package Support, so semantically a BSP layer should only contain things related to a particular hardware :) Nov 25 16:25:25 the point I think is in the demos and qt5 πŸ€” Nov 25 16:25:43 wyre: it's not because you have layers that you'll build what's in it Nov 25 16:25:54 wyre: Right. The good news there is that meta-freescale is higher quality, so I wouldn't worry too much about bringing that in Nov 25 16:26:09 oh, yes, smurray I was actually using this one https://github.com/engicam-stable/meta-engicam/blob/warrior/conf/machine/microgea.conf Nov 25 16:26:09 wyre: see it as an possibly unused C header file. it's there, you need it because it's included, but maybe nothing uses it. Nov 25 16:27:09 wyre: well.. bad example as the header is still part of the build. meh. time to stop, you're in good company with JPEW and smurray anyway Nov 25 16:27:41 wyre: Right, so based on that machine.conf file, you *at a minimum* need a BSP layer that has: that machine.conf file, linux-engicam and u-boot-engicam Nov 25 16:36:24 JPEW, I guess I have to write a new recipe for an image also, is that right? Nov 25 16:37:20 I say this because I was using this https://github.com/engicam-stable/meta-engicam/blob/warrior/recipes-images/images/engicam-test-hw.bb as target when running bitbake Nov 25 16:38:54 and what about the freescale-layer dependency? I guess could I maintain it and incude also meta-freescale, right? Nov 25 16:39:37 wyre: Yes, I would pull in meta-freescale as-is. You don't want to maintain your own copy of that layer Nov 25 16:40:15 wyre: Maintain your own fork of that layer Nov 25 16:40:40 Argh, keep hitting enter too soo: You don't want to maintain your own fork of meta-freescale Nov 25 16:40:47 JPEW, of course, I'm cloning the repos :-) Nov 25 16:41:57 JPEW, and regarding image? am I right? Nov 25 16:42:52 wyre: you're going to need to make an image recipe for your own use anyway, seems reasonable to start with that one Nov 25 16:58:27 wyre: in addition to all valuable feedback you've received here, i would also suggest you start with "simple" setups, which does not involve heavy-lifting graphics and Qt layers on top. Nov 25 17:00:20 we've already looked into this several days ago, and the engicam layer support is much to be desired. you can discard it for the moment, and start from a very basic setup, where you would just need to create your layer, bring the machine definition from engicam into it, and build one of core-images available to see if your HW is running fine. Nov 25 17:01:13 for this you would require only meta-freescale; meta-freescale-distro can be taken later on when you would start to dig into graphics and Qt Nov 25 17:15:04 Hi, I'm trying to use a specific and old version of u-boot in meta-ti for a beaglebone black. I'm on the fido branch of Yocto. Is it suppose to work if I added theses lines to my local.conf file Nov 25 17:15:33 zandrey, that's exactly what I want (remove all these heavy-liting graphics and layers on top) Nov 25 17:15:33 PREFERRED_PROVIDER_virtual/kernel = "linux-ti-staging" Nov 25 17:15:33 PREFERRED_VERSION_linux-ti-staging = "3.14%" Nov 25 17:15:33 PREFERRED_PROVIDER_u-boot = "u-boot-ti-staging" Nov 25 17:15:33 PREFERRED_VERSION_u-boot = "2014.07" Nov 25 17:17:29 Oups, sorry I made a mistake. PREFERRED_VERSION_u-boot-ti-staging = "2014.07" Nov 25 17:19:53 erakis: why? the bbb is supported upstream so it makes little sense to actually require such old version Nov 25 17:20:07 same for kernel Nov 25 17:25:31 @qschulz: You're right. But this is old configuration that we have and I'm not the author. I pull all new changes from the fido branch yesterday and this broke the u-boot mmc detection while booting (https://groups.google.com/g/beagleboard/c/BeoIKY4zpm0/m/ygOz3Zz1BAAJ). The only way I found to fix it is to downgrade the version to 2014.07. Nov 25 17:26:41 @qschulz: And seriously, my knowledge of Yocto is quite limited :| Nov 25 17:28:15 fido is so old that I suspect you're going to be on your own there Nov 25 17:31:10 @qschulz: We are still using the kernel 3.14 !!!! I remember two years ago we tried to migrate to Krogoth branch with the help of Scott Ellis. We succeed but there was a really HIGH CPU USAGE when using serial port with the new kernel. We never been able to fix it. So we gave up :( Nov 25 17:31:46 smurray: I know, this is what I often repeat to my supervisor ;) Nov 25 17:33:56 Anyway, thank you guys ;) Nov 25 17:34:13 erakis: there's a beaglebone.conf in meta-ti, I'd recommend just using that as MACHINE if you need something the TI kernel has Nov 25 17:42:02 smurray: Honestly, Yocto we ended up understanding when playing in it, but for the device trees I never understood anything so it's quite penalizing when playing with the u-boot or the kernel and especially if we have specific hardware like an RGB screen or stuff plugged into the GPIOS. Which is our case. Nov 25 17:43:36 erakis: devicetree is its own beast, indeed Nov 25 17:54:23 RP: did you see the latest set of patches I had to numpy ? any thougths ? Nov 25 18:25:14 is it possible to install pypi whl packages with yocto thud. they seems to not work as the tar.gz ones Nov 25 18:25:32 ? Nov 25 18:36:06 rcrudo: I don't expect that would work well. Python "wheels" are pre-built for particular platforms Nov 25 18:45:47 wyre: you can try our new Engicam setup here https://github.com/koansoftware/koan-engicam-mx6-bsp-repo Nov 25 19:22:37 wow! mckoan|away that's pretty awesome! but ... why do you use repo? Nov 25 19:31:03 Hi man Nov 25 19:31:07 I am back Nov 25 19:31:31 The trustedfirmware CI work is just huge! Nov 25 19:31:39 we (linaro) cannot just conclude it Nov 25 19:32:09 anyway, now swatting the rest of the day Nov 25 20:18:22 wyre: I use repo because I love it Nov 25 20:18:37 mckoan, it's not similar to git? Nov 25 20:19:08 wyre: is a kind of git multi repo manager Nov 25 20:20:25 good night Nov 25 22:22:16 Hi Nov 25 22:22:38 Can anyone help how to change the renderer behind wayland Nov 25 22:22:52 It is uselessly laggy now :( Nov 25 22:26:04 linums: You probably want to use the drm backend in weston.ini Nov 25 22:26:13 linums: if your hardware supports it Nov 25 22:31:02 Supposedly it is, I've seen the same machine used for better performance wayland run :D Nov 25 22:31:28 Well, thanks, this solution sounds really easy :D Nov 25 22:43:06 linums: /etc/xdg/weston/weston.ini I think Nov 25 22:48:51 Yeah, and I have the drm backend compiled, so soon I will know it =) **** ENDING LOGGING AT Thu Nov 26 02:59:57 2020