<zwelch>
my builds are suddenly failing due to failures trying to access github repos. It seems that https://github.com/a/b does not work but https://git@github.com/a/b does work (for various known good values of a and b). any ideas?
sakoman has joined #yocto
dlan_ is now known as dlan
invalidopcode1 has quit [Remote host closed the connection]
<mcfrisk>
what are the major reasons for recompiling glibc and other low level bits across compatible machines and distros? I have a custom machine and distro, both derived from poky qemuarm64 machine and poky distro config. taking a poky only machine with sstate and download cache from my custom builds ends up recompiling everything
<JaMa>
mcfrisk: compare the signatures to see what metadata difference triggered the rebuild (you can use sstate-diff-machines.sh script)
mvlad has joined #yocto
dacav has quit [Quit: Lost terminal]
dacav has joined #yocto
davidinux has joined #yocto
<mcfrisk>
JaMa: yep, will check once build passes. just wondering why glibc and others aren't compatible. things like selinux in DISTRO_FEATURES should not impact glibc. and plain MACHINE name should also not trigger recompilation of everythint, especially if MACHINEOVERRIDES includes the poky side machine name.
ptsneves has joined #yocto
thomasd13 has quit [Quit: Leaving]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<tomzy_0>
Hello
<tomzy_0>
this is probably more of the compilation problem
<tomzy_0>
but I try to enable meta-qt6 in my build
<tomzy_0>
and have the following problem when compiling qtbase-native
<tomzy_0>
```
<tomzy_0>
| /work/build-wayland/tmp/work/x86_64-linux/qtbase-native/6.3.2-r0/git/src/corelib/text/qlocale_tools.cpp:57:10: fatal error: charconv: No such file or directory | #include <charconv>
<tomzy_0>
| ^~~~~~~~~~
<tomzy_0>
| compilation terminated.
<tomzy_0>
```
<tomzy_0>
Does anyone have maybe an idea, what could be not working well?
<dacav>
tomzy_0: I don't know much but... missing DEPEND?
<qschulz>
zwelch: aren't you supposed to use git://github.com in SRC_URI and then specifiy protocol=https if you want to use https protocol for git cloning instead of the default git (non-working anymore IIRC)
<mcfrisk>
tomzy_0: old or too new host compiler for the version of qtbase-native that you want to compile. I'd try to avoid compiling qtbase for the build host (-native)
<RP>
mcfrisk: one problem is often systemd or not which changes glibc :(
<RP>
mcfrisk: we don't have many people interested and looking into reuse issues like that either. I have done but it is a lonely place
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
<tomzy_0>
mcfrisk so this is probably too old one.. so basically when I build any `-native` package I am using compiler/tools on my host machine to build them?
<tomzy_0>
Now I am using some docker container with Ubuntu 18.04
<tomzy_0>
so switching to e.g. Ubuntu 20.04 with newer host compiler should resolve this issue
florian_kc has joined #yocto
seninha has joined #yocto
<mcfrisk>
tomzy_0: yes, the host linux distro compiler is used for native. Newer Ubuntu with newer gcc will likely fix this.
<mcfrisk>
RP: yea, no worries. I was just hoping there would be simple thing which I missed which cause so little to be reused when deriving distro and machine from poky ones..
<tomzy_0>
Yeah, look like that qt6 layer is not supported on Ubuntu 18.04 (when Yocto is) - changing to 20.04 resolved the issue
<tomzy_0>
Thanks!
<dacav>
In a bbclass, can I just use any python construct? E.g. can I define a class?
<rburton>
no. but you can write a .py file, put it in your layer's lib/ and then just use it
<rburton>
see oe-core, lots of classes which have the bulk of their logic in lib/oe/
<dacav>
thanks rburton! That's great
amitk has joined #yocto
<dacav>
After some initial difficulties, things are coming now
<dacav>
Btw, I'm not sure how this happened, but now the speed of parsing is reasonable, as long as I don't add a global recipe. It looks like it was some caching problem. I *think* it happened after I removed sstate. What is a reasonable size for the sstate dir?
<rburton>
depends on your needs
<rburton>
if you build a lot of WIP patches and whole images, you can easily get into TBs
rob_w has quit [Remote host closed the connection]
amitk has quit [Ping timeout: 248 seconds]
manuel__ has joined #yocto
manuel1985 has quit [Ping timeout: 260 seconds]
jmk44 has quit [Ping timeout: 260 seconds]
<qschulz>
ptsneves: :+1:
jmk1 has joined #yocto
sakoman has joined #yocto
demirok has quit [Quit: Leaving.]
xmn has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
TundraMan is now known as marka
demirok has joined #yocto
demirok has quit [Quit: Leaving.]
<kayterina[m]>
Is there a way to check my project for missing COMPATIBLE_MACHINE recipes?
<kayterina[m]>
I ran a 'bitbake -c cleanall world' and some recipes produced the error:
<kayterina[m]>
<something> was skipped: incompatible with machine <machine> (not in COMPATIBLE_MACHINE)
<kayterina[m]>
ERROR: Nothing RPROVIDES '<something>' (but <project>/recipeA.bb RDEPENDS on or otherwise requires it)
zpfvo has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
<rburton>
bitbake world --dry-run
<rburton>
a dry run won't actually build but will go through the motions
<ptsneves>
rburton: do all recipes become automatically part of the world provider?
<rburton>
EXCLUDE_FROM_WORLD=1 skips the recipe from world
<rburton>
there is the universe target, which can't be skipped
invalidopcode1 has quit [Remote host closed the connection]
<ptsneves>
always learning :)
invalidopcode1 has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
<kergoth>
hmm, iirc universe also builds all providers of a given thing, whereas world only builds only the selected one, I think? been ages since i've run either one
* kergoth
yawns
nemik has joined #yocto
florian has quit [Ping timeout: 268 seconds]
<rburton>
honestly can't remember how universe works
Payam has joined #yocto
<RP>
universe does try everything and will usually generate warnings
Estrella has quit [Quit: No Ping reply in 180 seconds.]
Estrella has joined #yocto
Estrella_ has joined #yocto
mvlad has quit [Remote host closed the connection]
armhzjz has joined #yocto
sakoman has quit [Quit: Leaving.]
<armhzjz>
I created a yocto image which is already running in a raspberrypi. Then, I added another package (vim) to the yocto image recipe and re-built the image. Is there a way to deploy the new package to the raspberrypi without having to re-flash the sd-card?
<RP>
khem: looks like weston segfaulting with the new glibc
<Saur[m]>
armhzjz: You can use `devtool deploy-target`, assuming the rootfs is writable.
azcraft has quit [Remote host closed the connection]
<armhzjz>
Saur[m]: thanks! But in order to use that approach, I would need the vim recipe to be in my workspace right (like if I were working on that recipe)? Do you know if there is any other way?
<Saur[m]>
armhzjz: `devtool modify -w vim` should solve that. The alternative would be using a package manager, but that is a lot more work to setup initially.
<armhzjz>
Saur[m]: what about using the extensible SDK? I just started reading about it in the documentation. I thought that could help, but was also wondering if it wouldn't be too much of a hassle for just adding one small package...
<Saur[m]>
Since you already have the bitbake environment, using the eSDK wouldn't give you anything that you do not already have. Just use `devtool modify -w vim`, `bitbake vim` and `devtool deploy-target vim <IP address>`
<armhzjz>
Saur[m]: Yeah.. I get it now. Thanks a lot. I will follow your advice. Thanks again!
gsalazar has quit [Remote host closed the connection]