dankm has quit [Remote host closed the connection]
dankm has joined #yocto
Jones42_ has joined #yocto
Jones42 has quit [Ping timeout: 252 seconds]
xmn_ has joined #yocto
xmn has quit [Ping timeout: 246 seconds]
xmn_ has quit [Client Quit]
Daanct12 has quit [Ping timeout: 265 seconds]
Daanct12 has joined #yocto
<khem>
DvorkinDmitry: [depends] here is specifying inter-task dependency and its variable flag syntax, it does not allow override style syntax append/prepend/remove it does allow all other standard variable operation like =, +=
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
sugoi has quit [Ping timeout: 246 seconds]
sugoi has joined #yocto
Guest51 has joined #yocto
sugoi has quit [Ping timeout: 246 seconds]
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<Guest51>
Hi, I want to know how Yocto internally cross compiles python libraries, the tools it use and whole process of how yocto cross compiles python libraries for any target board
<Guest51>
Also in general without using yocto how we can cross compile python libraries for any target board with the help of its toolchain and which tools we have to use
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
albeu has joined #yocto
frieder has joined #yocto
wojci__ has joined #yocto
albeu has quit [Quit: Client closed]
Habbie has joined #yocto
Habbie has quit [Read error: Connection reset by peer]
Habbie has joined #yocto
Habbie has quit [Read error: Connection reset by peer]
fotte has joined #yocto
albeu has joined #yocto
leon-anavi has joined #yocto
florian_kc has joined #yocto
CrazyGecko has joined #yocto
mckoan|away is now known as mckoan
Kubu_work has joined #yocto
rfuentess has joined #yocto
<RP>
Guest51: all the code is there so you can see how it does it! :)
<albeu>
RP: I think the issue is due to a different directory layout of the layers between my machine and the build server. On my machine I have all layers next to each other in the same directory, on the buildserver the additional layers are checked out in a sub directory of the main layer. AFAICT the full path of files are used for sorting the
<albeu>
file_checksum_values array which result in the different ordering when some files come from the dependent layers.
<albeu>
sure I'll test that. I was wondering if it might not make more sense to sort by the hash as that would also deal with duplicate basename
<albeu>
or is there some cases where there is no hash?
<RP>
albeu: there are cases where the location of the file in the directory structure matters and needs to be accounted for (with the same hash)
<RP>
albeu: there are ways that could still be accounted for but...
Guest51 has quit [Ping timeout: 256 seconds]
mbulut_ has joined #yocto
<albeu>
RP: While we are on the sstate topic I was first thinking that the issues I'm seeing came from the fact that do_fetch (which is arch-less) depend on do_recipe_qa (which is arch specific) and opened this bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=15588 Can this be an issue too, or am I missing something and it doesn't really matter?
CosmicPenguin has quit [Ping timeout: 260 seconds]
Xogium has quit [Ping timeout: 260 seconds]
CosmicPenguin has joined #yocto
OnkelUll_ has joined #yocto
brrrm has joined #yocto
brrm has quit [Ping timeout: 260 seconds]
sarahn has quit [Ping timeout: 260 seconds]
jclsn has quit [Ping timeout: 260 seconds]
tleb has quit [Ping timeout: 260 seconds]
OnkelUlla has quit [Ping timeout: 260 seconds]
Xogium has joined #yocto
jclsn has joined #yocto
tleb has joined #yocto
florian_kc has quit [Ping timeout: 276 seconds]
Habbie has joined #yocto
goliath has joined #yocto
sarahn has joined #yocto
Guest51 has joined #yocto
<RP>
albeu: could you check that is the case with recent master? There were some changes recently which should have at least significantly helped with that
fotte_ has joined #yocto
<RP>
albeu: I replied in the bug to capture that
Habbie has quit [Quit: once more]
<albeu>
I'll see what I can do. Looking at master do_fetch still depend on do_recipe_qa so the taskhash of do_fetch will still be arch dependent
Habbie has joined #yocto
<RP>
albeu: why would that make it arch dependent ?
fotte has quit [Ping timeout: 252 seconds]
<albeu>
The do_fetch sstate contains the taskhash of do_recipe_qa so each arch has a different do_fetch taskhash
<RP>
albeu: If do_recipe_qa isn't arch specific, that wouldn't be true
<albeu>
If, but they currently are. I saw some diff that was full of arm vs x86 stuff
<albeu>
TUNE_FEATURES and a lot of other arch tunning related stuff differ
<RP>
that might be fixable though
<albeu>
In principle that sounds strange to have arch-less stuff depend arch-specific stuff and currently only the 'do_fetch', 'do_unpack', 'do_patch', 'do_populate_lic', 'do_preconfigure' tasks are made arch-less when the sstate is created
<albeu>
But that shouldn't break anything, there will just be more do_fetch sstate than really needed, right?
<RP>
albeu: it shouldn't be arch specific
<RP>
albeu: it won't really matter since do_fetch isn't an sstate task anyway
<Dvergatal>
khem: ahh yeah you are right
<Dvergatal>
khem: but for now this RRECOMENDS, BAD_RECOMMENDATIONS and splitting procps-sysctl into to separate packages is sufficient
<albeu>
RP: I see, thanks for taking the time to help with this