goliath has quit [Read error: Connection reset by peer]
goliath has joined #yocto
bhstalel has quit [Quit: Client closed]
Omax has quit [Ping timeout: 252 seconds]
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
GNUmoon has quit [*.net *.split]
mckoan is now known as mckoan|away
olani- has joined #yocto
<KanjiMonster>
is there a way to prevent the removal of the run-postinsts package in the image build step?
<rburton>
KanjiMonster: why would you need that if there are no postinsts to run?
<rburton>
(it is removed if there are no postinsts)
<KanjiMonster>
rburton: when we upgrade an image, we try to take over any conffiles + users/groups/etc, but replace everything else. So uids/guids may not match anymore, and any postinsts that chown files need to run at runtime, not at image creation time (or run again)
<KanjiMonster>
(we already have a custom run-preints service to make sure that any missing users are created on first boot)
<rburton>
you can probably add an option to _uninstall_unneeded in rootfs.py
<KanjiMonster>
would be less of an issue if yocto had static uids/guids for service users/groups, but currently it doesn't ;)
<rburton>
you can add them
<rburton>
useradd-staticids iirc
<KanjiMonster>
hm "when the OpenEmbedded build system adds a user to the system during package installation", doesn't sound like it would work if the user needs to be added during first boot, unless this also modifies the generated preinst script
<KanjiMonster>
olani-: my current question is if you add a package to the running system, will it still get the static uid/gid defined in files/passwd etc?
<KanjiMonster>
or would I need to .bbappend all recipes that add users for that
<Saur>
KanjiMonster: Yes. The static IDs are encoded into the preinst-function that creates the users for the package.
<KanjiMonster>
that's good to know, that should solve my issue
<Saur>
But using `useradd-staticids` is essential if you want to support updating your firmware and support non-root owned files that are created in runtime.
<KanjiMonster>
I come from an OpenWrt background, I'm used to (system) users having static ids by default ;)
<KanjiMonster>
anyway, thanks everyone for the pointers :)
ehussain has quit [Remote host closed the connection]
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #yocto
lquirion has joined #yocto
lucile has quit [Ping timeout: 252 seconds]
Minvera has quit [Read error: Connection reset by peer]
Minvera2 has joined #yocto
Minvera2 has quit [Read error: Connection reset by peer]
geoff_ has quit [Remote host closed the connection]
geoff_ has joined #yocto
<KanjiMonster>
unfortunately it seems systemd does not care for useradd-staticids, the wheel group does not match what I put into files/group
albeu has joined #yocto
Omax has joined #yocto
<KanjiMonster>
or whereever the wheel group comes from ...
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
Silcet_ has joined #yocto
Silcet_ is now known as Silcet
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
rob_w has quit [Remote host closed the connection]
<KanjiMonster>
so yeah, systemd does not use useradd but uses useradd and its own facilities. it does support static allocation, but requires this to be done as meson build args (to populate /usr/lib/sysusers.d/basic.conf)
rstreif has joined #yocto
lquirion has quit [Quit: Leaving]
<fray>
KanjiMonster: if systemd has it's own magic list of users then that is probably a bug if it's not synced up "somehow". I guess the question comes down to, do we try to detect this issue and warn/error for the user or is there a way we can update the configuration to match the static users (preferred approach).
<fray>
this is unix, having your own user list is insane.. IMHO
<KanjiMonster>
¯\_(ツ)_/¯
<KanjiMonster>
I mean this is systemd we are talking about, the NIH is very strong there
<fray>
I can see a list of "I want this capability, use this gid/uid" but anything more specific is "problematic", as you've found..
<fray>
Integration bugs in these things need to be reported is the best I can tell you.. but we should try to warn the user of this type of thing, if not fix it.. (we = the community in general)
albeu has joined #yocto
<KanjiMonster>
ah, selfregistration is disabled for bugzilla. so reporting will need to wait a bit
<sakoman>
rfs613: sorry, I can't do that. It probably would make sense to create your own dunfell fork and the gcc13 patches there. I suspect you will find that you need more than just this one!
<rfs613>
sakoman: yes already done it in a local meta-backports layer. And surprisingly that is the only one that I needed to get it building.
leon-anavi has quit [Remote host closed the connection]
<sakoman>
rfs613: I meant that there are probably other packages that will also need gcc13 patches :-)
<rfs613>
sakoman: indeedd there might be, but in my particular build, apt-native is the only one that failed to compile. I was kind of surprised...
<sakoman>
rfs613: you are lucky!
florian has quit [Quit: Ex-Chat]
leon-anavi has joined #yocto
rfuentess has quit [Remote host closed the connection]
albeu has quit [Quit: albeu]
druppy has joined #yocto
druppy has quit [Client Quit]
druppy has joined #yocto
druppy has quit [Client Quit]
druppy has joined #yocto
<Ch^W>
RP: (moving to IRC) I had a similar thought - we could add more configurabilty to get us closer to the same result.
<vmeson>
Interesting: https://sourceware.org/bunsen/ a test result storage and analysis toolkit ... stores them in a ludicrously compact de-duplicated Git repo
<vmeson>
well, interesting if you like to store and compare tests at least! ;-)
hexbrex has quit [Read error: Connection reset by peer]
Guest56 has joined #yocto
Guest56 has quit [Client Quit]
Guest56 has joined #yocto
<RP>
vmeson: Someone else mentioned that recently too
<RP>
vmeson: I keep meaning to ask if you fancy fixing the build profile graphs? :)
* RP
has various fixes but nothing I'm 100% happy with :(