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?
<patersonc>
Am I understanding wrong here?
MarcWeDLM has quit [Quit: Client closed]
Daanct12 has quit [Quit: WeeChat 4.6.2]
sgw has quit [Quit: Leaving.]
sgw has joined #yocto
sgw has quit [Ping timeout: 276 seconds]
sgw has joined #yocto
sgw has quit [Remote host closed the connection]
<AdrianF>
qschulz: Maybe not what you are looking for, but anyway. We also used bmap in the past for the initial flashing. Now we use the firmware updater which we anyway have to the initial flashing as well.
<qschulz>
AdrianF: so I have a very peculiar setup that's been required
<qschulz>
I hate it but it's pretty user friendly :)
<qschulz>
have yet to have someone to use it
<qschulz>
anyway, the point is, you prepare a USB stick/SD card and make the bootloader boot from it
<qschulz>
the user is supposed to copy their image to flash on the eMMC on a partition on that USB stick/SD card
<qschulz>
so it needs to be "big" to be able to contain that file which can be multiple GiB big
<qschulz>
arbitrarily 16GB for now, to fit "most" USB sticks and SD cards
<qschulz>
but out of those 16GB on the SD card, I have like only ~70MB that are somewhat useful (actually less because I have a 32MiB offset for the start of the partition where to copy the image to flash)
<qschulz>
so we are not talking about flashing the eMMC for the bmap file here, but flashing the USB stick that is used to boot stuff from. Hopefully rarely flashed but waiting tens of minutes is already too long to my taste :)
<qschulz>
I'm essentially waiting for U-Boot 2025.07 to be out, so I can port all our products to it and enable exFAT support (another sin for that user-friendliness :) )
<qschulz>
and then I'll push the support for this non-sense publicly in our yocto layer
rcw has joined #yocto
florian__ has quit [Ping timeout: 265 seconds]
<AdrianF>
qschulz: The point is: creating the partitions on the target device rather than on the build host. That brings you to the situation that you create an empty 16GB partition only on your target device and deal with 70MB for all other steps in your build, archiving and manufacturing steps.
<AdrianF>
If you have the same tool and archive format for your incremental update system as for the initial manufacturing it gets even better. When you come from images and bmap (what I do as well), it means re-thinking everything.
<khem>
qschulz: yoe updater+installer does something like that, it builds a small installer image which bundles the full image bundle, it boots and installer takes care of partitioning the on-device media ( MMC/SD ) and installing this image
mckoan is now known as mckoan|away
jmiehe has joined #yocto
<khem>
patersonc: are you using --machine argument to yocto-check-layer
<patersonc>
khem: Not directly, but TUNE_CCARGS will change depending on the tune-cortec*.inc included in the machine conf file
<khem>
right thats expected though
<patersonc>
That's what I thought
Xagen has joined #yocto
<khem>
is there any dependent layer for your BSP besides core ?
<patersonc>
meta-arm/meta-arm and meta-arm/meta-arm-toolchain
* rburton
hides
<patersonc>
:P
<patersonc>
Note I haven't been checking the dependencies... Let me try now
<rburton>
patersonc: check that your checklayer command works with eg qemuarm and meta-arm's fvp-base or something. and mail us if you find a bug in meta-arm :)
<patersonc>
rburton: Will do
denix has joined #yocto
zeemate has quit [Ping timeout: 260 seconds]
<qschulz>
AdrianF: I cannot create the partitions on the target, that's the whole issue. The USB stick is the source of truth and is provided by the user with everything needed to 1) boot 2) flash on the eMMC
<qschulz>
AdrianF: we use swupdate to flash this too, but admittedly very off the beaten path
<qschulz>
AdrianF: essentially, the whole point is: you get a module from us, you get only a bootloader flashed on it
<qschulz>
then on your manufacturing floor you connect a USB stick which has everything needed
<qschulz>
we give you the ISO/wic image to flash on the USB stick (16GB but actually ~40MB of content), you mount the USB stick and add two files 1) the image to flash at offset 0 on the eMMC, 2) the sha256sum of the image
<qschulz>
optionally scripts to run after swupdate has finished flashing and verifying the eMMC
<qschulz>
khem: I don't care about the partitioning of the target :)
<qschulz>
if it all sounds crazy to both of you, you're probably not far from what i'm attempting to do :)
berton has quit [Quit: Connection closed for inactivity]
<khem>
qschulz: systemd repart perhaps can help but creating a full size disk image which is then dd'ed to target disk is slow especially on these embedded devices
florian__ has joined #yocto
<khem>
I always try to build solutions where systemd is not a hard dependency but that has disadvantages too where I can not rely on come good systemd features
druppy has joined #yocto
leon-anavi has quit [Quit: Leaving]
rcw has joined #yocto
florian__ has quit [Ping timeout: 248 seconds]
dvergatal has quit [Quit: leaving]
florian__ has joined #yocto
florian__ has quit [Ping timeout: 265 seconds]
druppy has quit [Ping timeout: 272 seconds]
florian__ has joined #yocto
zeemate has joined #yocto
dgriego has joined #yocto
ello has quit [Read error: Connection reset by peer]
ello_ has quit [Read error: Connection reset by peer]
ello has joined #yocto
ello_ has joined #yocto
cyxae has quit [Quit: cyxae]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ptsneves has quit [Ping timeout: 276 seconds]
rcw has quit [Ping timeout: 240 seconds]
ello_ has quit [Read error: Connection reset by peer]
ello has quit [Read error: Connection reset by peer]
ello has joined #yocto
ello_ has joined #yocto
druppy has joined #yocto
druppy has quit [Ping timeout: 244 seconds]
<patersonc>
rburton: I haven't seen any checklayer issues with meta-arm yet :)
<patersonc>
Interestingly though I still get issues with my layer, even if I delete all files apart from the layer.conf and a qemu machine conf copied from poky! So I can't see how it's code in my layer causing the issue?
<patersonc>
If I delete three recipes from meta-oe (kernel-hardening-checker, spectre-meltdown-checker, smarty) the layercheck starts passing
* patersonc
shrugs
<patersonc>
So, if I force the bsp checks on meta-oe (by adding some machine confs to it) I get the same issues I was seeing from my own layer...
dgriego has quit [Ping timeout: 276 seconds]
<khem>
meta-oe is not a bsp layer though
<khem>
we should still fix the issues if possible
<khem>
does your layer pass the checks if you remove meta-oe from layermix ?
dgriego has joined #yocto
* patersonc
kicks off test
<khem>
two of them kernel-hardening-checker and spectre-meltdown-checker recommend kernel-dev and that could be reason
<khem>
smarty seems a bit different so not sure whats going on there
<khem>
we do run layer-check on meta-oe CI on Autobuilder though
<patersonc>
layer-check on meta-oe without the BSP tests passes for me
<khem>
right
<khem>
so something is amiss here
<khem>
the AB run is without BSP layers
<patersonc>
khem: If I remove meta-oe from my dependencies then layer-check test_machine_signatures passes.
<khem>
OK, thats good, separately both layers pass their checks but combined they dont
<khem>
thats interesting
<patersonc>
Yea
<patersonc>
I'm happy to help debug further if you have any ideas of where to look. However bed is calling me now, so it'll have to be a tomorrow job :)
<khem>
Can you see this with just meta-arm too ?
<khem>
np gn
<patersonc>
I haven't seen it at all with meta-arm
<patersonc>
But meta-arm doesn't have meta-oe as a dependency
<patersonc>
I'm off for now. Thanks for your help khem