**** BEGIN LOGGING AT Thu Jan 17 02:59:57 2019 Jan 17 15:38:55 <__deetz__> I managed to achieve *something* using do_deploy. but not without using do_rootfs as well, and my device tree overlay upending in the rootfs. This is not a disaster, but ... I presume there is a better way, still. Jan 17 15:40:34 <__deetz__> This is my recipe: Jan 17 15:40:35 <__deetz__> https://pastebin.com/bvjViHYH Jan 17 15:40:50 that's wrong Jan 17 15:41:12 remove the do_rootfs/do_image cruft, theres' no point to it Jan 17 15:41:43 just add your recipe name to EXTRA_IMAGEDEPENDS and it'll get built when you build another image, but won't end up insid ethe image Jan 17 15:43:10 <__deetz__> I've tried that, and it failed. But I give it a go again. Jan 17 15:43:17 <__deetz__> It is in EXTRA_IMAGE_DEPENDS Jan 17 15:43:30 <__deetz__> build is running, let's see what happens... Jan 17 15:44:15 "failed" is not useful information Jan 17 15:44:22 and it's EXTRA_IMAGEDEPENDS, not EXTRA_IMAGE_DEPENDS Jan 17 15:44:35 if it's not doing what you want, and you want assistance, you'll need to expand on exactly what the behavior is Jan 17 15:44:45 <__deetz__> I miswrote. Jan 17 15:45:07 <__deetz__> EXTRA_IMAGEDEPENDS_append = "myspi" Jan 17 15:45:13 that's wrong Jan 17 15:45:14 <__deetz__> is what I have in my machine conf Jan 17 15:45:16 missing leading space Jan 17 15:45:27 _append is a concatenation, it wont' add a space between the existing contents and myspi Jan 17 15:45:41 EXTRA_IMAGEDEPENDS_append = " myspi" Jan 17 15:46:53 <__deetz__> thanks. I updated the conf Jan 17 15:48:08 what's the failure mode here? is it just not building at all? Jan 17 15:48:26 <__deetz__> nope, it was complaining about the myspi.dtbo not being found Jan 17 15:48:42 <__deetz__> IMAGE_BOOT_FILES_append = " myspi.dtbo;overlays/myspi.dtbo" Jan 17 15:48:55 <__deetz__> that's the directive for wic Jan 17 15:48:58 <__deetz__> and wic was failing Jan 17 15:49:17 <__deetz__> what can I say? Jan 17 15:49:20 <__deetz__> it seems to work. Jan 17 15:49:55 <__deetz__> hm. Jan 17 15:50:04 <__deetz__> I still got the dtbo in the / of my image. Jan 17 15:50:16 <__deetz__> sorry, rootfs, not image .on my device Jan 17 15:50:31 that depends on the packages being installed in the rootfs Jan 17 15:50:37 deploy or not deploy won't have an effect on that Jan 17 15:50:45 most likely you want to just not install myspi package in the rootfs Jan 17 15:52:55 <__deetz__> I had myspi referenced in MACHINE_ESSENTIAL_EXTRA_RDEPENDS Jan 17 15:54:08 ah, that'd do it. that varaible adds the packages to the base packagegroup, which installs it in all images that include it Jan 17 15:54:53 this is not unlike a bootloader in what you want done, you want it built for an image, but not installed, so you can grep oe-core and other layers for virtual/bootloader, for example, and see how machines pull it in. thats what i did to remind myself of the exact name of EXTRA_IMAGEDEPENDS variable :) Jan 17 15:56:00 <__deetz__> thanks for the pointers. Jan 17 15:56:03 np Jan 17 15:56:45 <__deetz__> ok, the problem now is Jan 17 15:56:49 <__deetz__> that the dtbo is there Jan 17 15:56:52 <__deetz__> all great Jan 17 15:56:57 <__deetz__> but the actual kernel module is missing ;) Jan 17 15:57:15 <__deetz__> I guess that was roped in by the MACHINE_ESSENTIAL_EXTRA_RDEPENDS Jan 17 15:57:40 <__deetz__> Wolud a way to solve this to somehow split my recipe in two? Jan 17 15:58:08 <__deetz__> I would prefer it to be one package obviously, but if I have to treat the dtbo different from the module, that's ok. Jan 17 15:58:37 two recipes or two packages within the existing recipe would be ideal Jan 17 16:01:05 <__deetz__> ok, I'll look for examples for that. thanks again. Jan 17 16:25:40 https://www.plasma-mobile.org/ Jan 17 16:25:46 has anyone looked at that? Jan 17 16:27:38 you did Jan 17 16:31:14 hah Jan 17 16:31:17 I mean someone smart Jan 17 16:47:33 Crofton|work: the Librem 5 folks have: https://puri.sm/posts/librem5-progress-report-9/ Jan 17 16:48:58 but they might be focussing on Gnome Shell. Jan 17 17:24:19 Crofton|work: plasma mobile is pretty neat Jan 17 17:24:35 vmeson: purism folks have adopted it but as a step son Jan 17 17:24:55 primary platform is still gnome for them Jan 17 17:25:08 I dont now why people are so attached to gnome Jan 17 17:25:57 we need better gui demos :) Jan 17 17:35:03 I coworker was asking what it would take to replace sato. I expect that plasma would be acceptable in functionality but it's likely rather bloated Jan 17 19:12:37 vmeson: lxqt would be another choice Jan 17 19:12:50 but plasma mobile definitely a good option Jan 17 19:13:39 its a big downside that we dont have a widely deployed DM in OE-core Jan 17 19:13:51 even XFCE would have been better now a days than sato Jan 17 19:16:05 Crofton|work: at one point of time I hade KDE working it was KDE4 Jan 17 19:17:08 SBCs have grown in significant numbers and they definitely look for lighter desktops but kind of fully featured Jan 17 19:17:22 so XFCE, lxqt, mate fills in nicely Jan 17 19:17:51 but, I think desktop distros have taken over that space already in SBC world Jan 17 19:18:08 so we very well might not to some half hearted effort Jan 17 19:21:23 some of the KDE folks are active in maintaining a layer for their software Jan 17 19:21:31 haven't tried it myself though Jan 17 19:57:49 FWIW: https://www.slant.co/versus/1135/1122/~lxqt_vs_xfce -- also has comparisons for other DEs like Plasma, GNOME[3], ... and something called Pantheon. **** ENDING LOGGING AT Fri Jan 18 02:59:57 2019