<RP>
landgraf: do you happen to know how to allow target-sdk-provides-dummy (which provides perl) to replace a dependency some recipe has on perl >= 5.36.0, I'm a bit unclear on how to make the version piece work
xmn has quit [Quit: ZZZzzz…]
<RP>
landgraf: it does seem to be an rpm specific issue
<RP>
landgraf: just wondered if you had any insight! :)
<phako[m]>
Failed to load the xcbgen Python package! - shouldn't that come from some native package?
leon-anavi has joined #yocto
<phako[m]>
ah. found a patch foir libxcb that I am possibly missing.
<landgraf>
RP: I don't know. Never touched sdk part but I can take a look :)
<landgraf>
RP: I'm on CC list of this bug looks like I'm interested in.
Dracos-Carazza has quit [Ping timeout: 260 seconds]
Dracos-Carazza has joined #yocto
jclsn has quit [Ping timeout: 265 seconds]
falk0n[m] has quit [Quit: You have been kicked for being idle]
kiwi_29_[m] has quit [Quit: You have been kicked for being idle]
<alexis-lothore>
changing name of called script from yocto-autobuilder-helper, and poky for minor documentation update regarding the first two). I searched on doc/wiki about how I am supposed to send those 3 linked patchset, mut maybe I missed the info : is it ok to send three separate patch mails, each one mentioning the previous ?
<RP>
landgraf: they don't need that, the code works as is iirc
<RP>
landgraf: it could be there is some absolute path present which breaks things, what I then don't understand is why removing the perl version constraint would make it work
florian_kc has joined #yocto
<landgraf>
RP: I'll take a look at this bug if you don't mind (well, I'm on it already :-) )
<RP>
landgraf: I don't mind at all! I got so far with it but I'm not sure where from here
dev1990 has joined #yocto
dev1990 has quit [Client Quit]
ptsneves has joined #yocto
<RP>
landgraf: just to be clearer about the above patch, rpm has internal magic for dependencies on specific files which simply isn't present for ipk/deb, they don't have that mechanism at all
<RP>
landgraf: we run rpmdeps and generate some extra info so our deb/ipk dependencies are more like rpms but not everything is the same
<landgraf>
RP: yes, it does most of this magic features are disabled in oe iirc
<RP>
landgraf: it is possible my debugging was flawed, I may have been debugging the wrong thing :(
<landgraf>
RP: I will take it then. As well as two other bugs Tim mentioned.
<RP>
landgraf: somewhere part way through testing I think rpm was switched for ipk packaging :(
<RP>
landgraf: thanks, I suspect the challenge here is going to be working out the best way to do this all the package managers agree on
<landgraf>
RP: np. I was going to look for interesting bugs to solve anyway.
<RP>
landgraf: I updated the comments just to show my earlier ones are flawed
jamesreid[m] has joined #yocto
rfuentess has quit [Remote host closed the connection]
goliath has joined #yocto
d-s-e has quit [Ping timeout: 260 seconds]
olani- has quit [Ping timeout: 256 seconds]
olani- has joined #yocto
florian has joined #yocto
<qschulz>
ptsneves: send it for review and see :)
<qschulz>
with proper commit log, explaining why this was needed :)
demirok has joined #yocto
wkawka has joined #yocto
<wkawka>
Hi
<wkawka>
Can I make an append uding bbappend file to change something in inc file?
<wkawka>
Can I make an append using bbappend file to change something in inc file?
<wkawka>
*
thomasd13 has quit [Ping timeout: 272 seconds]
<ptsneves>
wkawka: yes, there is no difference where the metadata came from
<wkawka>
so assuming I have files: recipe.inc, recipe_git.bb and recipe-native_git.bb how should I name a bbappend file to append to the inc dile?
<wkawka>
file*
<ptsneves>
you do not bbapend to the inc but to the recipe. So for your case you need 2 bbappends
<ptsneves>
if you want to bbappend for both target and native
<wkawka>
Oh so it is like that, thanks
<ptsneves>
maybe the other part of the idea is that you do not bbappend any .inc file, only bb* files
<rburton>
wkawka: ideally, you don't have a native recipe, just do the native specific pieces with overrdes in the main recipe
<wkawka>
Yes, i just needed to fix SRC_URI path which is common for them in .inc file
<rburton>
RP: that pkgconfig bug, i presume you mean buildtools-tarball-extended (as normal has no pkgconfig)
<RP>
rburton: yes
alexis-lothore42 has quit [Quit: Connection closed]
d-s-e has joined #yocto
<RP>
rburton: sorry, I did mean that
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<rburton>
just checking i didnt get the wrong end of the stick :)
d-s-e has quit [Client Quit]
manuel1985 has joined #yocto
Payam has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<rburton>
and again i wish that sh had a "list all available paths for a binary" so I can run the one that isn't first
JaMa has quit [Read error: Connection reset by peer]
JaMa has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<rburton>
RP: can i use a non-posix but dash/bash option in the sdk environment script? :)
<rburton>
"command -p" is 'find the binary using a hardcoded path, not $PATH'
<rburton>
so runs the host pkgconfig easily
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
AntA has quit [Read error: Connection reset by peer]
manuel1985 has quit [Ping timeout: 265 seconds]
ptsneves has quit [Read error: Connection reset by peer]
ptsneves has joined #yocto
gho has quit [Ping timeout: 248 seconds]
gho has joined #yocto
gho has quit [Client Quit]
gho has joined #yocto
<RP>
rburton: it makes me a little nervous given all the places it could end up used, not sure
manuel1985 has joined #yocto
<RP>
rburton: which -a pkg-config btw
<rburton>
yeah, but can't rely on that
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
florian_kc has quit [Quit: Ex-Chat]
manuel1985 has quit [Ping timeout: 252 seconds]
Minvera has joined #yocto
florian has quit [Ping timeout: 252 seconds]
olani- has quit [Ping timeout: 252 seconds]
sakoman has joined #yocto
vik has quit [Quit: Client closed]
<RP>
zeddii: you're tempting me to reply asking about spaces vs tabs
<zeddii>
:)
xmn has joined #yocto
<mcfrisk>
is patch Friday a thing? maybe it should be..
rsalveti has joined #yocto
gho has quit [Ping timeout: 272 seconds]
gho has joined #yocto
<kergoth>
rburton: couldn't you roll your own PATH traversal? if [ -x $pathcomponent/yourbinary ]; then...
<kergoth>
might not be perfect, but in a pinch..
Minvera has quit [Ping timeout: 260 seconds]
<RP>
mcfrisk: I'm a bit torn on your patchset, I'm worried it will make runqemu a bit too chatty. That is useful during debugging like the issue you had but sometimes not so much day to day
<moto-timo>
landgraf: thank you for taking a look. I wonder if this worked differently with rpm5/smartpm vs. rpm4/dnf now?
<moto-timo>
landgraf: that switch happened back in ~2017 poky d4efcded26706f50f8ca98d76df2b349ed1f1792
<moto-timo>
landgraf: or in that time frame anyway
<mcfrisk>
RP: I prefer my builds and CI chatty over nice and quite and not possible to debug..
florian_kc has joined #yocto
<RP>
mcfrisk: do you always run with bitbake -DDDv then?
<Guest84>
Hello, I kindly ask for some guidelines on the topic of splitting the rootfs into several partitions
<Guest84>
We are working on a SOC and the provider has released to us a Yocto baseline. Their approach to rootfs split is to create several Image recipes, each image recipe will create a partition image(.ubi file).
<Guest84>
The architecture team requires to have 3 partitions:
<Guest84>
1- The usual rootfs contents, with FOSS utilities, init, etc
<Guest84>
2- A partition to store executable apprlications and shared libs from dev team A
<Guest84>
3- A partition to store executables and libs for dev team B
<Guest84>
I think the usage of separated Image recipes is not ok. It is creating issues like dupplicated files and also complicating SDK generation
<RP>
mcfrisk: too much output means the user misses things they need to see :/
<mcfrisk>
RP: bitbake is nice and quiet, the task output needs to have a lot of data when things go wrong..
<RP>
mcfrisk: well, I disagree :/
<RP>
There needs to be a balance
<Guest84>
I think it would be better to install all in a single image recipe and split this image in the end
<Guest84>
Is there a recomended approach to this? I know there is a tool called WIC but Im not sure if it fits my use case. I have not researched in dept
<mcfrisk>
This time I was just lucky to have reproducible deadlock. for sure debug output can be reduced. I actually reduced it quite a bit. the ssh run() output is in logs only once. the boot logs are quite important to be there when things go wrong
<ptsneves>
Guest84: what do you expect to get from splitting things into partitions?
<Guest84>
For instance, some recipes would install their files under /partition2, others will install under /partition3
<ptsneves>
yes but what advantages does that provide you at the system level
<kergoth>
Do we have a doc outlining the process to diagnose sstate manifest not found messages, especially with allarch involved?
<Guest84>
ok, to be honest, I dont do this choices.
<Guest84>
But my guess is that it will generate smaller sw update packages
<Guest84>
since the root partition will probably remain mostly unchaged in time
kscherer has joined #yocto
<Guest84>
while probably only partition2 or 3 will be updated
<ptsneves>
ok that sounds maybe fair but then you need to ensure compatibility with themselves. You start to manage a distribution. I think the rootfs is probably small enough to not be worth. You can use RAUC and mini-images to manage partitions and deployment. That is how i would do but it is a complex setup
<Guest84>
ok, thanks will read about it
<Guest84>
is it WIC out of the scope of my use case?
<ptsneves>
it would be in scope, but as an alternative to RAUC. RAUC is more complicated but solves problems you will no doubt face when going with partition swapping. So at least read about RAUC to make the decision.
<ptsneves>
that is my PoV of course
<Guest84>
thanks!
louson has quit [Ping timeout: 252 seconds]
alessioigor has quit [Quit: alessioigor]
azcraft has joined #yocto
<landgraf>
moto-timo: it worked differently. in 2017 it was failing even with package_rpm :)
<moto-timo>
landgraf: heh. so it was an "improvement"
<landgraf>
moto-timo: currently rpm works but ipk fails
<landgraf>
moto-timo: So rpm was improved )
<moto-timo>
landgraf: and deb
<moto-timo>
landgraf: but I suspect if we can figure out a sane fix for ipk, deb will also work
rob_w has quit [Quit: Leaving]
<landgraf>
RP: "funny fact" opkg with internal solver works fine while livsolv doesn't :-/
<landgraf>
RP: My fault it fails with internal solver too (IMAGE_INSTALL+="" should be banned from local.conf :( . It masks so many issues if used)
<landgraf>
(I know it's documented in the reference manual)
<RP>
landgraf: I would love to change things so that didn't do that
leon-anavi has quit [Quit: Leaving]
florian_kc has quit [Ping timeout: 246 seconds]
seninha has quit [Ping timeout: 260 seconds]
<landgraf>
RP: "conflics:" tag doesn't work if architecture of the packages differs (in our case perl is cortexa57 and target-sdk-provides-dummy is arch: sdk_provides_dummy_target) it means package_rpm is even more broken than ipk :-/
<landgraf>
in other words "conflics" does nothing in target-sdk-provides-dummy
<landgraf>
and they're parallel installable because dummy doesn't contain any files for actual conflict
<khem>
JaMa: yeah we need to address LFS64 symbols in binutils perhaps I will look into it post 2.40 merge
Payam has quit [Remote host closed the connection]
Payam has joined #yocto
olani- has joined #yocto
odra has quit [Quit: Leaving]
odra has joined #yocto
<khem>
RP: I am seeing a native package reuse issue - libatomic.so.1 is not uniformly available on all build hosts, so if a native package is built on say debian and reused on fedora37 builder we run into issues like | mtp-hotplug -w > 69-libmtp.hwdb
<khem>
| mtp-hotplug: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory
Minvera has quit [Remote host closed the connection]
Minvera has joined #yocto
<khem>
perhaps building statically solves it
<khem>
but its a thorny problem
ptsneves has quit [Remote host closed the connection]
ptsneves has joined #yocto
Vonter has quit [Quit: WeeChat 3.7.1]
<khem>
I see that none of AB nodes running fedora-like distros have libatomic package installed, perhaps that will be a good thing to improve the sstate use across builders
<khem>
halstead: any thoughts ^^
<halstead>
khem: I suppose that's the best setup. Then we can be sure we use the library we build instead of the host's. Yeah ?
ptsneves has quit [Ping timeout: 255 seconds]
<khem>
I think if you install it on all redhat like devices we should be good too
amitk__ has quit [Ping timeout: 256 seconds]
roussinm1 has quit [Ping timeout: 256 seconds]
seninha has joined #yocto
<halstead>
khem: It's easy enough to add to all those workers but doesn't that cover up potential problems?
<khem>
perhaps yes
Minvera has quit [Read error: Connection reset by peer]
Minvera has joined #yocto
mvlad has quit [Remote host closed the connection]
manuel1985 has joined #yocto
odra has quit [Quit: Leaving]
<RP>
khem: I think we need to fix the build
manuel1985 has quit [Ping timeout: 264 seconds]
manuel1985 has joined #yocto
seninha has quit [Remote host closed the connection]
<landgraf>
I should have read SDK section of the YP docs before...
azcraft has quit [Remote host closed the connection]
<khem>
RP: in what way should build be fixed ?
seninha has joined #yocto
<RP>
khem: can we put a copy of libatomic into uninative?
d-fens has quit [Read error: Connection reset by peer]
<khem>
libatomic is part of gcc
<RP>
khem: we already put libgcc into uninative
<khem>
I see that libusb tries to find who provides __atomic_fetch_add_4 during configure and on non-fedora hosts it says checking for library containing __atomic_fetch_add_4... -latomic
<khem>
but on fedora it says checking for library containing __atomic_fetch_add_4... no
<khem>
simply adding libatomic to pre-requisites might be simpler IMO