| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 00:00 | |
| zeddii | rburton: https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel-next | 00:01 |
|---|---|---|
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 268 seconds) | 00:01 | |
| *** olani <olani!~olani@83-233-29-230.cust.bredband2.com> has joined #yocto | 00:02 | |
| *** florian <florian!~florian@dynamic-093-133-028-113.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 00:05 | |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 00:13 | |
| RP | JPEW: maybe, will sleep on it | 00:26 |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 00:40 | |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 00:40 | |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Quit: Leaving) | 00:43 | |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 00:47 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has joined #yocto | 00:54 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 272 seconds) | 01:01 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 01:06 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has joined #yocto | 01:50 | |
| *** pbsds <pbsds!~pbsds@193.71.241.70> has quit IRC (Quit: Ping timeout (120 seconds)) | 01:55 | |
| *** pbsds <pbsds!~pbsds@193.71.241.70> has joined #yocto | 01:56 | |
| *** moose <moose!~moose@38.99.249.66> has joined #yocto | 02:01 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 268 seconds) | 02:03 | |
| *** money_ <money_!~money@216-131-83-77.nyc.as62651.net> has joined #yocto | 02:05 | |
| moose | Hello, adding fragment.cfg to a bbappend receipt isn't applying these configuration changes. I followed https://docs.yoctoproject.org/kernel-dev/common.html#creating-configuration-fragments. | 02:13 |
| moose | Quick online shows a few threads suggesting to add do_configure_append() cluase in my receipt but none of that is mentioned in yocto official documentation for how to modify kernel config. Any inputs? Thank you. | 02:13 |
| *** RobertBerger <RobertBerger!~rber|res@62-46-92-242.adsl.highway.telekom.at> has joined #yocto | 02:32 | |
| *** rber|res <rber|res!~rber|res@62-46-92-242.adsl.highway.telekom.at> has quit IRC (Ping timeout: 272 seconds) | 02:35 | |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection) | 02:39 | |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 02:39 | |
| *** money_ <money_!~money@216-131-83-77.nyc.as62651.net> has quit IRC (Ping timeout: 256 seconds) | 02:55 | |
| *** money_ <money_!~money@216-131-83-77.nyc.as62651.net> has joined #yocto | 02:59 | |
| *** starblue1 <starblue1!~juergen@dslb-094-220-119-126.094.220.pools.vodafone-ip.de> has quit IRC (Ping timeout: 272 seconds) | 03:03 | |
| *** starblue1 <starblue1!~juergen@dslb-094-220-111-012.094.220.pools.vodafone-ip.de> has joined #yocto | 03:04 | |
| *** money__ <money__!~money@50.239.93.29> has joined #yocto | 03:09 | |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Ping timeout: 272 seconds) | 03:10 | |
| *** money__ <money__!~money@50.239.93.29> has quit IRC (Read error: Connection reset by peer) | 03:11 | |
| *** money__ <money__!~money@50.239.93.29> has joined #yocto | 03:12 | |
| *** money_ <money_!~money@216-131-83-77.nyc.as62651.net> has quit IRC (Ping timeout: 256 seconds) | 03:12 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6539:d600:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 265 seconds) | 03:12 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6524:400:2ce:39ff:fecf:efcd> has joined #yocto | 03:14 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Quit: WeeChat 3.7.1) | 03:25 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 03:25 | |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 03:27 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 03:30 | |
| *** money__ <money__!~money@50.239.93.29> has quit IRC (Read error: Connection reset by peer) | 03:33 | |
| *** money_ <money_!~money@50.239.93.29> has joined #yocto | 03:33 | |
| *** amitk_ <amitk_!~amit@103.208.69.15> has quit IRC (Ping timeout: 246 seconds) | 03:36 | |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Quit: Leaving) | 03:37 | |
| *** amitk <amitk!~amit@103.208.69.15> has joined #yocto | 03:37 | |
| *** money_ <money_!~money@50.239.93.29> has quit IRC (Read error: Connection reset by peer) | 03:41 | |
| *** money__ <money__!~money@50.239.93.29> has joined #yocto | 03:43 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has quit IRC (Ping timeout: 260 seconds) | 03:58 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 03:59 | |
| *** mckoan_ <mckoan_!~marco@host-95-229-48-41.business.telecomitalia.it> has joined #yocto | 04:01 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 260 seconds) | 04:04 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has joined #yocto | 04:04 | |
| *** mckoan|away <mckoan|away!~marco@host-95-229-48-41.business.telecomitalia.it> has quit IRC (Ping timeout: 256 seconds) | 04:04 | |
| *** money__ <money__!~money@50.239.93.29> has quit IRC (Ping timeout: 256 seconds) | 04:06 | |
| *** money_ <money_!~money@172.58.203.79> has joined #yocto | 04:07 | |
| *** money_ <money_!~money@172.58.203.79> has quit IRC (Read error: Connection reset by peer) | 04:09 | |
| *** money_ <money_!~money@2607:fb91:bd34:c1b1:60ff:ce4f:5cae:2e80> has joined #yocto | 04:09 | |
| *** money__ <money__!~money@50.239.93.29> has joined #yocto | 04:22 | |
| *** money_ <money_!~money@2607:fb91:bd34:c1b1:60ff:ce4f:5cae:2e80> has quit IRC (Ping timeout: 256 seconds) | 04:26 | |
| Haxxa | I have a PLC running yocto linux which I cannot rebuilt the OS for. Is there anyway to add something for monitoring filesystem changes? (i.e.inotifywait) | 04:38 |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 04:38 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 04:38 | |
| *** moose <moose!~moose@38.99.249.66> has quit IRC (Quit: Client closed) | 04:51 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 05:17 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has quit IRC (Ping timeout: 268 seconds) | 05:24 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 05:24 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 252 seconds) | 05:29 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has joined #yocto | 05:29 | |
| *** money_ <money_!~money@2607:fb91:bd24:772:1444:8545:2c03:8bb9> has joined #yocto | 05:32 | |
| *** money__ <money__!~money@50.239.93.29> has quit IRC (Ping timeout: 256 seconds) | 05:35 | |
| *** pml <pml!~morne@209.203.60.184> has joined #yocto | 05:47 | |
| *** money__ <money__!~money@50.239.93.29> has joined #yocto | 05:50 | |
| *** money_ <money_!~money@2607:fb91:bd24:772:1444:8545:2c03:8bb9> has quit IRC (Ping timeout: 256 seconds) | 05:54 | |
| *** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has joined #yocto | 06:05 | |
| *** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has quit IRC (Client Quit) | 06:08 | |
| *** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has joined #yocto | 06:11 | |
| tomzy_0 | morining | 06:15 |
| *** money__ <money__!~money@50.239.93.29> has quit IRC (Quit: late) | 06:20 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 06:25 | |
| *** money_ <money_!~money@50.239.93.29> has joined #yocto | 06:29 | |
| *** olani <olani!~olani@83-233-29-230.cust.bredband2.com> has quit IRC (Ping timeout: 268 seconds) | 06:39 | |
| *** schtobia <schtobia!~quassel@schmidl.dev> has quit IRC (Quit: Bye!) | 06:39 | |
| *** schtobia <schtobia!~quassel@schmidl.dev> has joined #yocto | 06:40 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto | 06:41 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has quit IRC (Ping timeout: 252 seconds) | 06:48 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 06:49 | |
| *** mihai <mihai!~mihai@user/mihai> has joined #yocto | 06:52 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 268 seconds) | 06:54 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has joined #yocto | 06:54 | |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 07:13 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 260 seconds) | 07:32 | |
| *** rob_w <rob_w!~rob@2001:a61:61c0:5c01:9d46:1f95:999c:1f78> has joined #yocto | 07:36 | |
| LetoThe2nd | yo dudX | 07:38 |
| LetoThe2nd | Haxxa: if it is something that only is a userspace binary, it might be possible - but yocto is not going to help you until you have source. if you need bootloader or kernel modifications, probably no. | 07:40 |
| Haxxa | LetoThe2nd Yeah no source. How hard would it be to compile a new distro for the hardware? I have root access on yocto linux | 07:41 |
| Haxxa | I tried a couple of userland binaries but a lot expect libs that aren't present that are heavily integrated with kernel | 07:41 |
| LetoThe2nd | Haxxa: without source and schematics, depends on your expertise. as you have to ask, i would say "very hard" | 07:41 |
| Haxxa | I'd imagine | 07:42 |
| LetoThe2nd | Haxxa: why not ask the vendor for source? | 07:42 |
| Haxxa | LetoThe2nd lol, there is no way. This is a PLC manufacturer, these guys never release source code, they don't even stipulate it runs linux. My role is generally to make the box do things it's not designed to | 07:43 |
| LetoThe2nd | Haxxa: they have to, bring legal into play then. | 07:43 |
| LetoThe2nd | Haxxa: and it definitely is not true that PLC manufacturers don't do this. | 07:44 |
| Haxxa | The device is a brodersen rtu32m, I don't have resources to bring legal. Also anytime I ask a company to release source code because licensing, it never works. | 07:45 |
| LetoThe2nd | Haxxa: contact FSF[-E] then. its exactly their cup of tea. | 07:46 |
| Haxxa | Out of interest, what implies they have to release source code, I thought it was only for specific parts of the source code which are under GPL | 07:46 |
| LetoThe2nd | Haxxa: yep. but then you've got the kernel source, and from there you can do mostly everything. | 07:47 |
| LetoThe2nd | still its not trivial then, but hey... | 07:48 |
| Haxxa | I think I will take the trivial route and avoid this process :) | 07:48 |
| * LetoThe2nd shrug | 07:49 | |
| LetoThe2nd | in the end you want to create some statically linked binary then. but its quite different from what yocto does. look at the toolchains that bootlin provides, for example. | 07:49 |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto | 07:50 | |
| kroon | Hi. Am I the only one for whom bitbake always reparses the recipes on each invocation, even though no recipes are changing ? (using master branches of oe-core/bitbake) | 07:51 |
| *** Payam <Payam!~Payam@195.178.161.167> has joined #yocto | 07:55 | |
| *** mckoan_ is now known as mckoan | 07:55 | |
| mckoan | good morning | 07:55 |
| *** Algotech75 <Algotech75!~algotech@2a01:e0a:5e0:29b0:f344:5cde:8d9a:b42d> has joined #yocto | 08:07 | |
| *** gho <gho!~gho@i59F5CDBD.versanet.de> has joined #yocto | 08:07 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 08:08 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 08:08 | |
| *** money_ <money_!~money@50.239.93.29> has quit IRC (Quit: late) | 08:18 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:470d:8800:24d7:51ff:fed6:906d> has joined #yocto | 08:24 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 08:29 | |
| *** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Remote host closed the connection) | 08:49 | |
| *** azcraft <azcraft!~AzCraft@195.214.249.209> has joined #yocto | 08:53 | |
| *** frieder <frieder!~frieder@200116b8242fff810000000000001cba.dip.versatel-1u1.de> has joined #yocto | 08:55 | |
| mcfrisk | is linux-yocto sstate cache is wiped, and recipe rebuilt, but the hashes match the previous version, can this cause rootfs'es to not be re-generated on kirkstone? | 08:57 |
| mcfrisk | /is/if/ | 08:58 |
| *** frieder <frieder!~frieder@200116b8242fff810000000000001cba.dip.versatel-1u1.de> has quit IRC (Remote host closed the connection) | 08:59 | |
| *** Payam <Payam!~Payam@195.178.161.167> has quit IRC (Ping timeout: 268 seconds) | 08:59 | |
| *** gsalazar <gsalazar!~gsalazar@139.0.166.178.rev.vodafone.pt> has joined #yocto | 09:12 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 252 seconds) | 09:19 | |
| *** money_ <money_!~money@50.239.93.29> has joined #yocto | 09:19 | |
| *** money_ <money_!~money@50.239.93.29> has quit IRC (Client Quit) | 09:19 | |
| *** money_ <money_!~money@50.239.93.29> has joined #yocto | 09:20 | |
| *** money_ <money_!~money@50.239.93.29> has quit IRC (Quit: late) | 09:28 | |
| *** money_ <money_!~money@50.239.93.29> has joined #yocto | 09:31 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 09:32 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 09:32 | |
| *** money_ <money_!~money@50.239.93.29> has quit IRC (Client Quit) | 09:33 | |
| *** money_ <money_!~money@50.239.93.29> has joined #yocto | 09:38 | |
| *** money_ <money_!~money@50.239.93.29> has quit IRC (Read error: Connection reset by peer) | 09:40 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Ping timeout: 268 seconds) | 09:41 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has joined #yocto | 09:51 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:51 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 255 seconds) | 09:55 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 272 seconds) | 09:58 | |
| michaelo | Greetings. Did any of you who spoke at YPS2022.11 get a speaker gift this time? I saw the line in the conf budget, but apparently haven't received anything. | 09:59 |
| LetoThe2nd | ndec: your call ;-) | 10:01 |
| ndec | heh... yes, it is planned, i am almost done with getting the gift cards and sending them away! | 10:02 |
| LetoThe2nd | physical ones? | 10:06 |
| * LetoThe2nd blows mind | 10:06 | |
| *** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has quit IRC (Quit: Client closed) | 10:08 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:10 | |
| mcfrisk | if I wipe sstate cache of linux-yocto kernel and then rebuild target image, then linux-yocto will be recompiled, but the image will not be recompiled. I don't get this. Why doesn't the image get recompiled if kernel was recompiled. the task hashes of kernel did not change, but the binaries did. | 10:12 |
| ndec | LetoThe2nd: no, sending via email :) | 10:16 |
| mcfrisk | if signing is enabled, linux-yocto do_compile generates a key pair and do_install signs modules. Thus every rebuild is unique even if tash hashes did not change, and full dependency tree should be recompiled. How to enforce this? | 10:17 |
| qschulz | RP: wondering if scripts added by addpylib are watched by bitbake for changes? I remember that wasn't the case in Thud and we had to manually trigger a rebuild of everything when we did change some layer scripts | 10:24 |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has quit IRC (Ping timeout: 260 seconds) | 10:24 | |
| qschulz | (just reading the 4.2 migration notes :) | 10:24 |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 10:24 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 268 seconds) | 10:29 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has joined #yocto | 10:29 | |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 10:35 | |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection) | 10:36 | |
| michaelo | ndec: ah, great. Right in time for Xmas then ;) Thanks! I was asking because last time I almost missed the e-mail. | 10:36 |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 10:36 | |
| RP | qschulz: I opted not to make them depend on the code although variable dependencies would change iot | 10:41 |
| qschulz | RP: ack, thx for the info | 10:44 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 10:50 | |
| mcfrisk | I guess there is no defined way to generate build specific secrets during a bitbake/yocto build? things like the kernel module signing keys, ssh host keys. ssh keys are delayed to first boot. but kernel mod signing really should use build time generated random key. static keys increase the risk of leaks and key re-use | 10:54 |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 10:55 | |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 10:55 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto | 10:57 | |
| mcfrisk | for kernel module signing, the do_compile task would need to invalidate/increment/change the task hash to trigger all dependencies to rebuild | 10:57 |
| RP | mcfrisk: people have static key recipes but there isn't any common infra for it | 10:58 |
| RP | mcfrisk: having a recipe/task generate the kernel module signing keys then control where they're used would seem sensible, then it's hash can control when it is reused or isn't | 10:58 |
| mcfrisk | that's different from nostamp task which should always be executed, and also makes the build of task not reproducible. but that's per design, on purpose. build machine has more entroby than target | 10:58 |
| RP | right, nostamp always runs | 10:58 |
| mcfrisk | is there some magic to change task hash within task execution? | 10:59 |
| *** ptsneves <ptsneves!~Thunderbi@031011128120.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto | 11:01 | |
| RP | mcfrisk: we have to compute hashes in advance :( | 11:03 |
| RP | mcfrisk: else you can't query sstate for example | 11:03 |
| *** starblue1 <starblue1!~juergen@dslb-094-220-111-012.094.220.pools.vodafone-ip.de> has quit IRC (Ping timeout: 252 seconds) | 11:03 | |
| RP | mcfrisk: the only way it can change course is locked sigs or the "taint" that bitbake -f adds | 11:04 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 11:04 | |
| *** starblue1 <starblue1!~juergen@dslb-094-220-111-012.094.220.pools.vodafone-ip.de> has joined #yocto | 11:05 | |
| mcfrisk | RP: taint would do the job, I'll try | 11:06 |
| RP | mcfrisk: you can't do that when tasks are executing though | 11:06 |
| mcfrisk | can another task call invalidate_task? or is it only available at parsing time | 11:08 |
| RP | mcfrisk: it is only available before the taskgraph is constructed | 11:08 |
| RP | mcfrisk: I guess these days we do "rehash" after hashequiv was added. The code won't know how to handle a rehash for a changed taint on a task though | 11:09 |
| RP | mcfrisk: I'm just trying to help by warning you of this up front since I know the code! | 11:10 |
| *** Algotech75 <Algotech75!~algotech@2a01:e0a:5e0:29b0:f344:5cde:8d9a:b42d> has quit IRC (Remote host closed the connection) | 11:10 | |
| mcfrisk | RP: any help or guidance is highly appreciated! | 11:11 |
| *** Algotech75 <Algotech75!~algotech@2a01:e0a:5e0:29b0:29a4:cea0:37b6:5e8d> has joined #yocto | 11:11 | |
| mcfrisk | but I think there could be uses for a stage to generate secrets, which are not reproducible by design, and then trigger full dependency graph executions if something is recompiled | 11:12 |
| RP | mcfrisk: perhaps, but it does go against a lot of existing design so it isn't going to be straight forward | 11:13 |
| RP | mcfrisk: I'm just trying to make it clear where the design is going to make this hard and where there are possibilities that might allow it to work | 11:13 |
| mcfrisk | yea, using static keys would be easy way out... | 11:14 |
| mcfrisk | or 'static' really means generated outside of bitbake build with some manual or automatic steps | 11:14 |
| ptsneves | for secrets couldnt you just vardepexclude? | 11:15 |
| RP | mcfrisk: right, if you generate the keys into a recipe as files, bitbake knows what to do with those | 11:16 |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection) | 11:16 | |
| RP | mcfrisk: we could add in some event handler hooks for things like this, the trouble is they'd be a bit open to abuse :/ | 11:16 |
| mcfrisk | yea, I see the abuse point of view | 11:16 |
| RP | mcfrisk: I'm not against the idea, we'd just have to be careful about the implementation and docs | 11:17 |
| mcfrisk | "how to generate secrets at build time" would be nice to have in docs with some examples.. | 11:18 |
| mcfrisk | for "leaf" recipes and tasks, they can generate stuff. Build is not reproducible but for the use case it doesn't matter. for any inter recipe and task dependencies this causes problems. | 11:20 |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 11:20 | |
| RP | mcfrisk: right :/ | 11:23 |
| RP | mcfrisk: even documenting the challenges now would be helpful even without solutions | 11:23 |
| RP | abelloni: I've worked out the reasons the hash tests were failing, trying new builds | 11:24 |
| abelloni | RP: ack, I'll let you work that out | 11:24 |
| LetoThe2nd | RP: no breakage before christmas, please! | 11:25 |
| *** mckoan is now known as mckoan|away | 11:32 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 11:34 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 11:46 | |
| qschulz | LetoThe2nd: which Christmas :) ? | 11:46 |
| abelloni | LetoThe2nd: I feel like this is too late :) | 11:48 |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Quit: Leaving) | 11:55 | |
| hsv | Are there any active irc channels more appropriate to discussion of embedded linux, stuff like device tree, device drivers, on ARM ? | 12:09 |
| LetoThe2nd | hsv: #armlinux? | 12:13 |
| hsv | LetoThe2nd: thank you :) | 12:14 |
| mcfrisk | recipe and task tainting don't actually trigger any recompilations, at least when the task hashes remain the same. I think the consumers of other recipes output should take into account both the task hash and the binaries from build output. Now only first part if used, the metadata. This is fine as long as SW component builds are reproducible, but not when they are not. I recompiled kernel after wiping | 12:18 |
| mcfrisk | sstate cache and initramfs and rootfs are not re-generated with the newly rebuilt kernel. | 12:18 |
| RP | LetoThe2nd: I have some patches which definitely cause some interesting issues! | 12:19 |
| RP | mcfrisk: we *cannot* take output into account. If we did, how would you know if a given sstate object were valid or not, or even know how to query for it? | 12:20 |
| RP | mcfrisk: task tainting *will* trigger recompilation | 12:20 |
| RP | by definition, the taint will change the hash | 12:21 |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 12:21 | |
| mcfrisk | RP: taining linux yocto doesn't trigger re-generation of initramfs or rootfs, not on kirkstone in my config at least | 12:23 |
| mcfrisk | RP: for indexing, yes, metadata and task has is fine, but once you have the data file too, and decision is dont to rebuild or not, if the data files don't match, a recompilation is needed. now the assumption is that sstate hashes produce equal builds. that's maybe ok for poky but not valid elsewhere. a lot of things don't compile reproducibly. | 12:25 |
| RP | mcfrisk: how are you tainting it? | 12:26 |
| mcfrisk | bitbake -f linux-yocto | 12:26 |
| RP | mcfrisk: that won't work as it taints do_build (the default task) | 12:26 |
| RP | mcfrisk: try bitbake linux-yocto -c package -f | 12:26 |
| mcfrisk | ok, from task dependencies I see that package task is dependency of do_rootfs for all packages in rootfs | 12:27 |
| RP | right | 12:27 |
| RP | so if you taint install or compile or package, it should have the effect you want | 12:28 |
| mcfrisk | but I still think relying only on task hashes is dangerous. sstate objects for a recipe are produced by the metadata for the task, metadata for dependent tasks and the content of the sstate objects (tar ball). if sstate is corrupt or wiped on purpose, the recipe with matching task hashes will be recompiled, but the dependency tree not because. then at some point in the future when the rootfs do get | 12:33 |
| mcfrisk | regenerated all the recompiled things magially appear there. | 12:34 |
| * mcfrisk blames Friday for all typos.. | 12:34 | |
| mcfrisk | kernel module signing with build time generated keys only shows this problem because user sees freshly compiled kernel used with kernel modules on stale initramfs. without signing I would be harder to see that a new kernel is being used with older modules. with reproducible and compatible builds this works but outside of poky this assumption may not hold | 12:41 |
| RP | mcfrisk: By definition, the task only depends on the metadata for the task and the dependent task contents. This is how we defined and built the system | 12:45 |
| RP | We do assume builds are reproducible. Yes, you can design a task which isn't but we don't support that | 12:45 |
| RP | sstate is built on these assumptions. If we were to change them, we'd have to redesign everything | 12:46 |
| RP | mcfrisk: the alternative is always build everything. You can do that easily by not using/sharing sstate | 12:47 |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 12:50 | |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 12:50 | |
| mcfrisk | task hash is one input, second really should be the task output. if output changes, dependency tree needs to be recompiled. hash input can be the key to find data to compare. | 12:54 |
| RP | mcfrisk: I've tried to explain why that isn't practical and can't really work :/ | 12:55 |
| RP | You could I guess make it hard error if the output differed but you cannot recompute the dependency tree | 12:56 |
| RP | some tasks don't binary reproduce either, in particular, native task output | 12:56 |
| RP | for reproducibility we only look at the target output at present, native is something we should look at but nobody has stepped up | 12:57 |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 13:01 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Read error: Connection reset by peer) | 13:02 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 13:02 | |
| mcfrisk | after compiling a sstate cache hash, and the actual output, you can calculate the blob output hash too. and if the blob output now differs compared what user recipes previously saw with the task hash, the task has can't be trusted and recompilation is needed. if blob hashes do match, then binaries are reproducible. | 13:07 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 13:07 | |
| RP | mcfrisk: so to ensure a build is correct, we need to download each object, rebuild it and check the output checksum? Otherwise how do we know which objects we can use from sstate and which we have to rebuild? | 13:11 |
| mcfrisk | check output checksum only after recompilation. recompilaton can be forced or sstate entry can be missing. | 13:12 |
| RP | mcfrisk: so where does this output checksum to compare against come from if the sstate entry is missing? I guess you might have one if it is being forced, but if it is being forced, you may as well taint with -f | 13:14 |
| RP | then, how do you share this "taint" back into the wider ecosystem for another build to use? | 13:14 |
| mcfrisk | record the sstate hash and blob hashes which were used in every compilation. these are the inputs to the build. this is how I saw builds in sumo times, AFAIK.. | 13:16 |
| RP | mcfrisk: record where? We have never worked on output hashes until we added hashequiv. Sumo did not do that | 13:17 |
| mcfrisk | sumo did recompile a lot more with sstate, the effect was similar. full dependency tree recompiled every time. | 13:17 |
| mcfrisk | I really thought hashequiv did take the recipe output into account too | 13:18 |
| RP | mcfrisk: the behaviour is unchanged from sumo until now apart from hash equivalence. hash equvalence does take the output into account | 13:18 |
| mcfrisk | and rebuilds dependency tree also if output changed? maybe I should use that then | 13:19 |
| RP | mcfrisk: it will, however it is still built on top of the assumptions in the system that tasks are idempotent | 13:20 |
| RP | mcfrisk: you can't just change that assumption as it doesn't work for your use case :( | 13:21 |
| mcfrisk | I know that assumtion to be false in so many :( you've made poky reproducible, that is great! many other layers don't match that, proprietary things are even worse | 13:22 |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 13:24 | |
| RP | mcfrisk: well, what can we do about that? They're not using it as designed (which is probably why they complain sstate doesn't do what they want too) | 13:29 |
| RP | mcfrisk: changing the design isn't an option, it is inbuilt into too many places (even without sstate, that just builds on earlier pieces). We probably can detect it using hash equiv in limited cases but to work it out you really have to compare two builds and we do already have tests for that people can run | 13:31 |
| mcfrisk | I'll think about this. at least I know now that reproducible recipe builds are required for sstate cache to work reliably. and if there are issues with build output, wiping full sstate cache is a must. wiping a single recipe sstate doesn't rebuild the dependencies and fix all data in sstate cache. | 13:38 |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 246 seconds) | 13:46 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 13:47 | |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-26-174-95-44-180.dsl.bell.ca> has joined #yocto | 14:07 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 14:17 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has joined #yocto | 14:26 | |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Quit: Leaving) | 14:34 | |
| mcfrisk | RP: how about emulating build specific keys in do_fetch()? generating them with custom openssl call in do_fetch() and storing results in download dir. this would be outside of sstate hashes and would regenerate keys when ever do_fetch() gets executed. or should the cached files be bound to PV and PR regenerate only when those change | 14:37 |
| RP | mcfrisk: do_fetch is supposed to get deterministic inputs but you probably could make some custom approach work. Not sure it would be much different to a custom recipe extracting keys from DL_DIR though | 14:40 |
| RP | mcfrisk: the hard part would be having the "hash" for the fetch task ready at parse time | 14:40 |
| mcfrisk | yea, that could be some nice set of variables to refer in the custom task or do_fetch(), but hacking this into do_fetch() could be ok but then please don't publich download cache with private keys... :) | 14:41 |
| mcfrisk | oh problem wasn't generation but invalidating task hashes when parsing or executing recipe tasks | 14:46 |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Read error: Connection reset by peer) | 14:50 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 14:50 | |
| JPEW | RP: I pushed up a few more "interesting" filters that might be really useful | 15:01 |
| JPEW | One converts a variable to a python object by treating it as JSON and the other does the same but as a python eval() string | 15:02 |
| JPEW | (this would make it very easy for people to encode structured data in a variable and access it from a python task) | 15:03 |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Ping timeout: 268 seconds) | 15:03 | |
| *** Algotech75 <Algotech75!~algotech@2a01:e0a:5e0:29b0:29a4:cea0:37b6:5e8d> has quit IRC (Remote host closed the connection) | 15:04 | |
| JPEW | And, I was thinking the bitbake parsing code that calls filter can inject "d" into the extra_globals, so you could do e.g.: | 15:08 |
| JPEW | MY_STRUCTURED_DATA = "{'foo': d.getVar('FOO')}" | 15:08 |
| JPEW | MY_STRUCTURED_DATA[filter] = "eval(v)" | 15:08 |
| *** Algotech75 <Algotech75!~algotech@2a01:e0a:5e0:29b0:ff6b:c239:d87c:d94d> has joined #yocto | 15:14 | |
| *** mckoan|away <mckoan|away!~marco@host-95-229-48-41.business.telecomitalia.it> has quit IRC (Ping timeout: 268 seconds) | 15:14 | |
| *** mckoan|away <mckoan|away!~marco@host-95-229-48-41.business.telecomitalia.it> has joined #yocto | 15:16 | |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 15:19 | |
| RP | JPEW: I'm struggling to make the sig changes work atm :/ | 15:20 |
| JPEW | RP: Ah, what's not working? | 15:21 |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Client Quit) | 15:21 | |
| RP | JPEW: I broke the performance of -S X Y :/ | 15:21 |
| RP | (dump_sigs) | 15:22 |
| RP | JPEW: I can see how the structured data might be useful. I am a bit worried about us causing a parsing nightmare though | 15:22 |
| JPEW | RP: Ah, maybe we can't enable using RECIPE_SIGGEN_INFO that until we have the speedup optimizations? | 15:23 |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 15:23 | |
| JPEW | RP: Ya fair, I wanted to get the code on a branch so that it at least exists somewhere next time we get around to thinking about it | 15:23 |
| RP | JPEW: it isn't that, there is a different problem in the code I added | 15:23 |
| JPEW | RP: Ah, OK | 15:24 |
| RP | JPEW: I do really appreciate having the branch around! | 15:24 |
| RP | JPEW: I think I nearly have a patch which fixes things enough to maybe let us merge a bit more | 15:24 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 268 seconds) | 15:26 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 252 seconds) | 15:26 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 15:33 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has joined #yocto | 15:34 | |
| *** pabigot <pabigot!~pab@67-1-115-166.tcso.qwest.net> has quit IRC (Remote host closed the connection) | 15:37 | |
| *** pabigot <pabigot!~pab@67-1-115-166.tcso.qwest.net> has joined #yocto | 15:39 | |
| RP | JPEW: in case it is interesting, https://git.yoctoproject.org/poky-contrib/patch/?id=cec7b3ed4308aa71422fa93dd3f5fa02efef1e19 is how I fixed the performance issue. I'd removed that multiprocess code but had to put it back | 15:50 |
| RP | JPEW: I'd assumed if we didn't have to reparse, writing out the stamp files would be fast but it isn't :/ | 15:50 |
| JPEW | It's weird that multiprocess helps there? | 15:51 |
| JPEW | One would assume it's I/O bound | 15:51 |
| RP | JPEW: You can play with "time bitbake world -S none" | 15:51 |
| *** rob_w <rob_w!~rob@2001:a61:61c0:5c01:9d46:1f95:999c:1f78> has quit IRC (Quit: Leaving) | 15:52 | |
| RP | JPEW: I've not profiled it, I just want to remove the performance regression since we use -S in a lot of tests | 15:52 |
| JPEW | RP: Ya, that makes complete sense | 15:52 |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 272 seconds) | 15:54 | |
| RP | JPEW: I have a new problem coming there with this patch: https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/t222&id=8059cb566d2cfe3d38eb725f89ee9771a6a1e9fd | 15:54 |
| RP | JPEW: what that simpleish patch does is write a single file alongside locked-sigs.inc with all the sig data in it | 15:55 |
| *** azcraft <azcraft!~AzCraft@195.214.249.209> has quit IRC (Remote host closed the connection) | 15:55 | |
| RP | JPEW: so we can have the world signature data in a single file. It also enables diffsigs to simplisticly diff them | 15:55 |
| RP | JPEW: performance is even worse though : | 15:55 |
| RP | :( | 15:55 |
| *** ramacassis[m] <ramacassis[m]!~ramacassi@2001:470:69fc:105::2:1958> has quit IRC (Quit: You have been kicked for being idle) | 16:00 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has joined #yocto | 16:03 | |
| RP | JPEW: adding in the dump_sigs call in the above patch takes sstatetests.SStateTests.test_sstate_allarch_samesigs from 50s to 142s :( | 16:14 |
| JPEW | RP: yuck | 16:14 |
| RP | JPEW: exactly | 16:15 |
| JPEW | Is that so that you can diff locked signatures with the actual signature to see what's changed? | 16:15 |
| RP | JPEW: it means there is debug data we can include alongside locked-sigs, but yes, we could change the tests to use this to diff | 16:16 |
| RP | JPEW: it is about saving this data out and then being able to show the user debug info if things don't match when we think they should | 16:16 |
| RP | JPEW: it is using json, I need to switch that to pickle and it should be better. 651MB of json compressing to 27MB | 16:21 |
| * RP thought it was using pickle | 16:21 | |
| JPEW | I think pickle is a little faster than json | 16:22 |
| JPEW | But, probably not _that_ much faster | 16:22 |
| RP | JPEW: it will compress the data as we did with the main cache though (or plan to) | 16:27 |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 268 seconds) | 16:31 | |
| *** azcraft <azcraft!~AzCraft@195.214.249.209> has joined #yocto | 16:31 | |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection) | 16:35 | |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 16:35 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has joined #yocto | 16:46 | |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Ping timeout: 252 seconds) | 16:53 | |
| RP | JPEW: switching to pickle take the data to 265MB uncompressed, still around 27MB compressed. The sstate test 50s -> 65s | 17:00 |
| JPEW | Well, that's better at least | 17:01 |
| RP | JPEW: lot more workable, particularly if we add something to turn off the other data writing | 17:05 |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 265 seconds) | 17:07 | |
| *** gho <gho!~gho@i59F5CDBD.versanet.de> has quit IRC (Quit: Leaving.) | 17:17 | |
| *** Algotech75 <Algotech75!~algotech@2a01:e0a:5e0:29b0:ff6b:c239:d87c:d94d> has quit IRC (Quit: Leaving) | 17:17 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has joined #yocto | 17:22 | |
| rburton | abelloni: v2 of gtk tested properly this time | 17:38 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 17:39 | |
| *** mckoan_ <mckoan_!~marco@host-95-229-48-41.business.telecomitalia.it> has joined #yocto | 17:46 | |
| *** mckoan|away <mckoan|away!~marco@host-95-229-48-41.business.telecomitalia.it> has quit IRC (Ping timeout: 246 seconds) | 17:49 | |
| *** ptsneves <ptsneves!~Thunderbi@031011128120.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 255 seconds) | 17:57 | |
| *** barometz <barometz!~dvanb@92-109-61-249.cable.dynamic.v4.ziggo.nl> has quit IRC (Ping timeout: 272 seconds) | 17:59 | |
| *** barometz <barometz!~dvanb@92-109-61-249.cable.dynamic.v4.ziggo.nl> has joined #yocto | 17:59 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 17:59 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 18:08 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 18:08 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 18:17 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 18:19 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto | 18:28 | |
| *** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has joined #yocto | 18:32 | |
| *** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 18:36 | |
| *** npcomp <npcomp!~user@user/npcomp> has quit IRC (Ping timeout: 256 seconds) | 18:41 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 255 seconds) | 18:45 | |
| khem | rburton: did meta-clang/kirstone pull worked for you ? | 18:47 |
| khem | https://github.com/kraj/meta-clang/pull/706 | 18:47 |
| *** npcomp <npcomp!~user@user/npcomp> has joined #yocto | 18:55 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has joined #yocto | 18:55 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 19:09 | |
| *** pml <pml!~morne@209.203.60.184> has quit IRC (Ping timeout: 268 seconds) | 19:22 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 19:46 | |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 19:50 | |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 19:51 | |
| rburton | khem: perf blows up still but i think it helped. | 20:04 |
| rburton | khem: i've lost the perf fix you had | 20:29 |
| rburton | khem: perf fails with clang-14: error: no such file or directory: 'arm-poky-linux-gnueabi' | 20:30 |
| rburton | khem: but the strip/objcopy overrides work, yes | 20:31 |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 20:37 | |
| rburton | RP: so zstd has native threading now, so we can drop pzstd (assuming that doesn't mean using a really new version). Will investigate. | 20:39 |
| *** mvlad <mvlad!~mvlad@2a02:2f08:470d:8800:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection) | 21:24 | |
| *** demirok <demirok!~bell@user/demirok> has joined #yocto | 21:30 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 252 seconds) | 21:41 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has joined #yocto | 21:46 | |
| malsyned | I have a custom linux bb recipe based on NXP's linux-imx recipe which fetches the source using git, and every time I change the SRCREV bitbake fetches the entire repo from scratch rather than just pulling the new commits into an existing repo. Anybody know why or if there's a way to fix it? It's | 22:29 |
| malsyned | uldn't be necessary. | 22:29 |
| malsyned | like a half-hour every time, and it seems like it sho | 22:29 |
| *** florian_kc <florian_kc!~florian@dynamic-002-244-145-082.2.244.pool.telefonica.de> has joined #yocto | 22:33 | |
| *** swedishhat[m] <swedishhat[m]!~swedishha@2001:470:69fc:105::1:8c8> has joined #yocto | 22:58 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 265 seconds) | 23:06 | |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-26-174-95-44-180.dsl.bell.ca> has quit IRC (Quit: Konversation terminated!) | 23:28 | |
| *** azcraft <azcraft!~AzCraft@195.214.249.209> has quit IRC (Remote host closed the connection) | 23:32 | |
| RP | rburton: in both the compressor and decompressor? I think one was the issue last time | 23:53 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!