01:27 <mischief> can someone remind me (again), what's the procedure to request a backport?

01:27 <mischief> nothing big, but this doesn't exist in scarthgap https://github.com/yoctoproject/poky/commit/0dfd37f2408cbdb32de5553e30b96efee5798a3b

05:33 <usvi> good time of the day. we are using a single build for both production and debugging. we have a bbclass file to define some variables. It is included in multiple recipes. now, there is a need to, based on a variable in this bbclass, to include a debug user with a ssh key. how would you approach this?

05:33 <usvi> my workmate was tasked with this, but he is doing strange stuff like creating dynamically new bbappend files on the fly to achieve this. I have a feeling this is not the optimal way

05:34 <LetoThe2nd> usvi: use two distributions. its that simple.

05:44 <usvi> LetoThe2nd: I guess that is a thing. I was thinking if I could dynamically influence via bbclass variable if we are building "production" or "debug"

05:46 <usvi> I guess the question becomes: how do I make a recipe which adds a user with ssh key, password and sudo capabilities?

05:48 <usvi> that would be most convenient. to produce ipk which adds user

05:48 <usvi> is that even possible?

06:01 <khem> usvi: you can add users in image recipe and have separate image recipes if thats the only difference your production vs dev image needs

06:03 <usvi> khem: that is the only difference

06:03 <khem> see - https://github.com/YoeDistro/yoe-distro/blob/3c51f065d9695d5452b84641e8f45020ff7f6760/sources/meta-yoe/recipes-core/images/yoe-simple-image.bb#L42

06:04 <usvi> oh it can go to .bb

06:04 <khem> define two images which technically include same .inc file and one has these users other does not

06:04 <khem> yes it can

06:05 <usvi> I need to manipulate sudoers file also. any tips for that?

06:05 <usvi> one option is of course to just leave the debug user in sudoers file no matter what

06:05 <usvi> oh and I need the ssh key conditionally also

06:06 <usvi> brb

06:20 <rber|res> @usvi: You might introduce "image modes" and like that you can avoid building different distros. e.g. https://gitlab.com/meta-layers/meta-resy-secure-distro/-/blob/master/classes/image-mode.bbclass?ref_type=heads

06:29 <usvi> khem rber|res : thank you. I will consider everything you said

06:41 <mischief> we use two different images for production and debug, fwiw.

07:22 <philipl_> quick question as i'm not familiar with the project's merge process: when do things get merged from bitbake's master-next to master (i'm particularly interested about my current pending changes https://git.openembedded.org/bitbake/commit/?h=master-next&id=2a8722ddd155596862029f6ea34e1e92c77e0b7f). i'd like to use this series as a base for the discussed follow up change to assume lfs=0 by default

08:45 <qschulz> congrats all on the Walnascar release 🎉

09:17 <rburton> 🍻

09:43 <AdrianF> Will there also be a Co located Yocto Summit at https://events.linuxfoundation.org/open-source-summit-europe/features/co-located-events/ ?

09:45 <rburton> AdrianF: yes

09:49 <AdrianF> rburton: Thanks, I assume one day Thursday, 28 August

09:49 <rburton> i believe thats right. LetoThe2nd? ^^^

10:00 <LetoThe2nd> There will be a YP thing at Amsterdam, yeah. I can try to dig up the date.

10:22 <RP> philipl_: sorry about the delay on those, this is my fault

10:23 <RP> philipl_: there was something I wanted to check and I've not got around to it yet

10:31 <philipl_> RP: alright thanks - just wanted to make sure it isn't stuck because of some misunderstand (as i promised to also send out the lfs=0 patches)

10:37 <RP> philipl_: I've merged them, thanks and sorry for the delays

10:39 <qschulz> is there a way to execute a python BitBake function from a shell task?

10:39 <qschulz> (a custom python function in a recipe I mean :)

10:40 <qschulz> I know that for the opposite you can do bb.build.exec_func()

10:40 <rburton> no

10:40 <rburton> you're in a shell script

10:40 <rburton> you can do ${@...} to run python at evaluation time, before the shell is called

10:41 <qschulz> yup, but thats' not what i'm after sadly :)

10:41 <RP> qschulz: the challenge would be how to gain all the python environment info like the datastore from within a shell

10:41 <qschulz> but thanks, i'll figure something out (like making the shell task a python task instead :) )

10:41 <rburton> qschulz: how would it work? shell functions are literally written to disk and executed with bash.

10:42 <RP> I guess tinfoil could connect back in to the server but that would be horribly complex and fragile

10:42 <rburton> rewriting the function as python is likely the right thing

10:42 <rburton> but yeah, a next-gen tinfoil that would let you connect back to the running cooker and get/set variables would be useful

10:58 <qschulz> meh, cannot migrate an IMAGE_CMD function to a python task I guess, seems like it needs to be shell since do_image_<> content is generated by the anonymous python function in image.bbclass

10:59 <qschulz> all this to parse a bmap xml file to figure out where the last data block is in a sparse file because balena etcher has lost support for flashing bmap files and I cannot possibly wait to flash 16GB when only ~40MiB needs to be flashed

10:59 <qschulz> (yes, I know about bmaptool but we need something that works on all platforms easily, with GUI and balena etcher seems pretty popular)

11:00 <rburton> balena can't do bmap anymore? that's sad.

11:00 <qschulz> it can, but it fails

11:00 <qschulz> https://github.com/balena-io/etcher/issues/4079