ablu has quit [Read error: Connection reset by peer]
ablu has joined #yocto
khem has quit []
khem has joined #yocto
mattsm has quit [Ping timeout: 268 seconds]
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
Chocky has quit [Ping timeout: 245 seconds]
Chocky has joined #yocto
|Xagen has joined #yocto
Xagen has quit [Ping timeout: 256 seconds]
Vonter has quit [Ping timeout: 260 seconds]
alessioigor has joined #yocto
Vonter has joined #yocto
alperak has joined #yocto
agners has quit [Remote host closed the connection]
linfax has joined #yocto
sakman has joined #yocto
MarioMariollini has joined #yocto
leon-anavi has joined #yocto
prabhakarlad has joined #yocto
<MarioMariollini>
RP: I got it to work now. It was my own mistake obviously. Had SDKPATH depending on DEFAULT_TUNE in my distro conf
kpo_ has joined #yocto
<RP>
MarioMariollini: ah, nice. I wonder if there is some sanity check we should add to warn about that...
kpo_ has quit [Ping timeout: 252 seconds]
<MarioMariollini>
RP: I will take a look at that this afternoon, could be useful
mvlad has joined #yocto
brrm has quit [Ping timeout: 268 seconds]
JerryM has joined #yocto
prabhakarlad has quit [Ping timeout: 250 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<ablu>
Xogium: Having A/B updates + immutable filesystem but a method to allow read-write mounting can certainly speed up development. Whether you want to do that as a separate development image (which may increase maintenance effort) or just keep the toggle disabled in production probably depends on your needs. AOSP allows something with their engineering builds.
<alperak>
let's say there is a recipe with foo name and foo is DEPENDS in another recipe. how can I get this info?
neofutur has joined #yocto
<landgraf>
alperak: bitbake -g
<alperak>
landgraf thanks :)
jmd has joined #yocto
mbulut has joined #yocto
mbulut has quit [Client Quit]
khem has quit [Quit: Connection closed for inactivity]
<JerryM>
RP: you made some changes to runqueue which are needed for the useradd dependencies, would this be appropriate to backport to kirkstone or is that likely to cause issues?
prabhakarlad has quit [Quit: Client closed]
<RP>
JerryM: very invasive and no really appropriate sadly
prabhakarlad has joined #yocto
<RP>
JerryM: the useradd issues are not yet all fixed either so it probably wouldn't fix everything
Nonkel has joined #yocto
<Nonkel>
Hello
<Nonkel>
How can I find witch device tree is used for my embedded device?
pabigot has quit [Ping timeout: 245 seconds]
Guest18 has joined #yocto
<mckoan>
Nonkel: see KERNEL_DEVICETREE in your machine file. However it depends on the u-boot environment settings though
<Nonkel>
this variable doesn’t exist in my local.conf.
starblue has quit [Ping timeout: 252 seconds]
<mckoan>
Nonkel: machine file is in the layer providing your BSP. What's your MACHINE value in local.conf?
<Guest18>
i am building Yocto image for stm32mp1 board with IMAGE_INSTALL += " packagegroup-core-ssh-openssh openssh-sftp-server " included in local.conf and able to build without any issue.
<Guest18>
After boot up when i am trying to launch sshd service i am getting error as :
<Guest18>
root@mp1som:~# systemctl start sshd
<Guest18>
Job for sshd.service failed because the control process exited with error code.
<Guest18>
See "systemctl status sshd.service" and "journalctl -xe" for details.
<Guest18>
Jan 05 16:22:27 mp1som systemd[1]: Starting sshd.service...
<Guest18>
Jan 05 16:22:27 mp1som sshd[8728]: /etc/init.d/sshd: /etc/init.d/functions: line 134: syntax error: unexpected "(" (expecting "done")
<Guest18>
Jan 05 16:22:27 mp1som systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39msshd.service: Control process exited, code=exited, status=2/INVALIDARGUMENT[[0m
<Guest18>
Jan 05 16:22:27 mp1som systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39msshd.service: Failed with result 'exit-code'.[[0m
<Guest18>
Jan 05 16:22:27 mp1som systemd[1]: [[0;1;31m[[0;1;39m[[0;1;31mFailed to start sshd.service.[[0m
<Guest18>
I have not modified any of the files related to anything. Can someone give me some pointer ?
<mckoan>
Guest18: please use pastebin for command output or long messages
<Guest18>
sure
<mckoan>
Guest18: /etc/init.d/sshd: /etc/init.d/functions: line 134: syntax error: unexpected
<kanavin>
JerryM, you should rather plan for upgrading to upcoming LTS release
<kanavin>
and set up rolling master builds in your organization
<MarioMariollini>
RP: do you think a simple ' if "${DEFAULTTUNE}" in data.getVar("SDKPATH", False) ' would do for the sanity check, or should it be something that checks whether SDKPATH changes depending on the multilib
MarioMariollini has quit [Quit: Client closed]
MarioMariollini has joined #yocto
paulg has joined #yocto
<RP>
MarioMariollini: I was thinking more along the lines of the latter, it needs to be generic
MarioMariollini has quit [Quit: Client closed]
markov_twain has joined #yocto
jmd` has joined #yocto
jmd has quit [Remote host closed the connection]
Guest18 has joined #yocto
<JerryM>
kanavin: I am planning just that, but that is no solution for my current rebuilds unfortunately
<kanavin>
JerryM, one option is doing the backport yourself and maintaining a private branch. It's a slippery slope though.
<Xogium>
ablu: thanks for explaining this. I do admit I have a hard time imagining an image where one can toggle thedevelopment system on and off given I plan to use erofs for the rauc upgradable system
<kanavin>
JerryM, in my previous product organization there was a strict policy of not forking layers or poky, or any of the open source components (custom recipe patches to them were ok)
<ablu>
Xogium: One could overlay it with some writable partition (potentially from a different disk). But yeah, erofs or dm-verity make it a bit more complex.
<Xogium>
yeah and most of the boards are short on storage
<Xogium>
they come with a 4 gbyte eMMC and that ends up cut in half since wenhanced user area gets enabled, along with write reliability
<Xogium>
*enhanced
camus has quit [Quit: camus]
<JerryM>
kanavin: I would do the backport if it was upstreamable, or potentially in a mixin, however if the changes are 'very invasive and not appropriate' I'd rather wait a few months and spend my effort elsewhere
<JerryM>
kanavin: we don't fork any layer/component either and I'd rather keep it that way too :)
mckoan|away is now known as mckoan
<mckoan>
Nonkel: you have to modify the dts creating a .bbappend for the u-boot recipe
<mckoan>
Nonkel: the best practice in this case would be to create a new machine, mut is more complex
<mckoan>
Guest18: you should figure out whether you are using a custom layer providing that
<Nonkel>
mckoan: do you have any example how to create a .bbappend flle?
neofutur has quit [Ping timeout: 260 seconds]
neofutur has joined #yocto
MarioMariollini has joined #yocto
<JerryM>
I just noticed the IRC logs on http://irc.yoctoproject.org/irc/ have not been updated for this year, in case that is not as intended
<rburton>
halstead: irc logs failed to rollover to 2024
<MarioMariollini>
is there a function in the bb module to expand a variable, when possible using a certain suffix? like for example try to expand:
<MarioMariollini>
"/opt/sdk/${DEFAULTTUNE}/${VERSIONTAG}" but checking if each of the variables is defined for virtclass-multilib-lib32
<MarioMariollini>
So it would first try DEFAULTTUNE:virtclass-multilib-lib32, if None, then just give DEFAULTTUNE
<MarioMariollini>
Same for VERSIONTAG
<MarioMariollini>
I have read data and data_smart code but didn't find this
<yocton>
MarioMariollini: isn't that "just" getVar() from data_smart ?
<MarioMariollini>
yocton: but that does not take a second parameter for the suffix, does it? I would like to do it from outside the context of the virtclass-multilib-lib32 in this case
<yocton>
sorry, I don't understand "suffix" in this context :/
<yocton>
Do you mean an override? like "virtclass-multilib-lib32" in "DEFAULTTUNE:virtclass-multilib-lib32" ?
<MarioMariollini>
Yes, meant an override sorry
<MarioMariollini>
so, to apply overrides while expanding if they exist
<MarioMariollini>
but the override is a parameter to the function
<yocton>
ok, d.getVar(X) will give you the value of X respecting the overrides present in d
<RP>
MarioMariollini: the standard way of doing that is to create a copy of the data store, set OVERRIDES as needed, then run getVar()
<halstead>
rburton: ahh, it's not automatic at all. I'll fix that
yocti has quit [Remote host closed the connection]
khem has joined #yocto
goliath has joined #yocto
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
zkrx has quit []
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zkrx has joined #yocto
florian has joined #yocto
<rburton>
kanavin: fyi i have a partial glib 2.79 upgrade locally. the g-i changes are going to be "interesting".
alperak has quit [Quit: Client closed]
alperak has joined #yocto
<kanavin>
rburton, 2.79 is a development thingy?
<rburton>
yes
<kanavin>
2.80 is the release
<rburton>
correct
<rburton>
we need to scream now if the G-I rework is just too much pain
<kanavin>
ah that favorite word of the brits :)
<kanavin>
'interesting'
<rburton>
packages/cortexa57-poky-linux/glib-2.0/glib-2.0-doc: PKGSIZE changed from 23717520 to 0 (-100%)
<rburton>
i wonder if it refuses to build docs in cross
<kanavin>
rburton, I've just finished dealing with all the things that python removed in 3.12, so don't super fancy taking on another lets-break-stuff-for-fun upgrade
<rburton>
lol
<rburton>
i hear 3.13 removes more ;)
<kanavin>
yeah, it's python 4 split into edible chunks
<kanavin>
once all the fixes land in meta-oe and meta I'll send in the actual update
dgriego_ is now known as dgriego
alperak has quit [Quit: Client closed]
alperak has joined #yocto
prabhakarlad has quit [Ping timeout: 250 seconds]
goliath has quit [Quit: SIGSEGV]
florian has quit [Ping timeout: 256 seconds]
goliath has joined #yocto
zwelch has quit [Quit: Leaving]
zwelch has joined #yocto
<dvergatal>
khem: around?
<khem>
dvergatal: now yes
jmd` has quit [Remote host closed the connection]
alimon has quit [Ping timeout: 264 seconds]
goliath has quit [Quit: SIGSEGV]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alimon has joined #yocto
vladest has quit [Quit: vladest]
prabhakarlad has joined #yocto
alperak has quit [Quit: Client closed]
yudjinn has joined #yocto
vladest has joined #yocto
mrnuke has quit [Ping timeout: 260 seconds]
mrnuke has joined #yocto
goliath has joined #yocto
prabhakarlad has quit [Quit: Client closed]
Average_Joe has joined #yocto
<dvergatal>
khem: I have written to you are you there?
florian has joined #yocto
mvlad has quit [Remote host closed the connection]
Average_Joe has quit [Quit: Leaving]
florian has quit [Ping timeout: 256 seconds]
<RP>
rburton: hmm, probably not easily
<RP>
yocton: you generally want access to the data store copy so it wouldn't be as useful as you think
<cambrian_invader>
I moved my yocto build directory from one filesystem to another (restored from backup) and now pseudo complains that the inodes don't match
<cambrian_invader>
what's the right command to invalidate things?
<RP>
cambrian_invader: fresh TMPDIR probably
<cambrian_invader>
ok, I'll try that
<cambrian_invader>
well, no errors and I didn't have to rebuild the world thanks to sstat :)
Nonkel has quit [Ping timeout: 250 seconds]
alessioigor has quit [Ping timeout: 256 seconds]
florian has joined #yocto
nerdboy has quit [Ping timeout: 245 seconds]
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
<dvergatal>
khem: I have narrowed the issue and the result is written on bugzilla
<RP>
dvergatal: I replied, it is a change in behaviour and a regression from our perspective unfortunately as for us the names are the primary id
<dvergatal>
RP: i see but unfortunately this is an issue in regards of acls
<dvergatal>
you won't be able to extract files with set acls
<RP>
dvergatal: well, we can't just break everything :(
<dvergatal>
RP: and because of how acls are working it is not possible to store them diffrently in tar files otherwhise during extraction there will be a failure
<RP>
dvergatal: why do they have to be numeric?
<dvergatal>
RP: because if they will not be during extraction an error will occur like this tar: file: Warning: Cannot acl_from_text: Invalid argument
<RP>
dvergatal: you mean if they don't exist at extraction time?
<dvergatal>
RP: acls implementation is reading /etc/passwd and /etc/groups for extraction
<RP>
dvergatal: absolutely. Which is why we have preinst scripts setting up the users
<dvergatal>
RP: precisely
<RP>
dvergatal: since the preinst script sets up the user/groups they are available at extraction time?
<dvergatal>
RP: yes but they will be wrong because of fake rootfs for the package
<RP>
dvergatal: why will they be wrong?
<RP>
we go to great lengths to make them right
<dvergatal>
RP: in package e.g. of cpio-ptest it is random value for it and in rootfs it is completly different UID/GID
<RP>
the name is not random, the number is
<dvergatal>
RP: yeah the random is
<RP>
and the number will map to a value from the passwd/group file in the sysroot which psuedo is using for any lookups
<dvergatal>
RP: yes but you still need the name in /etc/passwd
<dvergatal>
RP: with correct number
<RP>
no, you need it in the sysroot passwd/group, pseudo handles it
<dvergatal>
RP: ahhhh ok
<dvergatal>
RP: so every ipk package will have the proper /etc/passwd and /etc/groups or what?
xmn has quit [Read error: Connection reset by peer]
<RP>
there is a passwd/group in the sysroot which is used for package creation
<dvergatal>
yes there is
<RP>
at rootfs time, there is either the real files on the target or the files within the image itself as it is being built
<RP>
it is possible we don't correctly handle some acl bits in pseudo, in which case we need to fix pseudo but using numeric ids will not work
<RP>
I need to head afk
<dvergatal>
generaly if i will want to extract image i'm unable to exract it because I don't have this stupid files /etc/passwd and /etc/groups
<dvergatal>
and this concerns the whole rootfs creation
<dvergatal>
for the image
<RP>
dvergatal: my patience with this is wearing a bit thin
<dvergatal>
RP: i can imagine
<dvergatal>
RP: but this was not my idea of acls implementation
<RP>
dvergatal: our rootfs construction work (or did). People use our images with users/groups all the time, it all works (or did). Extracting rootfs images outside of our environment isn't trivial and isn't a good measure of whether something is right
<dvergatal>
meaning how acls are working
<RP>
dvergatal: well, what is your idea?
<dvergatal>
dvergatal: I mean the whole acls idea how it works
<RP>
not much we can do about that
<RP>
Now the acl changes are actively breaking things I'm close to saying we should just not support them :(
<dvergatal>
RP: hmmm i would rather rethink the other solution on how to extract it without breaking things
florian has quit [Ping timeout: 264 seconds]
<dvergatal>
but i'm tired with it with and need to need to rest...
<RP>
dvergatal: lets leave this for some other time. Meanwhile we do need to remove that --numeric-owner option.
<dvergatal>
RP: I agree with you
<dvergatal>
RP: I can generally discuss it with Alex and change the commit to have this numeric-owner just in case of acls and/or xattrs parameters set
<dvergatal>
RP: but he has already pushed a release so i need to talk with him
<dvergatal>
ok cya I'm going to play some stupid games....:P