Wednesday, 2023-10-18

*** Guest33 <Guest33!> has quit IRC (Quit: Client closed)00:24
*** qschulz <qschulz!> has quit IRC (Remote host closed the connection)00:32
*** qschulz <qschulz!> has joined #yocto00:34
*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Quit: Client closed)00:41
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 240 seconds)01:03
*** davidinux <davidinux!~davidinux@> has joined #yocto01:06
*** emdevt <emdevt!~emdevt@2001:999:489:414f:5d52:8deb:11c2:fd50> has joined #yocto01:09
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)01:09
*** zhmylove <zhmylove!~zhmylove@> has quit IRC (Quit: Leaving)01:12
*** shakta <shakta!~shakta@2601:441:8081:6220:8d2:25cd:458:ac8e> has quit IRC (Quit: Client closed)01:30
*** sakman <sakman!~sakman@> has quit IRC (Quit: Leaving)01:33
*** emdevt__ <emdevt__!> has joined #yocto01:34
*** emdevt <emdevt!~emdevt@2001:999:489:414f:5d52:8deb:11c2:fd50> has quit IRC (Ping timeout: 245 seconds)01:37
*** paulg <paulg!> has quit IRC (Ping timeout: 258 seconds)01:44
*** paulg <paulg!> has joined #yocto01:45
*** ablu <ablu!> has quit IRC (Ping timeout: 248 seconds)01:52
*** ablu <ablu!> has joined #yocto01:53
*** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has quit IRC (Remote host closed the connection)01:54
*** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has joined #yocto01:54
*** shakta <shakta!~shakta@2601:441:8081:6220:8d2:25cd:458:ac8e> has joined #yocto01:55
shaktaWhy does kernel image w/ bundled initramfs image not get deployed to rootfs automatically?01:58
shaktaThe initramfs bundling task in poky is added after install before deploy. It does not get included in the *package* build directories but the kernel with out the bundled initramfs does.02:04
*** jclsn <jclsn!~jclsn@2a04:4540:650c:5800:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 255 seconds)02:04
*** emdevt__ <emdevt__!> has quit IRC (Remote host closed the connection)02:05
*** jclsn <jclsn!~jclsn@2a04:4540:6521:2300:2ce:39ff:fecf:efcd> has joined #yocto02:06
*** jclsn <jclsn!~jclsn@2a04:4540:6521:2300:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 252 seconds)03:03
*** jclsn <jclsn!~jclsn@2a04:4540:6531:d200:2ce:39ff:fecf:efcd> has joined #yocto03:05
*** shakta <shakta!~shakta@2601:441:8081:6220:8d2:25cd:458:ac8e> has quit IRC (Quit: Client closed)03:17
*** amitk <amitk!~amit@> has joined #yocto04:09
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Ping timeout: 260 seconds)04:10
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 260 seconds)04:14
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto04:15
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto04:18
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 255 seconds)05:22
*** rob_w <rob_w!> has joined #yocto05:23
*** davidinux <davidinux!~davidinux@> has joined #yocto05:24
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:30
*** ablu <ablu!> has quit IRC (Remote host closed the connection)05:51
*** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto05:51
*** sakman <sakman!~sakman@> has joined #yocto05:52
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto05:58
*** olani <olani!> has quit IRC (Ping timeout: 255 seconds)06:11
*** xmn <xmn!~xmn@2600:4040:9390:8c00:1c25:e65e:1c10:5d7c> has quit IRC (Ping timeout: 245 seconds)06:14
*** amitk_ <amitk_!~amit@> has joined #yocto06:16
*** Saur <Saur!> has quit IRC (Ping timeout: 240 seconds)06:18
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 255 seconds)06:18
*** linfax_ <linfax_!> has joined #yocto06:20
*** linfax_ <linfax_!> has quit IRC (Quit: Leaving)06:38
*** Max1980 <Max1980!> has joined #yocto06:38
*** linfax <linfax!> has joined #yocto06:42
Max1980goodmorning all! sorry for there any guide on how enable encryption on filesystem during yocto building ?06:42
*** mvlad <mvlad!~mvlad@2a02:2f05:810c:2f00:7656:3cff:fe3f:7ce9> has joined #yocto06:44
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)06:45
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:45
* RP doesn't know whether to put rc1 of 4.3 through QA or to try again with different kernel fixes06:51
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)06:59
abluMax1980: There are a lot of options here... Do you want a per-device key? Same key across all devices? Do you have a TPM?07:01
mcfriskRP: at least I have not seen the tty bug on real HW, or even on qemu with our setup07:02
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:02
abluMax1980: For TRS (Trusted Reference Stack) we do it from initramfs with a per-device key derived from the TPM.07:03
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)07:04
*** pabigot <pabigot!> has quit IRC (Ping timeout: 260 seconds)07:05
*** rfuentess <rfuentess!> has joined #yocto07:06
*** grma <grma!> has joined #yocto07:13
*** frieder <frieder!> has joined #yocto07:17
RPmcfrisk: it seems to be more infrequent after some of the changes07:18
*** pabigot <pabigot!> has joined #yocto07:20
*** zpfvo <zpfvo!> has joined #yocto07:25
*** Daanct12 <Daanct12!~danct12@user/danct12> has joined #yocto07:29
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 255 seconds)07:31
mcfriskRP: yep. it is sad that only yocto qemu test env triggers these. in previous projects we had dedicated machines for virtual tests, and kept a close eye on the load there. the autobuilders are really tough on qemu and SW stack07:32
*** rfuentess <rfuentess!> has quit IRC (Read error: Connection reset by peer)07:32
*** rfuentess <rfuentess!> has joined #yocto07:34
*** mckoan|away is now known as mckoan07:34
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:35
mcfriskif kernel tty layer has regressions, that should be a problem for all BSP vendors, not just yocto upstream maintainers. if you could afford it, I'd try to shield the qemu test jobs from each other and give them more CPU, memory etc resources. This would cost either time or more resources/machines though, but that's better than burning maintainers out with all the races and odd errors..07:37
LetoThe2ndyo dudX07:39
mckoanLetoThe2nd: hey!07:41
Max1980@ablu: sorry for late response. I've a custom rpi3 image conf for a custom board with a CM3 module onboard. The eMMC contains 4 partitions ( boot, 2 rootfs, opt ). i need to encrypt all 4 partitions07:43
Max1980@ablu: to answer your question: no TPM07:44
*** zpfvo <zpfvo!> has joined #yocto07:44
*** Kubu_work <Kubu_work!> has joined #yocto07:48
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)07:50
mcfriskMax1980: encryption just moves the problem elsewhere. Where is the key and how secure is that, e.g. secure boot...? meta-security and meta-secure-core have several building blocks but maybe not full solutions because those may depend on SoC specific secure boot magic.07:50
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:50
abluMax1980: For unattended boot, you probably want a TPM. Either from hardware or from software (via TrustZone). That said, RPI does not provide the necessary memory isolation for TrustZone.07:54
abluThe Yocto integrations that I am aware of mostly depend on TPM.07:54
abluOf course nothing stops you from just generating a partition guarded by a compile-time key. You just need someone at the machine to enter it at boot.07:54
mckoanMax1980: you can't do that in a completely trusted way with a RPI (Broadcom)07:54
*** pretec <pretec!> has joined #yocto07:57
LetoThe2ndMax1980: plus, encryption at scale requires some form of PKI plus key management, a manufacturing/provisioning process thats fit for it, and so on, and so on. It can be done, but as mckoan already pointed out - without any secure HW anchor of trust, it is relatively m00t.08:01
Max1980let's say that: ok it's not perfectly secure...but the cybs teams says that "it's ok" xD08:02
*** florian_kc is now known as florian08:02
Max1980i've read about doing secure boot ..c.reating a fitImage...but actually there's not so much documentations08:03
Max1980or maybe i haven't found08:04
LetoThe2ndMax1980: if your cyb team is happy with the form of security that can be broken by just attaching a serial cable and accessing the u-boot terminal (because thats effectively what you're saying), then you should severely question their competence, at least for embedded devices.08:04
LetoThe2ndMax1980: same story for secure boot, how do you verify the first loader?08:04
LetoThe2ndMax1980: and even legally speaking, if you're shipping anything GPLv3 then you are legally required to give your customers a documented way of changing the software on the device.08:05
LetoThe2ndupon request, that is.08:05
Max1980so the only way to do it in a "secure way" is using TPM. just for tryin can i modify my local.conf to test it ?08:11
mckoanMax1980: it's a sensitive subject we can't discuss details publicly08:13
Max1980okkey ...tnx anyway for your answers!08:15
abluMax1980: If you do not know where to start, maybe look into systemd-cryptenroll and friends. Support in Yocto is a bit rocky, but it also has supports non-TPM backed keys.08:18
ablu100% ACK to that doing this in production is a bad idea of course.08:18
*** bhstalel <bhstalel!~bhstalel@> has joined #yocto08:19
*** olani <olani!> has joined #yocto08:20
*** frieder <frieder!> has quit IRC (Ping timeout: 255 seconds)08:20
mckoanMax1980: however the most secure solution you have with a RPI is an HW module:
*** varjag <varjag!~user@> has joined #yocto08:25
dvergatalMax1980: if your using arm platform u can always use arm trust zone08:26
dvergatalinstead of tpm08:26
Max1980ablu: ok i'll try to read somthing08:26
dvergatalbut on RPI trust zone is not secure at all08:26
Max1980mckoan: yep i know...but as i said, it's only for testing08:26
Max1980dvergatal: ok ..there's something on that topic on the yocto docs ?08:28
dvergatalMax1980: read on op-tee documentation08:29
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)08:31
*** pidge <pidge!~pidge@> has quit IRC (Ping timeout: 240 seconds)08:32
abluLooks like lists the RPI4 as supported with TPM over SPI. Maybe the same works for RPI308:33
dvergatalit supports but it is still not protected08:34
dvergataljust a PoC08:34
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto08:34
dvergatalthan he has to do this
dvergatalwith the usage of mbedtls tee binary08:35
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto08:36
dvergatalgenerally this mbed tls tee blob is already being build within op-tee source code08:36
*** frieder <frieder!> has joined #yocto08:40
*** prabhakarlad <prabhakarlad!> has joined #yocto08:45
*** OnkelUlla <OnkelUlla!> has quit IRC (Read error: Connection reset by peer)08:47
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)08:49
Max1980thank you all guys :*08:50
*** OnkelUlla <OnkelUlla!> has joined #yocto08:56
LetoThe2ndMax1980: and as you mentioned 2x rootfs, I guess you are using a form of A/B update. Next step, think about which things are encrypted where, by which key, how they are transported, how to deal with per-device keys, rotation, etc. pp.08:58
*** OnkelUlla <OnkelUlla!> has quit IRC (Remote host closed the connection)08:58
LetoThe2ndworking for an OTA provider, my experience is "encrypting the rootfs" is usually a checkbox requirement for some department, but they hardly are aware of it being about 5% of the whole story. possibly even less.08:59
*** ptsneves <ptsneves!> has joined #yocto09:01
*** OnkelUlla <OnkelUlla!> has joined #yocto09:07
neverpanicMy guess is that a signature over the rootfs (e.g. using dm-verity) would in most cases be better than actually encrypting it.09:16
*** Saur <Saur!> has joined #yocto09:17
neverpanicEncryption isn't tamper-protection, but many people assume that it is. If you use AES-XTS, attackers can still flip bits in your rootfs.09:18
neverpanicThey can't if you use signatures.09:19
*** florian_kc <florian_kc!> has joined #yocto09:20
*** Danct12 <Danct12!~danct12@user/danct12> has quit IRC (Ping timeout: 258 seconds)09:31
LetoThe2ndneverpanic: but..but...BUT...IT WILL HIDE MY SECRETS! NOBODY CAN SEE MY GLIBC!09:32
LetoThe2nd(if you spotted hints of irony in the above post, rest assured, it is completely unintentional ;-) )09:32
*** Rich_1234 <Rich_1234!~Rich_1234@> has quit IRC (Quit: Connection closed)09:33
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)09:35
LetoThe2ndfor those who wonder: my take on things is to not just use encryption blindly "because it is secure", but to understand the requirements and processes first, build a threat model, and then choose mitigations accordingly. this *can* mean rootfs encryption, but in most cases it actually does *not* in my experience.09:36
qschulzencryption is IP protection when the device is powered off basically, not much more than this09:41
*** bhstalel <bhstalel!~bhstalel@> has quit IRC (Ping timeout: 245 seconds)09:42
Max1980neverpanic: signing with dm-verity it means that everything is "readable" but you can't use any file that isn't signed?09:42
neverpanicWell, with dm-verity you have a choice, either attempting to read files that have been tampered will fail with an error, or the system will reset.09:43
neverpanicDepending on how you set it up09:43
Max1980uhm..not applicable to my case09:44
LetoThe2ndqschulz: well there are definitely some more advanced techniques available, but yeah - rootfs encryption is mostly that.09:44
Max1980i have to try with encryption...09:44
neverpanicAlso what qschulz is saying. If you don't have a strategy to quickly address CVEs to prevent attackers from gaining code execution on your device, don't bother with rootfs encryption, because whatever you *think* you are protecting on there, you're probably failing at it.09:45
neverpanicAll that encryption doesn't stop somebody who already has code execution on the running device.09:45
Max1980the time "that guy" has this device in his's over :)09:46
neverpanicSo you're really just trying to protect your images while they are being transferred to the device?09:47
qschulzI mean, there's nothing 100% secure so.. in a way, yes.09:47
qschulzthreat model and everything, but that LetoThe2nd has already said a few words about09:47
*** mihai <mihai!~mihai@user/mihai> has quit IRC (Quit: Leaving)09:55
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 258 seconds)09:58
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto09:59
*** Rich_1234 <Rich_1234!~Rich_1234@> has joined #yocto10:03
landgrafis there documented (and ideally easy) way to run tests in autobuilder-like environment? My patchset causes test failures in autobuilder but same test is passed locally and I'd like to debug this.10:14
*** pabigot <pabigot!> has quit IRC (Ping timeout: 246 seconds)10:18
LetoThe2ndlandgraf: asking halstead for a shopping list and rebuilding the autobuilder locally is probably the most documented and easiest way :-)10:18
landgrafLetoThe2nd: s/easy/cheap/ then :D10:19
LetoThe2ndlandgraf: how böring.10:22
landgrafLetoThe2nd: I can't afford second expensive hobby :-)10:23
LetoThe2ndlandgraf: still böring.10:24
landgraffound this will see how up to date it is :)10:26
*** Rich_1234 <Rich_1234!~Rich_1234@> has quit IRC (Quit: Connection closed)10:33
*** pabigot <pabigot!> has joined #yocto10:34
*** tnovotny <tnovotny!> has joined #yocto10:38
*** bhstalel <bhstalel!~bhstalel@> has joined #yocto10:38
bhstalelHow do I distinguish between patches for oe-core and poky ? I sometimes send patches to poky and it should be sent to oe-core, I thought every change in poky project is related to poky mailing list10:41
qschulzbhstalel: look into openembedded-core git repo, if what you change is in there, send it to OE-Core10:41
qschulzbhstalel: could you also please use -v X when using git format-patch or git send-email so we know which version of the patch you sent is the latest (it's not that uncommon to have people answer to older versions of the patchsets)10:42
ablubhstalel: poky's also has a breakdown of which changes to send where.10:42
*** mckoan is now known as mckoan|away10:43
bhstalelqschulz Now I see, I get confused because oe-core source is already in poky project, I will keep "-v X" in mind, I did not know about this, I am new to contributions :))10:45
bhstalelLetoThe2nd Any updates about the Summit ?10:45
qschulzbhstalel: poky is a special case yes10:46
*** mbulut <mbulut!> has joined #yocto10:48
LetoThe2ndbhstalel: we will hopefully finish speaker notifications by the end of this week10:49
bhstalelLetoThe2nd Thanks.10:50
*** mbulut <mbulut!> has quit IRC (Client Quit)10:50
*** vladest <vladest!> has quit IRC (Remote host closed the connection)10:51
*** vladest <vladest!> has joined #yocto10:51
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Remote host closed the connection)10:52
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto10:52
*** prabhakarlad <prabhakarlad!> has joined #yocto10:54
rburtonbhstalel: just remember you never actually send a patch for *poky*.  that's a generated repository by glueing together oe-core + bitbake + yocto-docs + meta-yocto10:55
rburtonit's absolutely common to grab bitbake + oe-core + BSP layers + your own distro layer and not use poky at all10:55
bhstalelrburton Thanks for the clarification. This helps a lot10:57
*** Max1980 <Max1980!> has quit IRC (Remote host closed the connection)11:02
*** paulg <paulg!> has quit IRC (Ping timeout: 255 seconds)11:03
*** paulg <paulg!> has joined #yocto11:03
*** hcg <hcg!~hcg@> has joined #yocto11:19
*** frieder <frieder!> has quit IRC (Quit: Leaving)11:22
hcgHi, I wonder if someone could explain what the task do_ar_original does and if it is possible to bypass it under certain circumstances? I am currently doing development in the kernel rebuilding kernel code on a regular basis and the do_ar_original step takes >12 minutes on my build machine, wheeras the actual kernel and modules build takes ~511:24
rburtonhcg: don't enable the source archive and it won't run at all11:26
rburtonyou've INHERIT += "archiver" somewhere11:26
rburton(if you're doing development enabling the archiver is a massive waste of time)11:28
hcgI see someone had enabled it in one of our configuration files - yes, it is a huge waste of time, thank you very much for the quick response11:29
rburtonabsolutely use it for GPL compliance in a release build, but not on every build :)11:30
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Remote host closed the connection)11:42
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 252 seconds)11:48
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto11:48
*** zpfvo <zpfvo!> has joined #yocto11:48
*** Rich_1234 <Rich_1234!~Rich_1234@> has joined #yocto11:50
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 255 seconds)11:53
*** zpfvo <zpfvo!> has joined #yocto11:54
*** tnovotny <tnovotny!> has quit IRC (Read error: Connection reset by peer)12:09
*** tnovotny <tnovotny!> has joined #yocto12:10
LetoThe2ndrburton: wat, you don't release every build? ;-)12:11
*** Daanct12 <Daanct12!~danct12@user/danct12> has quit IRC (Quit: WeeChat 4.0.5)12:17
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)12:20
*** alessioigor <alessioigor!~alessioig@> has joined #yocto12:21
*** bhstalel <bhstalel!~bhstalel@> has quit IRC (Ping timeout: 245 seconds)12:33
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)12:37
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)12:43
*** hcg <hcg!~hcg@> has quit IRC (Quit: Client closed)12:52
*** hcg <hcg!~hcg@> has joined #yocto12:53
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto12:54
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)13:01
*** alessioigor <alessioigor!~alessioig@> has joined #yocto13:01
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 255 seconds)13:13
*** zpfvo <zpfvo!> has joined #yocto13:13
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 252 seconds)13:18
*** zpfvo <zpfvo!> has joined #yocto13:18
*** bhstalel <bhstalel!~bhstalel@> has joined #yocto13:19
*** Danct12 <Danct12!~danct12@user/danct12> has joined #yocto13:28
*** xmn <xmn!> has joined #yocto13:28
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)13:36
*** alessioigor <alessioigor!~alessioig@> has joined #yocto13:36
hcgRecently, in my build environment, I have noticed errors like:13:40
hcgPseudo log:13:40
hcgpath mismatch [1 link]: ino 63719173 db '.../deploy/images/board/core-image-minimal-board-20231018113242.rootfs.wic.xz' req '.../build/tmp/work/board-poky-linux/core-image-minimal/1.0-r0/rootfs/usr/share/zoneinfo/posix/America/Edmonton'.13:40
hcgSetup complete, sending SIGUSR1 to pid 2990189.13:41
hcgI am using a newer release of meta-ti, but I am not sure if that is the cause of the issue13:41
*** varjag <varjag!~user@> has quit IRC (Quit: ERC (IRC client for Emacs 27.1))13:41
hcgThe only way I can then build my image is to completely delete my build directory, but as I have an external download cache and sstate-cache, this is not an expensive operation13:43
denixhcg: that looks like a pseudo abort issue. doesn't seem to be meta-ti related. there have been some fixes for that in master - are you using master or a stable release?13:43
hcgI am using kirkstone 4.0.8 currently13:44
denixyeah, we are also seeing a lot of those in kirkstone... I was wondering if we can backport those fixes from master, but they are not trivial and invasive13:45
*** bhstalel <bhstalel!~bhstalel@> has quit IRC (Quit: Client closed)13:47
denixhcg: btw, are you getting this on consecutive do_rootfs calls? if so, you can try to clean up it in-between. e.g. bitbake your-image -c clean13:48
denixyour-image = core-image-minimal13:48
hcgIt always happens when I am building the rootfs, thanks for the tip, I will try this next time it happens13:48
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)13:54
*** wooosaiiii <wooosaiiii!> has quit IRC (Ping timeout: 252 seconds)13:57
*** Xagen <Xagen!> has joined #yocto14:00
*** bhstalel <bhstalel!~bhstalel@> has joined #yocto14:01
*** hcg <hcg!~hcg@> has quit IRC (Quit: Client closed)14:18
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)14:21
*** alessioigor <alessioigor!~alessioig@> has joined #yocto14:22
*** bhstalel <bhstalel!~bhstalel@> has quit IRC (Quit: Ping timeout (120 seconds))14:37
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)14:42
*** alessioigor <alessioigor!~alessioig@> has joined #yocto14:42
*** hcg <hcg!~hcg@> has joined #yocto14:47
*** vladest <vladest!> has quit IRC (Quit: vladest)14:58
*** linfax <linfax!> has quit IRC (Ping timeout: 240 seconds)14:58
*** vladest <vladest!> has joined #yocto14:59
*** brrm <brrm!> has quit IRC (Ping timeout: 245 seconds)15:00
*** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has quit IRC (Remote host closed the connection)15:01
*** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has joined #yocto15:01
*** brrm <brrm!> has joined #yocto15:03
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)15:17
*** alessioigor <alessioigor!~alessioig@> has joined #yocto15:17
*** hcg <hcg!~hcg@> has quit IRC (Quit: Client closed)15:27
*** sakman <sakman!~sakman@> has quit IRC (Quit: Leaving)15:33
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)15:47
*** kscherer <kscherer!> has joined #yocto15:52
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Quit: Chaser)15:55
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 240 seconds)16:01
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:01
*** Kubu_work <Kubu_work!> has quit IRC (Quit: Leaving.)16:01
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)16:02
*** alessioigor <alessioigor!~alessioig@> has joined #yocto16:03
*** RobertBerger <RobertBerger!~rber|> has joined #yocto16:05
*** rber__ <rber__!~rber|> has quit IRC (Read error: Connection reset by peer)16:05
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 255 seconds)16:06
*** zpfvo <zpfvo!> has quit IRC (Remote host closed the connection)16:09
*** frieder <frieder!~frieder@2001:9e8:93ac:8f81::1b2e> has joined #yocto16:17
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)16:22
*** zenstoic <zenstoic!> has joined #yocto16:29
*** jmd <jmd!~user@2001:a61:2b5e:7b01:795e:5fc:7902:702c> has joined #yocto16:45
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)16:49
*** florian_kc <florian_kc!> has joined #yocto16:56
*** silbe <silbe!~silbe@2a03:4000:20:16f:96de:80ff:fe22:1aaa> has quit IRC (Ping timeout: 264 seconds)17:04
*** jmd <jmd!~user@2001:a61:2b5e:7b01:795e:5fc:7902:702c> has quit IRC (Remote host closed the connection)17:13
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)17:17
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto17:28
*** frieder <frieder!~frieder@2001:9e8:93ac:8f81::1b2e> has quit IRC (Ping timeout: 245 seconds)17:31
*** silbe <silbe!~silbe@2a03:4000:20:16f:96de:80ff:fe22:1aaa> has joined #yocto17:36
*** frieder <frieder!> has joined #yocto17:44
*** pretec <pretec!> has quit IRC (Read error: Connection reset by peer)17:56
*** Guest67 <Guest67!> has joined #yocto18:04
Guest67hi all, I think yocto is fetching tar source files via wget. Is it possible to ask it to use something else like curl instead?18:04
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Remote host closed the connection)18:05
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto18:06
mischiefGuest67: what for?18:06
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Remote host closed the connection)18:13
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto18:14
*** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has quit IRC (*.net *.split)18:16
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (*.net *.split)18:16
*** Guest67 <Guest67!> has quit IRC (*.net *.split)18:16
*** goliath <goliath!~goliath@user/goliath> has joined #yocto18:18
*** florian_kc <florian_kc!> has joined #yocto18:19
*** frieder <frieder!> has quit IRC (Remote host closed the connection)18:45
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Quit: Chaser)18:56
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)18:59
*** alessioigor <alessioigor!~alessioig@> has joined #yocto19:01
*** Haxxa <Haxxa!~Haxxa@> has quit IRC (Quit: Haxxa flies away.)19:15
*** Haxxa <Haxxa!> has joined #yocto19:20
*** bhstalel <bhstalel!~bhstalel@> has joined #yocto19:34
bhstalelI am always wondering if all Yocto developers, architects and stuff are working on other companies or some of them are working in The linux foundation it self ?19:35
*** hcg <hcg!~hcg@> has joined #yocto19:50
*** tlwoerner <tlwoerner!> has quit IRC (Remote host closed the connection)19:51
*** tlwoerner_ <tlwoerner_!> has joined #yocto19:51
*** prabhakarlad <prabhakarlad!> has joined #yocto19:56
*** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has joined #yocto19:58
*** hcg <hcg!~hcg@> has quit IRC (Quit: Client closed)20:00
*** hcg <hcg!~hcg@> has joined #yocto20:00
hcgdenix: I mentioned earlier that I am using a newer release of meta-ti. I am busy working on updating our am625-based product from a release of meta-ti which was from mid November 2022. We also have an am335x product based on the same release and we never ever see this pseudo abort issue, and these builds are done frequently by over 30 developers,20:06
hcgas well as 6 or 7 products doing nightly CI builds. I am currently updating to basically the HEAD of meta-ti and it is only since I started this work that I see these errors. I am still using kirkstone-4.0.8, which is the same as we have for out stable releases of both out am62x and am335x products. I am not sure if it is a co-incidence, but that20:06
hcgis why I mentioned the newer meta-ti.20:06
hcgdenix: and I see these errors on probably every 2nd or 3rd build I do20:07
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)20:13
*** zenstoic <zenstoic!> has quit IRC (Quit: Connection closed for inactivity)20:26
*** bhstalel <bhstalel!~bhstalel@> has quit IRC (Quit: Client closed)20:37
*** Guest67 <Guest67!> has joined #yocto20:38
JaMaanyone with opinion about pseudo and io_uring? nodejs >= 20.3.0 now in meta-oe started to use it and pseudo doesn't intercept it correctly20:42
RPJaMa: 3) is obviously the ideal long term approach. I have no idea how complicated io_uring is20:45
RPJaMa: hmm, do we have to intercept liburing?20:46
JaMalibuv doesn't seem to use liburing20:48
* JaMa knows close to nothing about io_uring and libuv, just bisected to this change few hours ago20:49
mischiefthat sounds like a lovely world of pain :-)20:51
*** Guest67 <Guest67!> has quit IRC (Quit: Client closed)20:51
*** speeder <speeder!~speeder__@2001:8a0:dfde:fa00:c886:2f61:1b2d:1486> has joined #yocto20:56
*** drkhsh <drkhsh!~drkhsh@user/drkhsh> has quit IRC (Quit: WeeChat 3.8)21:00
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)21:02
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)21:08
*** drkhsh <drkhsh!~drkhsh@user/drkhsh> has joined #yocto21:20
*** behanw <behanw!> has joined #yocto21:24
RPJaMa: if it is using the syscalls directly we might not be able to intercept21:30
*** olani- <olani-!> has joined #yocto21:30
moto-timonetworkmanager seems unbuildable on kirkstone and the recipe looks no better in master for this specific issue. The 'vapi' PACKAGECONFIG also requires -Dintrospection=true, but then I think it DEPENDS on glib-2.0 for Gio-2.0 but then Gio-2.0.gir is not found.21:30
moto-timochasing my tail in circles21:31
*** olani- <olani-!> has quit IRC (Ping timeout: 240 seconds)21:42
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 272 seconds)21:42
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto21:44
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Ping timeout: 260 seconds)21:51
*** williamh54 <williamh54!> has joined #yocto22:01
JaMait calls syscall() directly with:22:05
JaMasrc/unix/linux.c:# define __NR_io_uring_setup 42522:05
JaMasrc/unix/linux.c:# define __NR_io_uring_enter 42622:05
JaMasrc/unix/linux.c:# define __NR_io_uring_register 42722:05
JaMabefore 1.45.0 version it was using syscall() only for __NR_copy_file_range, __NR_statx, __NR_getrandom,22:06
*** Xagen <Xagen!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)22:07
*** hcg <hcg!~hcg@> has quit IRC (Quit: Client closed)22:09
JaMawe can also call "chown root:root ${D}" in do_install after calling webpack (that's what I've used now as work around for this)22:09
JaMawith -R22:10
RPJaMa: I can't remember if syscall() is inlined or a glibc function?22:10
RPif it is a glibc function we can intercept and it just going to be painful to intercept and decode the syscall info. If it is inlined, we can't intercept22:11
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 258 seconds)22:36
JaManodejs-native/20.8.1/recipe-sysroot-native/usr/bin $ nm node | grep syscall -> U syscall@GLIBC_2.2.522:41
RPJaMa: so possible but painful and per arch specific22:42
RPJaMa: one way to do it is make the syscall return ENOSYS and force the code to use a fallback22:44
JaMaRP: thanks for pointers, will check pseudo code again after some sleep (in hope that someone else will beat me to it) and after finishing some other nasty bug we have in internal build which is blocking current release :(22:49
RPJaMa: I know all about blocked releases :/22:51
JaMayeah, I know you do :(22:52
JaMaFWIW: I've updated the "reproducer" with what your pointers in the end it might be useful to create some even simpler reproducer just for io_uring (without the rest of huge, slow to build nodejs :))22:55
*** williamh54 <williamh54!> has quit IRC (Quit: Client closed)22:56
RPJaMa: looks like a good summary22:56
* RP doesn't want to get involved in building nodejs22:57
moto-timoJust like we were trying to do with Django in meta-python, I honestly think the nodejs release should be on an LTS.
moto-timoOr at least we should still have an LTS versioned recipe.23:06
moto-timobut later commits wiped out that comment and merges happen23:08
JaManodejs LTS should move from 18 to 20 in 5 days according to so it's probably good it was merged in nanbield (even with the pain it caused me in last couple weeks)23:21
Ch^WHow many gigs of RSS per thread does NodeJS 20 require these days?23:21
JaMaaround 2G23:22
* Ch^W cringes...23:22
JaMaif you mean for building it23:22
Ch^WFor Hardknott allocating 2.5 Gigs of RAM per CPU core seems to be about the right ratio for stuff that includes NodeJS and OpenJDK.23:23
JaMachromium does the same, so on 64t threadripper I'm triggering OOMK with 128G ram if I don't restrict PARALLEL_MAKE a bit23:24
JaMapressure regulation unfortunatelly doesn't help much with OOMK and also now needs different thresholds for kirkstone and nanbield23:25
Ch^WYeah, PSI is not a silver bullet. It is an awesome feature, but not a silver bullet.23:25
JaMait could be much better with PSI-aware job-server for make and ninja, regulating on bitbake task granularity is too coarse (when such tasks are nodejs and chromium do_compile)23:27
JaMaas all looks fine until these 2 get scheduled at the same time (which is quite typical in all of my builds)23:27
Ch^WThose lovely progress bars from cmake builds are just divine. Almost worth wrapping my head around yet another build tool.23:28
JaMawrap it around bazel and you'll gladly return to CMake :)23:29
*** mvlad <mvlad!~mvlad@2a02:2f05:810c:2f00:7656:3cff:fe3f:7ce9> has quit IRC (Remote host closed the connection)23:47
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 255 seconds)23:49
moto-timoJaMa: I guarantee that 99% of all YP consumers are not ready for even NodeJS 18. but hey, who's counting23:51
moto-timoAnyone that complains about any build system should be required to use bazel.23:51
moto-timoNodeJS 18 end of life is not until 2025-04-03, so "99%" of all (embedded product) users will not switch yet
JaMaand 99% unfortunately aren't on nanbield, nor will be anytime soon23:55
moto-timostill getting paid to move people to dunfell, so yep23:56
moto-timoI don't see any News saying 20 is an LTS release... sigh23:57
JaMaI've seen it somewhere and that page says it it's active LTS in 5 days23:57
JaMa "As a reminder, Node.js 20 will enter long-term support (LTS) in October, but until then, it will be the "Current" release for the next six months."23:58
moto-timo"Node.js 21 will replace Node.js 20 as our ‘Current’ release line when Node.js 20 enters long-term support (LTS) later this month. As per the release schedule, Node.js 21 will be ‘Current' release for the next 6 months, until April 2024."23:59

Generated by 2.17.2 by Marius Gedminas - find it at!