qschulz_ has quit [Remote host closed the connection]
qschulz has joined #yocto
Saur63 has joined #yocto
Jones42_ has joined #yocto
jclsn has quit [Ping timeout: 246 seconds]
jclsn has joined #yocto
Jones42 has quit [Ping timeout: 252 seconds]
starblue1 has quit [Ping timeout: 246 seconds]
starblue1 has joined #yocto
Saur_Home68 has quit [Quit: Client closed]
Saur_Home68 has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jclsn has quit [Ping timeout: 252 seconds]
jclsn has joined #yocto
ablu has quit [Ping timeout: 252 seconds]
ablu has joined #yocto
Jones42 has joined #yocto
Jones42_ has quit [Ping timeout: 252 seconds]
steelswords9 has quit [Read error: Connection reset by peer]
steelswords9 has joined #yocto
ssweeny has quit [Quit: Gateway shutdown]
ssweeny has joined #yocto
enok has joined #yocto
xmn_ has joined #yocto
xmn has quit [Ping timeout: 246 seconds]
enok has quit [Quit: enok]
enok71 has joined #yocto
enok71 is now known as enok
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #yocto
prabhakalad has quit [Ping timeout: 245 seconds]
prabhakalad has joined #yocto
enok has quit [Quit: enok]
sugoi has quit [Ping timeout: 255 seconds]
<khem>
jonmason: I have not seen this, but it seems to be due to the library being provided by both llvm-native and clang-native, I dont see it because when using meta-clang, I completely override llvm-native
<mcfrisk_>
RP kanavin: should I post new version of uki bbclass patches now or after release? I've refactored the wic plugin and selftests to use uki.bbclass.
sugoi has quit [Ping timeout: 252 seconds]
<RP>
mcfrisk_: if it is ready I'd say post it...
ehussain has quit [Quit: ehussain]
sugoi has joined #yocto
<mcfrisk_>
RP: alright, will do. I presume the ovmf update is in some post-release queue too. will not re-submit that. Not a direct dependency but slightly related
sugoi has quit [Ping timeout: 260 seconds]
florian has joined #yocto
sugoi has joined #yocto
sugoi has quit [Ping timeout: 252 seconds]
vthor has quit [Excess Flood]
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
cabazon has joined #yocto
sugoi has joined #yocto
sugoi has quit [Ping timeout: 246 seconds]
grma has quit []
sugoi has joined #yocto
sugoi has quit [Ping timeout: 252 seconds]
sugoi has joined #yocto
sugoi has quit [Ping timeout: 252 seconds]
starblue1 has quit [Ping timeout: 248 seconds]
starblue1 has joined #yocto
sugoi has joined #yocto
michaelo has quit [Ping timeout: 245 seconds]
michaelo has joined #yocto
sugoi has quit [Ping timeout: 252 seconds]
sugoi has joined #yocto
sugoi has quit [Ping timeout: 252 seconds]
cabazon has quit [Quit: Client closed]
sugoi has joined #yocto
sugoi has quit [Ping timeout: 245 seconds]
sugoi has joined #yocto
sugoi has quit [Ping timeout: 272 seconds]
sugoi has joined #yocto
wdouglass has quit [Remote host closed the connection]
sugoi has quit [Ping timeout: 276 seconds]
Tyaku has joined #yocto
<Tyaku>
Hello, Is it possible to have a machine that regroup two machines ? For exemple, I have a product type which is "Matter light" (should be the common machine), but I have two products "diming light" and "color light". I want to put common things in "matter_light" machine and specific things in "matter_color_light" or "matter_dimming_light" for example. Is it possible ?
<Tyaku>
NB: I take this example with lights because I think it's easy to understand the need, but in fact the product is not a light.
<mcfrisk_>
Tyaku: sure. I think usecase specific machine configs are wrong in many ways. You can have a single machine config and multiple images for the different usecases. Or in the best case a single machine and distro config and even a single image which detects usecases at runtime
sugoi has joined #yocto
<Tyaku>
In fact this is the situation: Whe have TWO IOT hubs, one using IMX8MN (nxp) another one using RZG2UL (renesas). So currently we have two machines, one for the NXP, one for the RENESAS. But the renesas have two variants called BASIC and FULL, the variants have different HW (different WiFi chipset, one has Subghz capability and not the other, no ethernet on the basic)
<Tyaku>
So for example, depending if it's a FULL or a BASIC (variant), we need different DTS, also different services configurations, for example in one we need to start the WiFi driver "moal" and in the other "esp_hosted_ng" etc.
<mcfrisk_>
all that can be detected at runtime too
<mcfrisk_>
systemd services triggered by available HW and firmware configs etc. help from bootloaders may be needed.
sugoi has quit [Ping timeout: 260 seconds]
<Tyaku>
But for example for the DTS, how you configure the DTS differently if it's the same machines ?
<Tyaku>
For example: Disable Ethernet on "BASIC" board, Configure pins for the ESP32C3 on basic board, but configure different pins on the FULL board for another WiFi chip.
<mcfrisk_>
build two DTSes and decide in factory which one to flash to HW
<mcfrisk_>
discoverable buses help
<Tyaku>
Ok I understand the idea
<mcfrisk_>
kernel not a problem, same for userspace (udev, systemd/sysvinit)
<mcfrisk_>
problem may be in firmware side e.g. how to build multiple u-boot versions, and for that u-boot recipe supports it within a single machine config
<mcfrisk_>
if u-boot and something else, or two different recipes for u-boot from different vendors trees, then different recipes for them. as long as CPU tuning values are compatible, then all good
<Tyaku>
First I'm going to check/list all the differences, and after I will watch if it's possible to do how you say.
<mcfrisk_>
for the really low level things, and things like secure boot, multiconfig may be needed to keep things a bit more separated. or if another vendor provides HW and the firmware as binaries..
<mcfrisk_>
I have found in real life that building completely separate SW stack due to minor usecase or HW differences kills productivity
<mcfrisk_>
e.g. CI builds and testing become really slow, local builds take too much time. And then developers start working aroung those and soon there are even more variants, if product succeeds in the market..
sugoi has joined #yocto
tgamblin_ has joined #yocto
tgamblin has quit [Ping timeout: 252 seconds]
sugoi has quit [Ping timeout: 246 seconds]
<Tyaku>
mcfrisk_: I think we are going to keep two machine for the different brand (NXP / RENESAS), like now. BUT for the product differences for the RENESAS hub, (BASIC / FULL) we are going to check if it's possible to do it like you said: At runtime/different dts/etc. I take a note of all the discussion
tgamblin_ is now known as tgamblin
MrTatillon has joined #yocto
<mcfrisk_>
Tyaku: sounds good. been there too. note that there is often configuration in firmware too, e.g. device types, serial numbers, plain config flags, which can be exposed to firmware and all the way to userspace to change behavior at runtime
rfuentess has quit [Remote host closed the connection]
<Tyaku>
At the production we will set some variables in U-Boot env (MAC address, serial number, informations for OTA like board type etc) you are talking about it ? We are also watching about "secured storage" to store key's to do certificate checks/signature from the burned key. (This part will not be in U-Boot but something related to renesas) (not checked yet)
sugoi has joined #yocto
<MrTatillon>
Bonjour, je construis mon projet Yocot sur OpenSUSE 15.4
<MrTatillon>
J'ai d'abord essayé de migrer mon ancien projet de Krogoth à Dunfell (pour la version poky).
<MrTatillon>
Mais récemment, j'ai vu que Dunfell était en fin de vie, et quelqu'un m'a suggéré de passer à une version plus récente de poky, donc aujourd'hui j'ai essayé de passer à la version Scarthgap.
<MrTatillon>
Lors de cette mise à jour, j'ai eu des problèmes avec Pyhton3 (version 3.6 au lieu de la version 3.8 qui est requise)
<MrTatillon>
Maintenant, lorsque j'essais de compiler j'ai une erreur avec la lib "_ctypes"
<MrTatillon>
Je ne comprend pas pourquoi, OpenSUSE 15.4 est bien compatible avec Scarthgap, pourquoi est-je ten de problème avant même de débuter la vrais compilation ??
<MrTatillon>
Could not find platform dependent libraries <exec_prefix>
<MrTatillon>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
<MrTatillon>
Traceback (most recent call last):
<MrTatillon>
File "/home/aquassay/yocto/rpi-lite/scarthgap/poky/bitbake/bin/bitbake", line 21, in <module>
<MrTatillon>
import bb
<MrTatillon>
File "/home/aquassay/yocto/rpi-lite/scarthgap/poky/bitbake/lib/bb/__init__.py", line 23, in <module>
<MrTatillon>
import ctypes
<MrTatillon>
File "/usr/local/lib/python3.8/ctypes/__init__.py", line 7, in <module>
<MrTatillon>
from _ctypes import Union, Structure, Array
<MrTatillon>
ModuleNotFoundError: No module named '_ctypes'
<MrTatillon>
```
<MrTatillon>
Hello, I'm building my Yocot project on OpenSUSE 15.4
<MrTatillon>
I first tried to migrate my old project from Krogoth to Dunfell (for the poky version).
<MrTatillon>
But recently I saw that Dunfell was at the end of its life, and someone suggested I upgrade to a newer poky version, so today I tried to upgrade to the Scarthgap version.
<MrTatillon>
During this upgrade, I had problems with Pyhton3 (version 3.6 instead of the required 3.8).
<MrTatillon>
Now, when I try to compile I get an error with the “_ctypes” lib
<MrTatillon>
I don't understand why, OpenSUSE 15.4 is compatible with Scarthgap, why do I have such a problem before I even start compiling?
<MrTatillon>
Translated with DeepL.com (free version)
<MrTatillon>
If anyone can help me, it would be a pleasure :)
<MrTatillon>
Note that importing '_ctypes' in a Python2 terminal works, but not in my Python3 terminal. I assume this is due to my installation of Python 3.8, but I don't understand why or how to solve the problem.
sugoi has quit [Ping timeout: 248 seconds]
<mcfrisk_>
Tyaku: yes, those things. Of course devicetrees are one way but there are others too, including the device and vendor serial numbers. secure storage helps to add more feature flags, feature specific keys etc.
rfuentess has joined #yocto
sugoi has joined #yocto
sugoi has quit [Ping timeout: 252 seconds]
rfuentess has quit [Remote host closed the connection]
jmd has joined #yocto
grma has joined #yocto
sugoi has joined #yocto
Minvera has joined #yocto
sugoi has quit [Ping timeout: 260 seconds]
khimaros has quit [Ping timeout: 272 seconds]
xmn has joined #yocto
sugoi has joined #yocto
sugoi has quit [Ping timeout: 260 seconds]
Saur_Home68 has quit [Quit: Ping timeout (120 seconds)]
sugoi has joined #yocto
wojci has quit [Ping timeout: 260 seconds]
sugoi has quit [Ping timeout: 265 seconds]
sugoi has joined #yocto
Guest44 has joined #yocto
sugoi has quit [Ping timeout: 245 seconds]
<Guest44>
Question about the bmap-tool. Normally our other developers write the USB Disk directly via BMPTOOL, much like the wiki page says: bmaptool copy build-directory/tmp/deploy/images/machine/image.wic /dev/sdX, instead of writing to /dev/sdX - can I write to a file - then later use DD (on Linux) to write the image at a later time? Or - better -
<Guest44>
What tool can I use on Windows to write the image to a USB Drive, would RUFUS or ETCHER do this? Problem I have is our builds are done on a VM SERVER with no usb interface to write to the USB drive
Xagen has joined #yocto
sugoi has joined #yocto
sugoi has quit [Ping timeout: 246 seconds]
Guest44 has quit [Quit: Client closed]
<khem>
etcher would work fine on windows
<vmeson>
khem: correction about cargo and riscv64 - I don't see that error in our AB. I do see a periodic stack overflow for debug builds only. Sorry for the incorrect data yday.
sugoi has joined #yocto
sugoi has quit [Ping timeout: 246 seconds]
florian has quit [Ping timeout: 246 seconds]
sugoi has joined #yocto
rfuentess has joined #yocto
sugoi has quit [Ping timeout: 246 seconds]
florian has joined #yocto
<qschulz>
MrTatillon: did you install the required packages on openSUSE? Est-ce que tu as installé les paquets nécessaires sur ta distro?
<qschulz>
i don't know where and what you need to know for your imager plugin to be found by wic though
wojci has quit [Ping timeout: 264 seconds]
Kubu_work has quit [Quit: Leaving.]
Kubu_work1 has joined #yocto
zpfvo has quit [Remote host closed the connection]
Kubu_work1 has quit [Client Quit]
Kubu_work has joined #yocto
<ayaka>
qschulz, I don't use the default direct image plugins
<ayaka>
s/image/imager/
<ayaka>
And for the WKS_FILE, without the wic -i argument, I don't want generate any image actually
<ayaka>
I just want to prepare the rootfs and those deploy images, then wic command could do the rest of work since I may not decided which wks I want to use
<ayaka>
qschulz, bitbake image-recipe do call wic when use with IMAGE_FSTYPES="wic" and WKS_FILE set
<ayaka>
but that is not what I want, I want the bitbake call wic not using the default direct imager plugin
<ayaka>
or bitbake just don't call wic itself, I would call wic manually
<ayaka>
so for the second method, should I set IMAGE_FSTYPES to none (IMAGE_FSTYPES="")
reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
<qschulz>
yes
<ayaka>
I think I can complete the doc with that. Actually, I have done that, I am just not sure whether I did it right and whether it would cause some side effect
<qschulz>
ayaka: would be nice to add something in the variables glossary for this I believe!
florian_kc has joined #yocto
sudip has joined #yocto
rcwoolley has joined #yocto
rcwoolley has quit [Quit: rcwoolley]
tgamblin_ is now known as tgamblin
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
<usvi>
how can I influence the xz packager of the final image to use threads ? I'm using kirkstone
<usvi>
I have 4 cores available but yocto calls xz with only one
<usvi>
XZ_THREADS ?
<khem>
yes
<khem>
but also limit how much memory these threads can take
<khem>
because multiple invocation can mean you run out of memory
<khem>
something like XZ_MEMLIMIT = "20%"
<khem>
will keep it capped under 20% of RAM
<usvi>
alright, thanks
frieder has quit [Remote host closed the connection]
jmd has quit [Remote host closed the connection]
<usvi>
does this affect all ipks? not just image?
<usvi>
I think I'm too afraid to change it
sugoi has quit [Ping timeout: 252 seconds]
sugoi has joined #yocto
zkrx has quit []
sugoi has quit [Ping timeout: 252 seconds]
zkrx has joined #yocto
Kubu_work has quit [Quit: Leaving.]
Haxxa has quit [Quit: Haxxa flies away.]
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
Haxxa has joined #yocto
gsalazar has quit [Remote host closed the connection]
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
florian_kc is now known as florian
Guest13 has quit [Quit: Client closed]
<khem>
it will only affect build time
<khem>
ipks wont changes
amitk_ has quit [Ping timeout: 260 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP>
usvi: you could set XZ_THREADS:pn-<imagename> = "xx" if you wanted to make it image specific. Setting it system wide should be ok though
prabhakalad has quit [Ping timeout: 265 seconds]
prabhakalad has joined #yocto
<halstead>
RP: debian12-vk-4 passed all tests after a reboot. Several successful passes. I'm going to put it back in the pool and see if the autobuilder can knock it over again.
kleist has joined #yocto
agrace has joined #yocto
<RP>
halstead: that was the slow disk one?
<RP>
halstead: I guess we can run some builds and see...
<halstead>
RP: Yes. But the disks performed perfectly in testing.
<RP>
halstead: weird. I guess we see what happens going forward
<RP>
halstead: there is a master-next build we can run. I wondered if we should stop mingw on ubuntu 2404 and 2410 until JPEW has a chance to look into it?
<halstead>
RP: I think so.
<halstead>
I'll do that now.
<RP>
halstead: do you want to do it or should I? :)
<RP>
halstead: thanks :)
<halstead>
RP: Done.
<RP>
halstead: great. Should I run master-next?
<RP>
halstead: did you tweak the ubuntu userns issue?
<halstead>
RP: I have on all 24.04 workers and the 24.10 worker.
<RP>
halstead: great, we should be good to go then
<halstead>
RP: I went with the sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 approach instead of changing the glob thought. Hopefully that's alright.
<RP>
halstead: I replied to your emaim but yes, totally fine
kleist has quit [Quit: WeeChat 4.1.1]
<halstead>
RP: I force-reloaded and your reply popped up. Sorry about that.
kleist has joined #yocto
<RP>
halstead: build away. Hoping for green in this one