Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rfuentess has joined #yocto
Chaser has joined #yocto
ptsneves has joined #yocto
Chaser has quit [Ping timeout: 276 seconds]
Vonter has quit [Ping timeout: 276 seconds]
Vonter has joined #yocto
can_u_kick_it has joined #yocto
leaf_it_out has quit [Quit: leaf_it_out]
<can_u_kick_it>
Hi, I have a question regarding using devtool to and how it treats bbappends. Is it Ok to Just post it here?
prabhakalad has quit [Ping timeout: 276 seconds]
prabhakalad has joined #yocto
walter has quit [Quit: Konversation terminated!]
<yocton>
can_u_kick_it: yes :)
walter has joined #yocto
ptsneves has quit [Ping timeout: 248 seconds]
thomas_34 has joined #yocto
sakoman has quit [Ping timeout: 260 seconds]
sakoman has joined #yocto
<can_u_kick_it>
Thanks. Well I have created a workspace using devtool modify linux-raspberrypi (which is in meta-raspberrypi layer), however there are bbappend fiels in meta-boot2qt-distro/dynamic-layers. These are not included in the workspace. If a create patch to apply in my own layer how should I test that there is no interferecne between layers when testing to compile in the workspace.
thomas_34 has quit [Quit: Client closed]
ptsneves has joined #yocto
dlpartain has quit [Quit: Client closed]
Guest9 has joined #yocto
<Guest9>
Hi, how I can pass the -DFOO_MYMACRO to kernel module build?
<yocton>
can_u_kick_it: ideally, yes, you should test. Realisticaly, if that's for a private project and you don't use the dynamic layers parts, I would not bother.
ptsneves has quit [Ping timeout: 276 seconds]
ptsneves has joined #yocto
dlpartain has quit [Ping timeout: 272 seconds]
prabhakalad has quit [Quit: Konversation terminated!]
Guest9 has quit [Quit: Client closed]
florian_kc is now known as florian
ablu has quit [Ping timeout: 260 seconds]
ablu has joined #yocto
ptsneves has quit [Read error: Connection reset by peer]
<mcfrisk>
clang compiles are crazy. I must have sstate wrongly setup since qemuarm64 and genericarm64 end up recompiling clang-native all the time. rootfs and initrd recipes are compiled but still waiting for clang, I guess for some qemu, mesa related native dependency
<rburton>
yeah qemu-system pulls in mesa-native thus clang-native by default
<rburton>
(packageconfig, you can nuke it)
<rburton>
but yes, if its rebuilding for a target switch then either the recipe is very broken or your sstate isn't being shared
<mcfrisk>
sstate and download configs point to same directory, but still these clang and qemu native things are not picked up..
<rburton>
very odd
<rburton>
if you can replicate from master and a pristine tree then please do file a bug
Minvera has quit [Ping timeout: 248 seconds]
ptsneves has joined #yocto
dlpartain has quit [Quit: Client closed]
walter has quit [Quit: Konversation terminated!]
<RP>
mcfrisk: you have hashserve set?
<RP>
can_u_kick_it: might be worth filing a bug for the issue. No promises on when it might get fixed but probably worth trackin
dgriego has quit [Ping timeout: 248 seconds]
dgriego has joined #yocto
chep` has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
walter has joined #yocto
walter has quit [Changing host]
walter has joined #yocto
<qschulz>
mcfrisk: rburton: I may end up making the libclc packageconfig in mesa-native mandatory
<qschulz>
to save from building libclc for the target (required for asahi and panfrost)
<rburton>
qschulz: i've also related plans to chop up the clang recipe a bit more, pull stuff like clc and lldb out of the clang recipe itself
<mcfrisk>
RP: no hashserver set, using defaults from poky for qemuarm64 and genericarm64. I'd like to see fever variants of the native toolchain. Don't really care how much or which features get enabled but would be nice to share the tooling across target machines for same arch like arm64
<rburton>
mcfrisk: there are no variants for native stuff
<rburton>
only gcc-cross will rebuild due to how it has to be built
rob_w has quit [Remote host closed the connection]
<rburton>
you should only ever build one clang-native, so if it rebuilds on a metadata change then congrats thats a bug
<rburton>
(entirely likely there's a bug, its a new recipe in core)
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
<RP>
mcfrisk: you won't get sstate reuse if you don't also use hashserve
<RP>
mcfrisk: we do try and keep native variants to a minimum
<mcfrisk>
RP: thanks, that explains it then
<mcfrisk>
I always thought sharing the same sstate directory would be enough, and been wondering why it's not
Chaser has joined #yocto
<RP>
mcfrisk: basically, unless you use the hashserve that matches the sstate, remapping goes back to different hashes and it won't match
<RP>
mcfrisk: pre hash equivalence you just needed to share sstate but if you have hash equivalence enabled, you need that as well as sstate
<mcfrisk>
I wonder if I should just use meta/conf/fragments/yocto/sstate-mirror-cdn.conf
<RP>
mcfrisk: it was designed to get the settings right :)
<qschulz>
:sob: 1h30 in and clang-native is only half way through compilation
<RP>
I'm mentioned the clang performance problem a lot. It would appear from the reaction from people that nobody actually cares and it is fine :/.
<qschulz>
where can I download more CPU cores
<qschulz>
RP: people only start complaining once they need to compile it, which isn't necessarily always the case I guess
<qschulz>
turns out I would like to have GPU on master and mesa requires clang for that :/
<qschulz>
(but also, our product line is only running scarthgap which won't be able to have GPU support... so only trying to anticipate stuff for next LTS now 😬)
<RP>
qschulz: it is good at least some people are noticing I guess
<RP>
qschulz: I'm just frustrated as I can't keep an eye one and address all the issues and people's expectations are that somehow I will/can
<RP>
s/one/on/
<qschulz>
I'm just surprised none of the bigtech players have noticed this yet and sent a patch publicly
<qschulz>
but maybe they are running behind and not on master yet
goliath has quit [Quit: SIGSEGV]
<qschulz>
or they just throw more CPUs at it :)
<rburton>
qschulz: sadly there's no -DBUILD_FAST_PLEASE=1 fix
<rburton>
i have thoughts about ripping up the clang recipe so eg lldb is a separate recipe but it would be a lot easier after the toolchain changes land
<qschulz>
if d.getVar(BUILD_FAST_PLACE): bb.skipParseRecipe()
<qschulz>
tada
<Saur>
qschulz: That's like the -fdwiw switch our compiler expert keeps mentioning. It is still missing...
<rburton>
I suspect we can fiddle the mesa-native build to not pull in clang
<rburton>
but considering my qemu is headless i'm not exactly the best person to test that
<qschulz>
rburton: will need libclc (and thus clang AFAIU) in mesa-native soon
<rburton>
what for?
<qschulz>
I believe so that panfrost and asahi can use mesa-clc=system with only mesa-native as dependency and not other dependencies
<qschulz>
still need to check
<qschulz>
building precomp-compilers as well and reusing those
<qschulz>
but I need basically my target recipe to depend on a PACKAGECONFIG from my native recipe, and this we don't do as they are different recipes anyway
<rburton>
i'd love it if it were possible to build the user-facing bits and the drivers separately too
<qschulz>
it says I can cross compile without LLVM (on target; but required on host) by using system for mesa-clc and precomp-compiler for target recipe
<qschulz>
if I build enabled for mesa-clc and precomp-compiler for native recipe
<qschulz>
so my understanding is that then my mesa's libclc option would only depend on mesa-native and not llvm, spirv and whatnot like it does today
<rburton>
i'm having dinner with a mesa developer on thursday. i can withhold food until they draw a flow chart of how to cross-compile panfrost optimally
<qschulz>
(I believe it would be close to what's needed for asahi as well since they both use precom-compilers and libclc and whatnot)
<RP>
rburton: haha, that sounds fun
<rburton>
qschulz: is someone/you trying to build a yocto for apple silicon?
<qschulz>
rburton: seems like it somehow?
<qschulz>
rburton: Markus added support for it (and a later patch to fix it (though it's debated whether the fix is actually a fix))
pbiel has joined #yocto
florian has quit [Ping timeout: 252 seconds]
frgo has quit [Read error: Connection reset by peer]
frgo has joined #yocto
florian has joined #yocto
pbiel has quit [Quit: Leaving]
walter has quit [Quit: Konversation terminated!]
ptsneves has quit [Ping timeout: 260 seconds]
mckoan is now known as mckoan|away
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
rfuentess has quit [Remote host closed the connection]
<alperak>
I'm trying to put kernel modules into rootfs but nothing showing up in the rootfs. Tried with MACHINE_EXTRA_RRECOMMENDS += "kernel-modules" and MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
<alperak>
Am I missing something?
tgamblin has quit [Ping timeout: 244 seconds]
tgamblin_ is now known as tgamblin
<alperak>
Tried with the core-image-base so packagegroup-core-boot added to image. MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS must work, isn't it?
<rburton>
alperak: meta-arm does MACHINE_EXTRA_RRECOMMENDS += "kernel-modules" so yes that should work
<alperak>
@rburton I checked the manifest file of core-image-base and there are no modules. I mean just two module available kernel-module-autofs4 and kernel-module-sch-fq-codel.
<rburton>
use bitbake-getvar to check the content of PACKAGE_INSTALL for your image
steelswords94361 has quit [Quit: Ping timeout (120 seconds)]
steelswords94361 has joined #yocto
florian has quit [Killed (NickServ (GHOST command used by florian_kc!~florian@2a02:3100:45d4:2600:c754:bbca:b216:81eb))]
florian_kc is now known as florian
florian_kc has joined #yocto
<alperak>
@rburton found it. i forgot a line in “IMAGE_INSTALL += foo” in conf/local.conf and somehow it disables packagegroup-core-boot and packagegroup-base-extended, so it doesn't add kernel-modules to the image. most probably they are disabled if IMAGE_INSTALL is defined.
<alperak>
but if i use IMAGE_INSTALL:append = " foo", it works right.
_lore_ has quit [Ping timeout: 245 seconds]
_lore_ has joined #yocto
kanavin has quit [Remote host closed the connection]
kanavin has joined #yocto
tlwoerner has quit [Ping timeout: 248 seconds]
tlwoerner has joined #yocto
<rburton>
alperak: you're replacing the default
<alperak>
yes, noticed. thank you!
Vonter has quit [Ping timeout: 260 seconds]
Articulus has joined #yocto
ptsneves has joined #yocto
_lore_ has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<can_u_kick_it>
Thanks. Don't know how I missed that as I was looking in open embedded core as well but it didn't come up. Problem between keyboard and seat.
<can_u_kick_it>
One more please. I am adding a device tree overlay (dts file) and I have found a varible in meta-raspberrypi/conf/machine/raspberrypi-armv8.conf called KERNEL_DEVICETREE. Do I need to add my dts file (via bbappend) to this list to ensure it is compiled?
<mischief>
probably
<RP>
I just merged the toolchain selection pieces
savolla has quit [Ping timeout: 260 seconds]
druppy has quit [Ping timeout: 245 seconds]
jpuhlman- has quit [Ping timeout: 248 seconds]
zeemate has quit [Ping timeout: 260 seconds]
jan_ has quit [Ping timeout: 244 seconds]
kergoth has quit [Quit: Connection closed for inactivity]
alperak has quit [Quit: Connection closed for inactivity]