steelswords94361 has quit [Quit: Ping timeout (120 seconds)]
steelswords94361 has joined #yocto
vthor has quit [Quit: kill -9 $pid]
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.6.2]
vthor has quit [Quit: kill -9 $pid]
<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?
<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
<LetoThe2nd>
usvi: use two distributions. its that simple.
ablu has quit [Ping timeout: 272 seconds]
ablu has joined #yocto
Daanct12 has joined #yocto
sakman has quit [Quit: Leaving]
<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"
<usvi>
I guess the question becomes: how do I make a recipe which adds a user with ssh key, password and sudo capabilities?
<usvi>
that would be most convenient. to produce ipk which adds user
<usvi>
is that even possible?
Daanct12 has quit [Quit: WeeChat 4.6.2]
Chaser has joined #yocto
<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
<usvi>
khem rber|res : thank you. I will consider everything you said
zeemate has joined #yocto
mckoan|away is now known as mckoan
<mischief>
we use two different images for production and debug, fwiw.
_whitelogger has joined #yocto
ptsneves has joined #yocto
florian_kc has joined #yocto
yannd has quit [Remote host closed the connection]
khem has quit [Quit: WeeChat 4.6.2]
khem has joined #yocto
eduter has joined #yocto
<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
eduter58 has joined #yocto
eduter has quit [Ping timeout: 240 seconds]
ptsneves has quit [Quit: ptsneves]
ptsneves has joined #yocto
eduter58 has quit [Ping timeout: 240 seconds]
MarcWeDLM has joined #yocto
berton has joined #yocto
ptsneves has quit [Read error: Connection reset by peer]
florian_kc has quit [Ping timeout: 248 seconds]
enok has joined #yocto
enok has quit [Quit: enok]
enok has joined #yocto
enok has quit [Read error: Connection reset by peer]
enok has joined #yocto
enok has quit [Client Quit]
enok has joined #yocto
enok has quit [Client Quit]
enok has joined #yocto
enok has quit [Read error: Connection reset by peer]
<RP>
philipl_: sorry about the delay on those, this is my fault
<RP>
philipl_: there was something I wanted to check and I've not got around to it yet
<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)
<RP>
philipl_: I've merged them, thanks and sorry for the delays
<qschulz>
is there a way to execute a python BitBake function from a shell task?
<qschulz>
(a custom python function in a recipe I mean :)
<qschulz>
I know that for the opposite you can do bb.build.exec_func()
<rburton>
no
<rburton>
you're in a shell script
<rburton>
you can do ${@...} to run python at evaluation time, before the shell is called
<qschulz>
yup, but thats' not what i'm after sadly :)
<RP>
qschulz: the challenge would be how to gain all the python environment info like the datastore from within a shell
<qschulz>
but thanks, i'll figure something out (like making the shell task a python task instead :) )
<rburton>
qschulz: how would it work? shell functions are literally written to disk and executed with bash.
<RP>
I guess tinfoil could connect back in to the server but that would be horribly complex and fragile
<rburton>
rewriting the function as python is likely the right thing
<rburton>
but yeah, a next-gen tinfoil that would let you connect back to the running cooker and get/set variables would be useful
<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
<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
<qschulz>
(yes, I know about bmaptool but we need something that works on all platforms easily, with GUI and balena etcher seems pretty popular)
<rburton>
balena can't do bmap anymore? that's sad.
<RP>
mcfrisk: is there one of our own repos we could use?
<mcfrisk>
any repo and recipe will do, in the best case a local git repo which is on build machine
<RP>
mcfrisk: we generally work on the idea that if git.yoctoproject.org breaks, everything breaks
<mcfrisk>
pseudo as sample recipe?
rob_w has quit [Remote host closed the connection]
Guest18 has joined #yocto
rcw has joined #yocto
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
alessio has joined #yocto
arisut has quit [Quit: install gentoo]
arisut has joined #yocto
arisut has quit [Remote host closed the connection]
arisut has joined #yocto
Guest18 is now known as MarcWeDLM
MarcWeDLM has quit [Changing host]
MarcWeDLM has joined #yocto
<RP>
mcfrisk: yes, that would be fine
xmn has joined #yocto
rcw has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
goliath has joined #yocto
Vonter has joined #yocto
cyxae has joined #yocto
Xagen has joined #yocto
<patersonc>
Hi Folks. I'm just migrating a BSP layer to Walnascar. All building okay but I'm seeing new failures (since Scarthgap) with the yocto-check-layer script. test_machine_signatures fails complaining about "The machines have conflicting signatures for some shared tasks".
<patersonc>
Looking at the log I've seen a couple of errors from this e.g. "Variable MACHINE value changed from 'hihope-rzg2h' to 'hihope-rzg2m'" and "Variable TUNE_CCARGS value changed: [--mcpu=cortex-a57.cortex-a53+crc-] {+-mcpu=cortex-a57+crc+} -mbranch-protection=standard".
<patersonc>
To me, both of these "should" be different? As the machines are different and use different tuning as the CPUs are different?