| *** Guest33 <Guest33!~Guest62@host-80-41-77-253.as13285.net> has quit IRC (Quit: Client closed) | 00:24 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Remote host closed the connection) | 00:32 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 00:34 | |
| *** kevinrowland <kevinrowland!~kevinrowl@130.41.226.131> has quit IRC (Quit: Client closed) | 00:41 | |
| *** davidinux <davidinux!~davidinux@45.11.82.203> has quit IRC (Ping timeout: 240 seconds) | 01:03 | |
| *** davidinux <davidinux!~davidinux@45.11.82.203> has joined #yocto | 01:06 | |
| *** emdevt <emdevt!~emdevt@2001:999:489:414f:5d52:8deb:11c2:fd50> has joined #yocto | 01:09 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 01:09 | |
| *** zhmylove <zhmylove!~zhmylove@178.252.127.211> 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@208.111.77.233> has quit IRC (Quit: Leaving) | 01:33 | |
| *** emdevt__ <emdevt__!~emdevt@85-76-104-119-nat.elisa-mobile.fi> has joined #yocto | 01:34 | |
| *** emdevt <emdevt!~emdevt@2001:999:489:414f:5d52:8deb:11c2:fd50> has quit IRC (Ping timeout: 245 seconds) | 01:37 | |
| *** paulg <paulg!~paulg@23-233-30-231.cpe.pppoe.ca> has quit IRC (Ping timeout: 258 seconds) | 01:44 | |
| *** paulg <paulg!~paulg@198-84-237-91.cpe.teksavvy.com> has joined #yocto | 01:45 | |
| *** ablu <ablu!~m-bfyrfh@p54b3c291.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 248 seconds) | 01:52 | |
| *** ablu <ablu!~m-bfyrfh@p4fdb2284.dip0.t-ipconnect.de> has joined #yocto | 01: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 #yocto | 01:54 | |
| *** shakta <shakta!~shakta@2601:441:8081:6220:8d2:25cd:458:ac8e> has joined #yocto | 01:55 | |
| shakta | Why does kernel image w/ bundled initramfs image not get deployed to rootfs automatically? | 01:58 |
|---|---|---|
| shakta | The 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__!~emdevt@85-76-104-119-nat.elisa-mobile.fi> has quit IRC (Remote host closed the connection) | 02:05 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6521:2300:2ce:39ff:fecf:efcd> has joined #yocto | 02: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 #yocto | 03:05 | |
| *** shakta <shakta!~shakta@2601:441:8081:6220:8d2:25cd:458:ac8e> has quit IRC (Quit: Client closed) | 03:17 | |
| *** amitk <amitk!~amit@58.84.61.152> has joined #yocto | 04: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 #yocto | 04:15 | |
| *** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto | 04:18 | |
| *** davidinux <davidinux!~davidinux@45.11.82.203> has quit IRC (Ping timeout: 255 seconds) | 05:22 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 05:23 | |
| *** davidinux <davidinux!~davidinux@45.11.82.206> has joined #yocto | 05:24 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 05:30 | |
| *** ablu <ablu!~m-bfyrfh@p4fdb2284.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection) | 05:51 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto | 05:51 | |
| *** sakman <sakman!~sakman@208.111.77.233> has joined #yocto | 05:52 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 05:58 | |
| *** olani <olani!~olani@wlan-gw.se.axis.com> 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@58.84.60.38> has joined #yocto | 06:16 | |
| *** Saur <Saur!~pkj@nebula.axis.com> has quit IRC (Ping timeout: 240 seconds) | 06:18 | |
| *** amitk <amitk!~amit@58.84.61.152> has quit IRC (Ping timeout: 255 seconds) | 06:18 | |
| *** linfax_ <linfax_!~linfax@eumail.topcon.com> has joined #yocto | 06:20 | |
| *** linfax_ <linfax_!~linfax@eumail.topcon.com> has quit IRC (Quit: Leaving) | 06:38 | |
| *** Max1980 <Max1980!~Max1980@host-80-104-213-226.retail.telecomitalia.it> has joined #yocto | 06:38 | |
| *** linfax <linfax!~linfax@eumail.topcon.com> has joined #yocto | 06:42 | |
| Max1980 | goodmorning all! sorry for bothering....is 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 #yocto | 06:44 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 06:45 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 06:45 | |
| * RP doesn't know whether to put rc1 of 4.3 through QA or to try again with different kernel fixes | 06:51 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 06:59 | |
| ablu | Max1980: 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 |
| mcfrisk | RP: at least I have not seen the tty bug on real HW, or even on qemu with our setup | 07:02 |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:02 | |
| ablu | Max1980: 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!~pab@163.sub-75-236-23.myvzw.com> has quit IRC (Ping timeout: 260 seconds) | 07:05 | |
| *** rfuentess <rfuentess!~rfuentess@2a01cb09d02177b01a441349bd1215e0.ipv6.abo.wanadoo.fr> has joined #yocto | 07:06 | |
| *** grma <grma!~gruberm@89-41-133-247.static.kufnet.at> has joined #yocto | 07:13 | |
| *** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has joined #yocto | 07:17 | |
| RP | mcfrisk: it seems to be more infrequent after some of the changes | 07:18 |
| *** pabigot <pabigot!~pab@163.sub-75-236-23.myvzw.com> has joined #yocto | 07:20 | |
| *** zpfvo <zpfvo!~fvo@i59F5CFC3.versanet.de> has joined #yocto | 07:25 | |
| *** Daanct12 <Daanct12!~danct12@user/danct12> has joined #yocto | 07:29 | |
| *** zpfvo <zpfvo!~fvo@i59F5CFC3.versanet.de> has quit IRC (Ping timeout: 255 seconds) | 07:31 | |
| mcfrisk | RP: 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 stack | 07:32 |
| *** rfuentess <rfuentess!~rfuentess@2a01cb09d02177b01a441349bd1215e0.ipv6.abo.wanadoo.fr> has quit IRC (Read error: Connection reset by peer) | 07:32 | |
| *** rfuentess <rfuentess!~rfuentess@2a01cb09d02177b0ad149a534992f55f.ipv6.abo.wanadoo.fr> has joined #yocto | 07:34 | |
| *** mckoan|away is now known as mckoan | 07:34 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 07:35 | |
| mcfrisk | if 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 |
| LetoThe2nd | yo dudX | 07:39 |
| mckoan | LetoThe2nd: 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 partitions | 07:43 |
| Max1980 | @ablu: to answer your question: no TPM | 07:44 |
| *** zpfvo <zpfvo!~fvo@i59F5CFC3.versanet.de> has joined #yocto | 07:44 | |
| *** Kubu_work <Kubu_work!~kubu@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 07:48 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 07:50 | |
| mcfrisk | Max1980: 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@185.178.95.233> has joined #yocto | 07:50 | |
| ablu | Max1980: 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 |
| ablu | The Yocto integrations that I am aware of mostly depend on TPM. | 07:54 |
| ablu | Of 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 |
| mckoan | Max1980: you can't do that in a completely trusted way with a RPI (Broadcom) | 07:54 |
| *** pretec <pretec!~Matthias@ip-109-40-240-223.web.vodafone.de> has joined #yocto | 07:57 | |
| LetoThe2nd | Max1980: 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 |
| Max1980 | let's say that: ok it's not perfectly secure...but the cybs teams says that "it's ok" xD | 08:02 |
| *** florian_kc is now known as florian | 08:02 | |
| Max1980 | i've read about doing secure boot ..c.reating a fitImage...but actually there's not so much documentations | 08:03 |
| Max1980 | or maybe i haven't found | 08:04 |
| LetoThe2nd | Max1980: 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 |
| LetoThe2nd | Max1980: same story for secure boot, how do you verify the first loader? | 08:04 |
| LetoThe2nd | Max1980: 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 |
| LetoThe2nd | upon request, that is. | 08:05 |
| Max1980 | so the only way to do it in a "secure way" is using TPM. just for tryin without...how can i modify my local.conf to test it ? | 08:11 |
| mckoan | Max1980: it's a sensitive subject we can't discuss details publicly | 08:13 |
| Max1980 | okkey ...tnx anyway for your answers! | 08:15 |
| ablu | Max1980: 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 |
| ablu | 100% ACK to that doing this in production is a bad idea of course. | 08:18 |
| *** bhstalel <bhstalel!~bhstalel@193.95.99.58> has joined #yocto | 08:19 | |
| *** olani <olani!~olani@wlan-gw.se.axis.com> has joined #yocto | 08:20 | |
| *** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has quit IRC (Ping timeout: 255 seconds) | 08:20 | |
| mckoan | Max1980: however the most secure solution you have with a RPI is an HW module: https://www.zymbit.com/ | 08:24 |
| *** varjag <varjag!~user@188.95.241.196> has joined #yocto | 08:25 | |
| dvergatal | Max1980: if your using arm platform u can always use arm trust zone | 08:26 |
| dvergatal | instead of tpm | 08:26 |
| Max1980 | ablu: ok i'll try to read somthing | 08:26 |
| dvergatal | but on RPI trust zone is not secure at all | 08:26 |
| Max1980 | mckoan: yep i know...but as i said, it's only for testing | 08:26 |
| Max1980 | dvergatal: ok ..there's something on that topic on the yocto docs ? | 08:28 |
| dvergatal | Max1980: read on op-tee documentation | 08:29 |
| dvergatal | https://optee.readthedocs.io/en/latest/building/devices/rpi3.html | 08:29 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 08:31 | |
| *** pidge <pidge!~pidge@194.110.145.184> has quit IRC (Ping timeout: 240 seconds) | 08:32 | |
| ablu | Looks like https://trs.readthedocs.io/en/latest/firmware/requirements/supported_platforms.html lists the RPI4 as supported with TPM over SPI. Maybe the same works for RPI3 | 08:33 |
| dvergatal | it supports but it is still not protected | 08:34 |
| dvergatal | just a PoC | 08:34 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 08:34 | |
| dvergatal | than he has to do this https://optee.readthedocs.io/en/latest/architecture/secure_boot.html | 08:35 |
| dvergatal | with the usage of mbedtls tee binary | 08:35 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 08:36 | |
| dvergatal | generally this mbed tls tee blob is already being build within op-tee source code | 08:36 |
| *** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has joined #yocto | 08:40 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 08:45 | |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has quit IRC (Read error: Connection reset by peer) | 08:47 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 08:49 | |
| Max1980 | thank you all guys :* | 08:50 |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has joined #yocto | 08:56 | |
| LetoThe2nd | Max1980: 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!~user@dude03.red.stw.pengutronix.de> has quit IRC (Remote host closed the connection) | 08:58 | |
| LetoThe2nd | working 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!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto | 09:01 | |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has joined #yocto | 09:07 | |
| neverpanic | My 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!~pkj@nebula.axis.com> has joined #yocto | 09:17 | |
| neverpanic | Encryption 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 |
| neverpanic | They can't if you use signatures. | 09:19 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:20 | |
| *** Danct12 <Danct12!~danct12@user/danct12> has quit IRC (Ping timeout: 258 seconds) | 09:31 | |
| LetoThe2nd | neverpanic: 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@109.176.155.130> has quit IRC (Quit: Connection closed) | 09:33 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 09:35 | |
| LetoThe2nd | for 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 |
| qschulz | encryption is IP protection when the device is powered off basically, not much more than this | 09:41 |
| *** bhstalel <bhstalel!~bhstalel@193.95.99.58> has quit IRC (Ping timeout: 245 seconds) | 09:42 | |
| Max1980 | neverpanic: signing with dm-verity it means that everything is "readable" but you can't use any file that isn't signed? | 09:42 |
| neverpanic | Well, 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 |
| neverpanic | Depending on how you set it up | 09:43 |
| Max1980 | uhm..not applicable to my case | 09:44 |
| LetoThe2nd | qschulz: well there are definitely some more advanced techniques available, but yeah - rootfs encryption is mostly that. | 09:44 |
| Max1980 | i have to try with encryption... | 09:44 |
| neverpanic | Also 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 |
| neverpanic | All that encryption doesn't stop somebody who already has code execution on the running device. | 09:45 |
| Max1980 | the time "that guy" has this device in his hand....it's over :) | 09:46 |
| neverpanic | So you're really just trying to protect your images while they are being transferred to the device? | 09:47 |
| qschulz | I mean, there's nothing 100% secure so.. in a way, yes. | 09:47 |
| qschulz | threat model and everything, but that LetoThe2nd has already said a few words about | 09: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 #yocto | 09:59 | |
| *** Rich_1234 <Rich_1234!~Rich_1234@109.176.155.130> has joined #yocto | 10:03 | |
| landgraf | is 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!~pab@163.sub-75-236-23.myvzw.com> has quit IRC (Ping timeout: 246 seconds) | 10:18 | |
| LetoThe2nd | landgraf: asking halstead for a shopping list and rebuilding the autobuilder locally is probably the most documented and easiest way :-) | 10:18 |
| landgraf | LetoThe2nd: s/easy/cheap/ then :D | 10:19 |
| LetoThe2nd | landgraf: how böring. | 10:22 |
| landgraf | LetoThe2nd: I can't afford second expensive hobby :-) | 10:23 |
| LetoThe2nd | landgraf: still böring. | 10:24 |
| landgraf | found this https://wiki.yoctoproject.org/wiki/AutoBuilder_Cluster_Setup will see how up to date it is :) | 10:26 |
| *** Rich_1234 <Rich_1234!~Rich_1234@109.176.155.130> has quit IRC (Quit: Connection closed) | 10:33 | |
| *** pabigot <pabigot!~pab@163.sub-75-236-23.myvzw.com> has joined #yocto | 10:34 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 10:38 | |
| *** bhstalel <bhstalel!~bhstalel@196.203.207.106> has joined #yocto | 10:38 | |
| bhstalel | How 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 list | 10:41 |
| qschulz | bhstalel: look into openembedded-core git repo, if what you change is in there, send it to OE-Core | 10:41 |
| qschulz | https://git.openembedded.org/openembedded-core/ | 10:42 |
| qschulz | bhstalel: 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 |
| ablu | bhstalel: poky's README.md also has a breakdown of which changes to send where. | 10:42 |
| *** mckoan is now known as mckoan|away | 10:43 | |
| bhstalel | qschulz 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 |
| bhstalel | LetoThe2nd Any updates about the Summit ? | 10:45 |
| qschulz | bhstalel: poky is a special case yes | 10:46 |
| *** mbulut <mbulut!~mbulut@ip1f125d2c.dynamic.kabel-deutschland.de> has joined #yocto | 10:48 | |
| LetoThe2nd | bhstalel: we will hopefully finish speaker notifications by the end of this week | 10:49 |
| bhstalel | LetoThe2nd Thanks. | 10:50 |
| *** mbulut <mbulut!~mbulut@ip1f125d2c.dynamic.kabel-deutschland.de> has quit IRC (Client Quit) | 10:50 | |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has quit IRC (Remote host closed the connection) | 10:51 | |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has joined #yocto | 10:51 | |
| *** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Remote host closed the connection) | 10:52 | |
| *** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto | 10:52 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 10:54 | |
| rburton | bhstalel: just remember you never actually send a patch for *poky*. that's a generated repository by glueing together oe-core + bitbake + yocto-docs + meta-yocto | 10:55 |
| rburton | it's absolutely common to grab bitbake + oe-core + BSP layers + your own distro layer and not use poky at all | 10:55 |
| bhstalel | rburton Thanks for the clarification. This helps a lot | 10:57 |
| *** Max1980 <Max1980!~Max1980@host-80-104-213-226.retail.telecomitalia.it> has quit IRC (Remote host closed the connection) | 11:02 | |
| *** paulg <paulg!~paulg@198-84-237-91.cpe.teksavvy.com> has quit IRC (Ping timeout: 255 seconds) | 11:03 | |
| *** paulg <paulg!~paulg@23-233-30-231.cpe.pppoe.ca> has joined #yocto | 11:03 | |
| *** hcg <hcg!~hcg@147.161.246.105> has joined #yocto | 11:19 | |
| *** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has quit IRC (Quit: Leaving) | 11:22 | |
| hcg | Hi, 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 ~5 | 11:24 |
| hcg | minutes | 11:24 |
| rburton | hcg: don't enable the source archive and it won't run at all | 11:26 |
| rburton | you've INHERIT += "archiver" somewhere | 11:26 |
| rburton | (if you're doing development enabling the archiver is a massive waste of time) | 11:28 |
| hcg | I 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 response | 11:29 |
| rburton | absolutely 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!~fvo@i59F5CFC3.versanet.de> has quit IRC (Ping timeout: 252 seconds) | 11:48 | |
| *** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto | 11:48 | |
| *** zpfvo <zpfvo!~fvo@i59f5cfc3.versanet.de> has joined #yocto | 11:48 | |
| *** Rich_1234 <Rich_1234!~Rich_1234@109.176.155.130> has joined #yocto | 11:50 | |
| *** zpfvo <zpfvo!~fvo@i59f5cfc3.versanet.de> has quit IRC (Ping timeout: 255 seconds) | 11:53 | |
| *** zpfvo <zpfvo!~fvo@i59F5CFC3.versanet.de> has joined #yocto | 11:54 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Read error: Connection reset by peer) | 12:09 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 12:10 | |
| LetoThe2nd | rburton: 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@185.178.95.233> has quit IRC (Quit: alessioigor) | 12:20 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 12:21 | |
| *** bhstalel <bhstalel!~bhstalel@196.203.207.106> has quit IRC (Ping timeout: 245 seconds) | 12:33 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> 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@147.161.246.105> has quit IRC (Quit: Client closed) | 12:52 | |
| *** hcg <hcg!~hcg@147.161.246.105> has joined #yocto | 12:53 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 12:54 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 13:01 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 13:01 | |
| *** zpfvo <zpfvo!~fvo@i59F5CFC3.versanet.de> has quit IRC (Ping timeout: 255 seconds) | 13:13 | |
| *** zpfvo <zpfvo!~fvo@i59F5CFC3.versanet.de> has joined #yocto | 13:13 | |
| *** zpfvo <zpfvo!~fvo@i59F5CFC3.versanet.de> has quit IRC (Ping timeout: 252 seconds) | 13:18 | |
| *** zpfvo <zpfvo!~fvo@i59F5CFC3.versanet.de> has joined #yocto | 13:18 | |
| *** bhstalel <bhstalel!~bhstalel@41.225.25.106> has joined #yocto | 13:19 | |
| *** Danct12 <Danct12!~danct12@user/danct12> has joined #yocto | 13:28 | |
| *** xmn <xmn!~xmn@pool-71-105-152-109.nycmny.fios.verizon.net> has joined #yocto | 13:28 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 13:36 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 13:36 | |
| hcg | Recently, in my build environment, I have noticed errors like: | 13:40 |
| hcg | Pseudo log: | 13:40 |
| hcg | path 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 |
| hcg | Setup complete, sending SIGUSR1 to pid 2990189. | 13:41 |
| hcg | I am using a newer release of meta-ti, but I am not sure if that is the cause of the issue | 13:41 |
| *** varjag <varjag!~user@188.95.241.196> has quit IRC (Quit: ERC (IRC client for Emacs 27.1)) | 13:41 | |
| hcg | The 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 operation | 13:43 |
| denix | hcg: 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 |
| hcg | I am using kirkstone 4.0.8 currently | 13:44 |
| denix | yeah, 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 invasive | 13:45 |
| *** bhstalel <bhstalel!~bhstalel@41.225.25.106> has quit IRC (Quit: Client closed) | 13:47 | |
| denix | hcg: 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 clean | 13:48 |
| denix | your-image = core-image-minimal | 13:48 |
| hcg | It always happens when I am building the rootfs, thanks for the tip, I will try this next time it happens | 13:48 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 13:54 | |
| *** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has quit IRC (Ping timeout: 252 seconds) | 13:57 | |
| *** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has joined #yocto | 14:00 | |
| *** bhstalel <bhstalel!~bhstalel@41.225.25.106> has joined #yocto | 14:01 | |
| *** hcg <hcg!~hcg@147.161.246.105> has quit IRC (Quit: Client closed) | 14:18 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 14:21 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 14:22 | |
| *** bhstalel <bhstalel!~bhstalel@41.225.25.106> has quit IRC (Quit: Ping timeout (120 seconds)) | 14:37 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 14:42 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 14:42 | |
| *** hcg <hcg!~hcg@147.161.246.105> has joined #yocto | 14:47 | |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has quit IRC (Quit: vladest) | 14:58 | |
| *** linfax <linfax!~linfax@eumail.topcon.com> has quit IRC (Ping timeout: 240 seconds) | 14:58 | |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has joined #yocto | 14:59 | |
| *** brrm <brrm!~brrm@ip-078-043-203-234.um18.pools.vodafone-ip.de> 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 #yocto | 15:01 | |
| *** brrm <brrm!~brrm@ip-078-043-203-234.um18.pools.vodafone-ip.de> has joined #yocto | 15:03 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 15:17 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 15:17 | |
| *** hcg <hcg!~hcg@147.161.246.105> has quit IRC (Quit: Client closed) | 15:27 | |
| *** sakman <sakman!~sakman@208.111.77.233> has quit IRC (Quit: Leaving) | 15:33 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Remote host closed the connection) | 15:47 | |
| *** kscherer <kscherer!~kscherer@bras-base-toroon020aw-grc-25-76-71-129-107.dsl.bell.ca> has joined #yocto | 15:52 | |
| *** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Quit: Chaser) | 15:55 | |
| *** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 240 seconds) | 16:01 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:01 | |
| *** Kubu_work <Kubu_work!~kubu@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC (Quit: Leaving.) | 16:01 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 16:02 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 16:03 | |
| *** RobertBerger <RobertBerger!~rber|res@089144200221.atnat0009.highway.a1.net> has joined #yocto | 16:05 | |
| *** rber__ <rber__!~rber|res@089144200221.atnat0009.highway.a1.net> has quit IRC (Read error: Connection reset by peer) | 16:05 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 255 seconds) | 16:06 | |
| *** zpfvo <zpfvo!~fvo@i59F5CFC3.versanet.de> has quit IRC (Remote host closed the connection) | 16:09 | |
| *** frieder <frieder!~frieder@2001:9e8:93ac:8f81::1b2e> has joined #yocto | 16:17 | |
| *** rfuentess <rfuentess!~rfuentess@2a01cb09d02177b0ad149a534992f55f.ipv6.abo.wanadoo.fr> has quit IRC (Remote host closed the connection) | 16:22 | |
| *** zenstoic <zenstoic!uid461840@id-461840.hampstead.irccloud.com> has joined #yocto | 16:29 | |
| *** jmd <jmd!~user@2001:a61:2b5e:7b01:795e:5fc:7902:702c> has joined #yocto | 16:45 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 16:49 | |
| *** florian_kc <florian_kc!~florian@dynamic-092-229-182-103.92.229.pool.telefonica.de> has joined #yocto | 16: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!~florian@dynamic-092-229-182-103.92.229.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 17:17 | |
| *** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto | 17: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 #yocto | 17:36 | |
| *** frieder <frieder!~frieder@i577B91FE.versanet.de> has joined #yocto | 17:44 | |
| *** pretec <pretec!~Matthias@ip-109-40-240-223.web.vodafone.de> has quit IRC (Read error: Connection reset by peer) | 17:56 | |
| *** Guest67 <Guest67!~Guest67@cpef81d0f8974b3-cmf81d0f8974b0.cpe.net.fido.ca> has joined #yocto | 18:04 | |
| Guest67 | hi 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 #yocto | 18:06 | |
| mischief | Guest67: 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 #yocto | 18: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!~Guest67@cpef81d0f8974b3-cmf81d0f8974b0.cpe.net.fido.ca> has quit IRC (*.net *.split) | 18:16 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 18:18 | |
| *** florian_kc <florian_kc!~florian@dynamic-092-229-182-103.92.229.pool.telefonica.de> has joined #yocto | 18:19 | |
| *** frieder <frieder!~frieder@i577B91FE.versanet.de> 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@185.178.95.233> has quit IRC (Quit: alessioigor) | 18:59 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 19:01 | |
| *** Haxxa <Haxxa!~Haxxa@202.65.68.206> has quit IRC (Quit: Haxxa flies away.) | 19:15 | |
| *** Haxxa <Haxxa!~Haxxa@202-65-68-206.ip4.superloop.au> has joined #yocto | 19:20 | |
| *** bhstalel <bhstalel!~bhstalel@197.27.115.232> has joined #yocto | 19:34 | |
| bhstalel | I 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@213.55.240.10> has joined #yocto | 19:50 | |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has quit IRC (Remote host closed the connection) | 19:51 | |
| *** tlwoerner_ <tlwoerner_!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has joined #yocto | 19:51 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 19:56 | |
| *** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has joined #yocto | 19:58 | |
| *** hcg <hcg!~hcg@213.55.240.10> has quit IRC (Quit: Client closed) | 20:00 | |
| *** hcg <hcg!~hcg@213.55.240.10> has joined #yocto | 20:00 | |
| hcg | denix: 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 |
| hcg | as 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 that | 20:06 |
| hcg | is why I mentioned the newer meta-ti. | 20:06 |
| hcg | denix: and I see these errors on probably every 2nd or 3rd build I do | 20:07 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 20:13 | |
| *** zenstoic <zenstoic!uid461840@id-461840.hampstead.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 20:26 | |
| *** bhstalel <bhstalel!~bhstalel@197.27.115.232> has quit IRC (Quit: Client closed) | 20:37 | |
| *** Guest67 <Guest67!~Guest67@cpef81d0f8974b3-cmf81d0f8974b0.cpe.net.fido.ca> has joined #yocto | 20:38 | |
| JaMa | anyone 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 correctly | 20:42 |
| JaMa | see https://lists.openembedded.org/g/openembedded-devel/message/105583 | 20:42 |
| RP | JaMa: 3) is obviously the ideal long term approach. I have no idea how complicated io_uring is | 20:45 |
| RP | JaMa: hmm, do we have to intercept liburing? | 20:46 |
| JaMa | libuv doesn't seem to use liburing | 20:48 |
| * JaMa knows close to nothing about io_uring and libuv, just bisected to this change few hours ago | 20:49 | |
| mischief | that sounds like a lovely world of pain :-) | 20:51 |
| *** Guest67 <Guest67!~Guest67@cpef81d0f8974b3-cmf81d0f8974b0.cpe.net.fido.ca> has quit IRC (Quit: Client closed) | 20:51 | |
| *** speeder <speeder!~speeder__@2001:8a0:dfde:fa00:c886:2f61:1b2d:1486> has joined #yocto | 20:56 | |
| *** drkhsh <drkhsh!~drkhsh@user/drkhsh> has quit IRC (Quit: WeeChat 3.8) | 21:00 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> 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 #yocto | 21:20 | |
| *** behanw <behanw!uid110099@id-110099.uxbridge.irccloud.com> has joined #yocto | 21:24 | |
| RP | JaMa: if it is using the syscalls directly we might not be able to intercept | 21:30 |
| *** olani- <olani-!~olani@83-233-29-102.cust.bredband2.com> has joined #yocto | 21:30 | |
| moto-timo | networkmanager 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-timo | chasing my tail in circles | 21:31 |
| *** olani- <olani-!~olani@83-233-29-102.cust.bredband2.com> 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 #yocto | 21:44 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Ping timeout: 260 seconds) | 21:51 | |
| *** williamh54 <williamh54!~williamh@cpef81d0f8974b3-cmf81d0f8974b0.cpe.net.fido.ca> has joined #yocto | 22:01 | |
| JaMa | it calls syscall() directly with: | 22:05 |
| JaMa | src/unix/linux.c:# define __NR_io_uring_setup 425 | 22:05 |
| JaMa | src/unix/linux.c:# define __NR_io_uring_enter 426 | 22:05 |
| JaMa | src/unix/linux.c:# define __NR_io_uring_register 427 | 22:05 |
| JaMa | before 1.45.0 version it was using syscall() only for __NR_copy_file_range, __NR_statx, __NR_getrandom, | 22:06 |
| *** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 22:07 | |
| *** hcg <hcg!~hcg@213.55.240.10> has quit IRC (Quit: Client closed) | 22:09 | |
| JaMa | we 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 |
| JaMa | with -R | 22:10 |
| RP | JaMa: I can't remember if syscall() is inlined or a glibc function? | 22:10 |
| RP | if 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 intercept | 22:11 |
| *** florian_kc <florian_kc!~florian@dynamic-092-229-182-103.92.229.pool.telefonica.de> has quit IRC (Ping timeout: 258 seconds) | 22:36 | |
| JaMa | nodejs-native/20.8.1/recipe-sysroot-native/usr/bin $ nm node | grep syscall -> U syscall@GLIBC_2.2.5 | 22:41 |
| RP | JaMa: so possible but painful and per arch specific | 22:42 |
| RP | JaMa: https://git.yoctoproject.org/pseudo/tree/ports/linux/pseudo_wrappers.c#n58 | 22:43 |
| RP | JaMa: one way to do it is make the syscall return ENOSYS and force the code to use a fallback | 22:44 |
| JaMa | RP: 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 |
| RP | JaMa: I know all about blocked releases :/ | 22:51 |
| JaMa | yeah, I know you do :( | 22:52 |
| JaMa | FWIW: I've updated the "reproducer" with what your pointers https://github.com/shr-project/com.webos.app.minimal/commit/bd238047c8ce3cd085041d276613396b863213cf 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!~williamh@cpef81d0f8974b3-cmf81d0f8974b0.cpe.net.fido.ca> has quit IRC (Quit: Client closed) | 22:56 | |
| RP | JaMa: looks like a good summary | 22:56 |
| * RP doesn't want to get involved in building nodejs | 22:57 | |
| moto-timo | Just like we were trying to do with Django in meta-python, I honestly think the nodejs release should be on an LTS. https://nodejs.org/en | 23:06 |
| moto-timo | Or at least we should still have an LTS versioned recipe. | 23:06 |
| moto-timo | https://git.openembedded.org/meta-openembedded/commit/meta-python/recipes-devtools/python?id=961755a7bd17f7347f7dd0f2de3d2400a9c36f09 | 23:08 |
| moto-timo | but later commits wiped out that comment and merges happen | 23:08 |
| JaMa | nodejs LTS should move from 18 to 20 in 5 days according to https://github.com/nodejs/release#release-schedule so it's probably good it was merged in nanbield (even with the pain it caused me in last couple weeks) | 23:21 |
| Ch^W | How many gigs of RSS per thread does NodeJS 20 require these days? | 23:21 |
| JaMa | around 2G | 23:22 |
| * Ch^W cringes... | 23:22 | |
| JaMa | if you mean for building it | 23:22 |
| Ch^W | yeah | 23:22 |
| Ch^W | For 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 |
| JaMa | chromium does the same, so on 64t threadripper I'm triggering OOMK with 128G ram if I don't restrict PARALLEL_MAKE a bit | 23:24 |
| JaMa | pressure regulation unfortunatelly doesn't help much with OOMK and also now needs different thresholds for kirkstone and nanbield | 23:25 |
| Ch^W | Yeah, PSI is not a silver bullet. It is an awesome feature, but not a silver bullet. | 23:25 |
| JaMa | it 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 |
| JaMa | as all looks fine until these 2 get scheduled at the same time (which is quite typical in all of my builds) | 23:27 |
| Ch^W | Those lovely progress bars from cmake builds are just divine. Almost worth wrapping my head around yet another build tool. | 23:28 |
| JaMa | wrap 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@58.84.60.38> has quit IRC (Ping timeout: 255 seconds) | 23:49 | |
| moto-timo | JaMa: I guarantee that 99% of all YP consumers are not ready for even NodeJS 18. but hey, who's counting | 23:51 |
| moto-timo | Anyone that complains about any build system should be required to use bazel. | 23:51 |
| moto-timo | NodeJS 18 end of life is not until 2025-04-03, so "99%" of all (embedded product) users will not switch yet https://github.com/nodejs/release#release-schedule | 23:54 |
| JaMa | and 99% unfortunately aren't on nanbield, nor will be anytime soon | 23:55 |
| moto-timo | still getting paid to move people to dunfell, so yep | 23:56 |
| moto-timo | I don't see any News saying 20 is an LTS release... sigh | 23:57 |
| JaMa | I've seen it somewhere and that page says it it's active LTS in 5 days | 23:57 |
| JaMa | https://nodejs.org/en/blog/announcements/v20-release-announce "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 |
| moto-timo | https://nodejs.org/en/blog/announcements/v21-release-announce | 23:59 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!