**** BEGIN LOGGING AT Mon Mar 08 02:59:57 2021 Mar 08 06:33:36 hi trying meta-raspeberypi I got ERROR: No recipes in default available for: Mar 08 06:33:36 /home/gilles/Developpements/yocto/meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.18.%.bbappend Mar 08 06:33:39 idea ? Mar 08 06:56:03 ok found Mar 08 07:43:36 good morning Mar 08 07:44:17 good morning everyone. Quick question: is there a reason to prefer ipkg over deb packages? Mar 08 07:45:46 sorry, i meant opkg Mar 08 07:47:45 flash27: the heaviness. IPK is the lighter but with less features, then DEB, and RPM is full featured bit heavier Mar 08 07:48:03 s/bit/but Mar 08 07:48:38 flash27: that's the reason why IPK is preferrend in embedded systems Mar 08 07:50:52 mckoan: i noticed that IPK seems the default choice in yocto. Do you have idea of which are the features missing? I could not find a lot regarding IPK. If you know of some comparison, it would be great Mar 08 07:51:02 if not, thank you the same for the answer Mar 08 08:10:12 flash27: https://openwrt.org/docs/guide-user/additional-software/opkg Mar 08 08:14:22 yo dudX Mar 08 08:15:09 LetoThe2nd: hi Mar 08 08:19:06 @mckoan thank you Mar 08 09:15:08 jonesv[m]: IIRC, the device tree is part of the defconfig in U-Boot, c.f. CONFIG_DEFAULT_DEVICE_TREE Mar 08 09:21:03 I have an out-of-tree kernel module that I build with a bitbake recipe. I would like to create a toolchain/sysroot in the same way as a generic yocto SDK so that I can let external parties build the same module against our kernel without having access to our wider Yocto workspace. Is this possible? Mar 08 09:35:06 bps: doesn't the generic sdk do the trick? maybe with enabled kernel-devel feature orwhatsitcalled. Mar 08 09:36:06 that would probably do the job but I just wondered if I could make a slimmed-down version, since all I'm building is a kernel module Mar 08 09:39:33 hum. i think there is a meta-toolchain target somewhere, but not sure if its maintained properly. so if at all i would just build the sdk for core-image-minimal to pull in as little as possible and live with it, unless there is good reason to spend additional effort. Mar 08 09:41:30 bps: bitbake meta-toolchain is what you need Mar 08 09:42:01 hmm thanks, I'll take a look Mar 08 10:35:42 Hi Mar 08 10:35:56 can we create a class in bbclass file Mar 08 10:36:08 if yes what is the syntax Mar 08 10:36:46 https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#functions Mar 08 10:36:54 i was able to follow and use functions Mar 08 10:46:02 Manju: pretty sure one can define classes within python functions/tasks Mar 08 10:46:15 Manju: but what exactly do you want to do that requires classes? Mar 08 11:03:45 i want to create objects Mar 08 11:03:52 of a class Mar 08 11:04:26 anywhere you can write python, you can define a class. Mar 08 11:05:12 * LetoThe2nd thinks it would be classy to stand in front of a class and explain classes of classes. Mar 08 11:05:46 will i t be of same syntax Mar 08 11:05:54 as in normal python Mar 08 11:06:17 like eg: class myclass: Mar 08 11:17:26 Manju: you're not explaining why you want classes. I'm considering you want to share objects between tasks/functions and I'm pretty sure it cannot work in Bitbake but happy to be proven otherwise Mar 08 11:19:02 the datastore (d) just stores python objects, so yes you can put a class instance in it if you want Mar 08 11:19:41 Manju: when you're somewhere you can write python, that text is literally given to the python interpretter. you can't just do class foo: at the top level of a bbclass, because you can't write python there. Mar 08 11:20:26 rburton: also to the python interprettier? Mar 08 11:20:37 * LetoThe2nd is severely undercaffeinated. or underbeered. Mar 08 11:20:55 LetoThe2nd: at that level, probably should mix beer and coffee just to be safe Mar 08 11:22:12 qschulz: i have conducted extensive experiments, and i can confirm that its not that easy. mixing alcohol and caffeine takes quite some experience to actually archieve desirable effects, instead of just bad taste. Mar 08 11:22:48 LetoThe2nd: then go for irish coffee, extensive test was done on that recipe Mar 08 11:23:08 just want to know the syntax then Mar 08 11:23:24 i didnt quiet get rburton Mar 08 11:23:51 Where you're writing python, just define the class Mar 08 11:23:57 qschulz: Test Driven Development! Mar 08 11:24:17 ok Mar 08 11:24:26 * LetoThe2nd oO( Test Driven Drinking ) Mar 08 11:25:36 like python class foo: Mar 08 11:26:02 python class foo: Mar 08 11:26:18 python class foo(): Mar 08 11:27:12 sorry for my poor understanding here Mar 08 11:27:38 Manju: in a python task or function only. so in your bbclass/recipe, python some_func() { class Foo: } Mar 08 11:28:00 ok Mar 08 11:28:16 Thanks qschulz Mar 08 11:54:33 @LetoThe2nd: Oida - Irish coffee is good for me - effects achieved ;) Mar 08 11:59:55 RobertBerger: OIDA! Mar 08 12:00:27 ;) Mar 08 14:20:04 Hi all Mar 08 14:20:14 I'm newbie of yocto and I've a question: Given a target image is it possibile to have a list of packages installed on rootfs? Mar 08 14:21:16 ventoneicapelli: its not only possible. just look at the .manifest file that is generated along the image file. Mar 08 14:24:13 Hi LetoThe2nd and thanks. Is it also possibile during execution say from a python function, I would like to store packages (ipk/rpm/deb) automatically... Mar 08 14:25:48 ventoneicapelli: anythign is possible, its only software. but what is it you ACTUALLY want to do? Mar 08 14:28:01 I would like to get list of package used to build the rootfs, then get those packages and store them on a server Mar 08 14:28:44 that can mean many things. Mar 08 14:29:39 plus it still sounds like you are actually trying to do something actually very much different, and you think that copying the packages is the way to do it. what is it you ACTUALLY want to do? Mar 08 14:30:45 because in itself the question does not make much sense. on a clean build there is basically nothing unneeded, so if you run a clean build then all of the package output is important. but the pakcage output is by definition transient... so? Mar 08 14:33:34 you are true, I would like to run a function on a subset of binaries that are part of the rootfs. Those binaries are the ones selected by a list of packages Mar 08 14:34:13 and I'd like to do this step as a ROOTFS_POSTPROCESS_COMMAND Mar 08 14:36:24 so, given a set of package I need to get binaries (executable) produced by and apply a function on them Mar 08 14:36:40 before creating the image Mar 08 14:38:42 it still sounds wrong. Mar 08 14:38:51 you want to modify the binaries in the package? Mar 08 14:39:15 what is it you *REALLY* want to do? Mar 08 14:39:45 some arcane magic because your binaries are so special? sign a binary? sign the image? Mar 08 14:40:06 license complicance scanning? because chances are that you are basically on the wrong track Mar 08 14:40:29 no its not a matter of licensing Mar 08 14:40:37 no it's not a matter of licensing Mar 08 14:41:14 essentially I would like to tag a binary add an elf section Mar 08 14:42:06 to be used in a lsm module to check the binary Mar 08 14:42:28 sounds like somethign that should go into a do_compile postfunc Mar 08 14:42:59 but I have to do on recipes written from others.... Mar 08 14:43:19 hooray! breaking news, we do have bbappends! Mar 08 14:43:36 I said I was a newbie, sorry Mar 08 14:43:50 I said I AM a newbie, sorry Mar 08 14:44:14 and i repeatedly said "what is it you actually want to do" Mar 08 14:44:41 it's not a secret I would try to keep things small... Mar 08 14:44:56 no offense meant, but seriously - google XY question, you've just delivered a prime axample. Mar 08 14:45:25 and i'm still mostly convinced that you are actually on the wrong thinking lines. Mar 08 14:45:39 oh no...why? Mar 08 14:47:01 I'll have a look at compile postfunc with bbappend and try play with it Mar 08 14:48:12 is there a way to add a function to be called from every package? Like a hook for package tasks.... Mar 08 14:48:22 because your questioning is so inconsistent. first you talk about a list of packages. then you say you want to put them on a server. then you say you want to do some binutils magic, basically. that all doesn't go together. its inconsistent. it suggests that you are actually trying to solve a completely different problem, of which you think those things are partial steps. Mar 08 14:51:27 Hello, what are the possible explainations that dependency library is stored correctly in .../recipe-sysroot/usr/lib, but the configure script fails to find it with pkg-config? is there anything more than add it to `DEPENDS`? Mar 08 14:51:43 Blackbetty: inherit pkg-config ? Mar 08 14:51:48 LetoThe2nd, I'm just trying to think about your new directions. Thank you for your help I don't want you to spend more time Mar 08 14:51:53 Thanks a lot Mar 08 14:52:06 ventoneicapelli: have fun Mar 08 14:52:08 thanks, but pkg-config is inherited Mar 08 14:52:20 Blackbetty: no problem, but you didn't mention that so far. Mar 08 14:52:21 PetoThe2nd have fun too Mar 08 14:52:37 im talking about `mesa` recipe which cant find `libdrm` Mar 08 14:53:21 LetoThe2nd: he/she did a typo that means 'Fart'the2nd Mar 08 14:53:56 :-D Mar 08 14:56:47 RP: Mar 08 14:56:52 2021-03-08 09:55:00,931 - oe-selftest - INFO - RESULTS: Mar 08 14:56:52 2021-03-08 09:55:00,932 - oe-selftest - INFO - RESULTS - reproducible.ReproducibleTests.test_reproducible_builds: PASSED (4759.01s) Mar 08 14:56:52 2021-03-08 09:55:02,615 - oe-selftest - INFO - SUMMARY: Mar 08 14:57:07 alt.perf.die.die.die Mar 08 14:58:20 zeddii: nice :) Mar 08 14:58:50 unfortunately, it's a hack now. since I can't get bison to not generate path specific #ifdefs, even with that flag Mar 08 14:59:04 so I compile -> generate the .h's, fix them -> recompile. Mar 08 14:59:13 but it does prove that's the last thing. Mar 08 14:59:30 but perf builds so fast, it really doesn't make a difference. Mar 08 15:00:30 zeddii: Knowing where the issues are is half the battle! Mar 08 15:04:58 zeddii: Hmm, there must be more bison hacks needed :/ Mar 08 15:05:08 zeddii: Err... "fixes" :) Mar 08 15:06:10 mckoan: no idea how you guessed it but its actually unbelievable fitting today. (TMI) Mar 08 15:06:42 Blackbetty: mesa is a complicated beast which i always avoid, sorry. Mar 08 15:07:02 :( I always tried to avoid it too Mar 08 15:08:32 so maybe wider question - Im trying to run QtWebEngine on arm. And well - it works. But with no hw acceleration its really slow. I thought - building opengl/mesa would allow me to use hw acceleration. Is it even a good path? Mar 08 15:09:15 Blackbetty: Mesa is only going to give hardware acceleration if it supports your GPU Mar 08 15:09:26 Otherwise, it will fallback to SW acceleration Mar 08 15:09:38 "acceleration" rather ;) Mar 08 15:11:15 SW deceleration! Mar 08 15:12:12 :D Mar 08 15:12:20 ye, its unusable Mar 08 15:13:03 but mesa should support that, its snapdragon Mar 08 15:18:12 Blackbetty: check it's supported by mesa, then check if your kernel has support for your GPU, then check it's enabled and correct in the Device Tree Mar 08 15:18:30 Blackbetty: what I usually do is install libdrm-tests and check with kmscube first Mar 08 15:18:42 if it does not work with kmscube, you're in deep shit Mar 08 15:18:52 oh thats a good advice! i didnt know kmscube Mar 08 15:21:30 from what I found out the configure script doesnt really check if pkg-config shows the lib, but if LIBDRM_CFLAGS and LIBDRM_LIBS is set... Im not super familiar with autotools (only on user level), what should set those flags? Mar 08 15:38:26 Blackbetty: have you added freedreno in PACKAGECONFIG of mesa by any chance? Mar 08 16:29:41 paulbarker: do you know when the prserv patches will be ready? Wondering what to do in the context of the release... Mar 08 16:34:49 zeddii: Could you have a look at meta/recipes-core/images/build-appliance-image_15.0.0.bb and tell me if that bit about kernel modules looks totally bogus to you? Mar 08 16:35:04 zeddii: as far as I can see kernel-devsrc has that all sorted now Mar 08 16:41:57 RP: yah, everyone gets that with -devsrc now. Mar 08 16:42:21 zeddii: thanks, I'll get rid of it Mar 08 16:49:41 zeddii: ironically that fixes this runqueue issue I've been chasing but glad to have a proper fix for that Mar 08 16:52:26 so it was somehow racing ? Mar 08 16:56:01 Does beaglebone-yocto support graphics acceleration? Mar 08 16:56:15 zeddii: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=ca572e9144da7858949d9aaf42be4b349a352d8c Mar 08 16:56:35 zeddii: corruption of runqueue's internal state Mar 08 16:59:32 ahahah Mar 08 17:00:02 nasty. I can feel the aura of time spent debugging from the commit. Mar 08 17:04:12 zeddii: 5 days :/ Mar 08 17:04:29 at least you have an answer Mar 08 17:04:59 fray: I had to get to the bottom of it Mar 08 17:15:10 zeddii: could we put a README into yocto-kernel-tools saying where to sent patches/who maintains it? Mar 08 17:32:20 hello I build a raspberry image from raspberrypi4-64 and I compiled for sd card... can I change MACHINE to qemuarm64 and recompile ? I got the message from runqemu deploy/images/qemux86-64 not a directory valid DEPLOY_DIR_IMAGE Mar 08 17:32:23 idea ? Mar 08 17:42:23 jdrol: rebuild with MACHINE=qemuarm64 and then use runqemu Mar 08 17:42:52 though you have to understand, most things from raspberrypi4-64 won't be in your qemu image Mar 08 19:22:48 Is Khem here.... Guest27389 maybe? Mar 08 19:32:06 yes I am here Mar 08 19:35:03 khem: Did you see my image_types_simg patch in meta-oe? I think I forgot to CC you Mar 08 20:11:34 hahah. found the hiding bison call in perf. I can delete my hack now. J Mar 08 20:40:45 can you remove a dependency added to do_image_wic[depends]? Mar 08 20:42:32 do_image_wic[depends]_remove obviously doesn't work. Mar 08 20:44:13 vdl: whats the usecase? Mar 08 20:45:18 LetoThe2nd: the board definition i'm using sets do_image_wic[depends] += "u-boot:do_deploy" but I want to use another bootloader, hence removing this dependency Mar 08 20:46:42 JPEW: infact I missed it, looks ok to me Mar 08 20:48:25 vdl: is the board definition actually worth it? otherwise, just copy+refactor Mar 08 20:51:01 vdl: that strikes me as an odd way to do that, could be done with EXTRA_IMAGEDEPENDS Mar 08 20:51:55 smurray: yeah, sounds like another glorious bsp. Mar 08 20:52:54 LetoThe2nd: smurray: the guilty is meta-ti, the beaglebone machine EXTRA_IMAGEDEPENDS += "u-boot" as well as do_image_wic[depends] += "u-boot:do_deploy"... Mar 08 20:53:35 denix: wake up! :) Mar 08 20:54:25 so I was considering defining my own machine, like beaglebone-yocto, because only including the SoC .inc file really matters. Mar 08 20:54:50 though i have to say, swapping out the bootloader is in fact rare enough a requirement that i'll give the bsp an okay for that. copy-hacking into an own machine is probably the way to go. Mar 08 20:55:16 yeah Mar 08 20:56:00 my conclusion was that a bsp layer really is a way to provide a bootable config, but is hardly reliable to define your own boards. Mar 08 20:56:42 well, for the ones from SoC vendors they use what they support Mar 08 20:57:20 so "it depends" Mar 08 20:57:43 if you want a different bootloader than TI provides out of the box support for, some assembly required shouldn't be a surprise Mar 08 20:58:10 yeah and meta-ti depends on meta-arm and meta-arm-toolchain, but getting rid of this doesn't look like a bad idea... Mar 08 20:59:10 it all depends on the usecase Mar 08 20:59:13 meta-arm is required for the optee firmware, that's actually part of a slow path of improvement versus every vendor having their own Mar 08 20:59:39 smurray: well I kinda disagree because on paper you should be able to set PREFERRED_PROVIDER_virtual/bootloader = "other" and you're done ;-) Mar 08 21:00:10 smurray: what's the optee firmware? Mar 08 21:00:37 vdl: https://www.op-tee.org/ Mar 08 21:01:35 hum, not sure I need this Mar 08 21:01:48 if you're on am335x, you don't Mar 08 21:02:20 but TI support other aarch64 based SoCs in that layer that need it Mar 08 21:02:42 smurray: do you know if graphics-wise, beaglebone-yocto can do the same as meta-ti's beaglebone? Mar 08 21:02:43 optee is a secure OS Mar 08 21:03:23 the beaglebone is am335x indeed, so that is not required. Mar 08 21:03:58 vdl: not right off, I've not had any need for graphics on a beaglebone board in a long time. denys would have an idea if he's around Mar 08 21:04:28 LetoThe2nd: btw beaglebone-yocto does the same IMAGE_EXTRADEPENDS + do_image_wic[depends] trick. Mar 08 21:04:40 vdl: be easy enough to test it with core-image-sato + MACHINE="beaglebone-yocto" Mar 08 21:05:25 smurray: right I'll try this. Mar 08 21:05:50 so I might not even need linux-ti-staging from meta-ti as well... Mar 08 21:07:16 vdl: RP made the change that adds that to beaglebone-yocto.conf, he might be able to comment. I'm not quite sure I follow the explanation in the commit message Mar 08 21:07:42 smurray: what's the problem? Mar 08 21:08:42 vdl: which graphics do you mena? if you mean 3D, then you need out-of-tree SGX drivers from meta-ti, which unfortunately also need kernel patching, that is part of linux-ti-staging Mar 08 21:09:39 smurray: do_image_wic() does not respect IMAGE_EXTRADEPENDS. so if you want to place bootloader into your SD card image, you need to ensure it's deployed Mar 08 21:10:46 vdl: virtual/bootloader is not as widely recognized as virtual/kernel. hence "u-boot" itself is a provider, so you need PREFERRED_PROVIDER_u-boot = "other" Mar 08 21:11:56 vdl: I guess you could change machine config to do_image_wic[depends] += "virtual/bootloader:do_deploy" Mar 08 21:12:51 that'd be more appropriate, it's the purpose of virtual/bootloader after all. I'll try that Mar 08 21:13:07 denix: really? they get added as deps of do_image_complete which do_image_wic should depend on, shouldn't it? Mar 08 21:13:53 denix: so support for 3D graphics is the only thing that linux-ti-staging provides compared to linux-yocto or mainline for example? Mar 08 21:16:10 vdl: not only Mar 08 21:16:26 khem: Thanks! Mar 08 21:18:17 vdl: I'd guess more advanced power and thermal support, among others. but otherwise beagle/am335x has quite extensive coverage in mainline - it's a simple architecture... Mar 08 21:20:15 I think meta-ti version works well especially when your real product will be another TI SOC which usually is case, then using meta-ti kernel would give you some advantage since thats what u will use in the end Mar 08 21:20:29 denix: thank you. At least yocto makes it easy to switch between kernel providers if I need some proprietary bits from TI Mar 08 21:22:03 smurray: I don't remember all the details, but it never worked that way - I can try tracing it down later, when I have more time Mar 08 21:23:02 denix: does u-boot-ti-staging provides an TI specific bits or is it just the bootloader of choice? Mar 08 21:23:12 any* Mar 08 21:25:53 denix: okay, no worries Mar 08 21:32:13 vdl: as both names suggest, linux-ti-staging and u-boot-ti-staging were created as a "temporary" staging area for any changes to support TI platforms until they are fully upstreamed. the original idea was to eventually don't have any needs in this staging trees, once everything will be in mainline. so older platforms are closer to that goal, while newer platforms take very long time to upstream everything Mar 08 21:33:31 denix: I see! With 3d graphics for example be one of them. Do you have any idea of the upstream status for the beaglebone black? Mar 08 21:36:31 funny, beaglebone-yocto sets DEFAULTTUNE ?= "cortexa8hf-neon" while meta-ti's beaglebone has DEFAULTTUNE ?= "armv7athf-neon" Mar 08 21:46:56 vdl: SGX is a binary blob mess, so unupstreamable Mar 08 21:48:22 vdl: yes, and I responsible for both... :) I had them both set to cortex originally, but changed meta-ti back to armv7 to share packages with other platforms. the performance gain is negligible Mar 08 21:50:36 denix: interesting! Regarding u-boot-ti-staging I meant to ask if it does any particular hardware initialization or something that I might need beside linux-ti-staging? Mar 08 21:51:49 I think armv7athf-neon is better since it would use thumb2 ISA which is compact and most tested on armv7+ so practically it will be optimized path Mar 08 21:52:27 I would not be surprised if it even performed better over cortexa8hf-neon tune Mar 08 22:03:06 khem: Sent an updated patch for the sparse images.... forgot to CC you again :) Mar 08 22:20:28 denix: this fixes using a different bootloader for beaglebone: http://ix.io/2Scn Mar 08 22:23:21 zeddii: congrats on the find :) Mar 08 22:30:33 test build running now. with any luck, I'll send the changes out tomorrow. Mar 08 22:44:30 zeddii: nice :) Mar 08 23:06:40 JPEW: np I got it this time **** ENDING LOGGING AT Tue Mar 09 02:59:57 2021