| smurray | RP: okay, I'm about to check out for the evening, but can take a whack at it tomorrow | 00:01 |
|---|---|---|
| *** dev1990 <dev1990!~dev@78.8.203.136> has quit IRC (Quit: Konversation terminated!) | 00:03 | |
| RP | Oh, it is because I'm causing errors in the base configuration and this is before knotty has properly started up, therefore the log filtering isn't fully live | 00:03 |
| * RP can live with a couple of duplicate lines | 00:03 | |
| RP | sgw, smurray: the above commit should apply on top of the bitbake changes in master-next and be usable from there | 00:04 |
| sgw | Looking at this time. | 00:05 |
| smurray | RP: one question wrt having the list of variables in code, would the plan be to variables in oe-core just be added there? (I'd be okay with that, but checking) | 00:05 |
| smurray | err, would the plan be to have variables... | 00:06 |
| sgw | I will give them a try, I started with the earlier patch set and did see a reduction in errors, but will try again with master-next ++ | 00:08 |
| RP | smurray: that list is just the bitbake ones, we should be able to add the oe-core ones in the metadata as you originally did using a flags variable | 00:10 |
| smurray | RP: okay | 00:10 |
| RP | smurray: we need the bitbake ones in bitbake so it can scan the enviroment and bail early for those | 00:10 |
| smurray | RP: yeah, I was more thinking about whether we'd need to carry a list of the OE ones in BitBake | 00:11 |
| RP | smurray: we shouldn't have to | 00:12 |
| RP | I think these changes address issues 1+2 in my email. 3 remains and 4 is maybe partly handled | 00:13 |
| * RP has best try and sleep | 00:14 | |
| sgw | night! | 00:14 |
| *** superdupond <superdupond!~Kev@2a01cb0400149f0020a63845738b1ffd.ipv6.abo.wanadoo.fr> has quit IRC (Ping timeout: 252 seconds) | 00:14 | |
| *** florian <florian!~florian@dynamic-002-244-025-193.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 00:26 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 256 seconds) | 00:45 | |
| *** jqua[m] <jqua[m]!~quaresmam@2001:470:69fc:105::1:2faa> has joined #yocto | 01:01 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 252 seconds) | 01:12 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 01:16 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:18 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 252 seconds) | 01:23 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:29 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Quit: qschulz) | 01:32 | |
| *** mckoan|away <mckoan|away!~marco@host-79-3-92-72.business.telecomitalia.it> has quit IRC (Ping timeout: 240 seconds) | 01:32 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 01:35 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 252 seconds) | 01:36 | |
| *** mckoan|away <mckoan|away!~marco@host-79-3-92-72.business.telecomitalia.it> has joined #yocto | 01:39 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:41 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 252 seconds) | 01:49 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:55 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 01:56 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 02:10 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:13 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 02:24 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 02:29 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:30 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-184-111.home.otenet.gr> has joined #yocto | 02:32 | |
| *** rber|res <rber|res!~rber|res@ppp-2-86-184-111.home.otenet.gr> has quit IRC (Ping timeout: 252 seconds) | 02:34 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 02:38 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:43 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 252 seconds) | 02:48 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:54 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 252 seconds) | 02:59 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:04 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.60.115.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 252 seconds) | 03:09 | |
| *** jclsn7 <jclsn7!~jclsn@192.119.49.120.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:16 | |
| *** jclsn7 <jclsn7!~jclsn@192.119.49.120.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 03:25 | |
| *** jclsn7 <jclsn7!~jclsn@192.119.49.120.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:27 | |
| *** jclsn7 <jclsn7!~jclsn@192.119.49.120.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 252 seconds) | 03:34 | |
| *** jclsn7 <jclsn7!~jclsn@192.119.49.120.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:40 | |
| *** jclsn7 <jclsn7!~jclsn@192.119.49.120.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 03:51 | |
| *** amitk <amitk!~amit@103.59.74.32> has joined #yocto | 03:51 | |
| *** jclsn7 <jclsn7!~jclsn@192.119.49.120.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:56 | |
| *** jclsn7 <jclsn7!~jclsn@192.119.49.120.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 04:04 | |
| zeddii | khem: I'll have a look at it on Wednesday, that's for the heads up. | 04:07 |
| *** jclsn7 <jclsn7!~jclsn@192.119.49.120.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 04:10 | |
| zeddii | s/that's/thanks/ | 04:11 |
| khem | cool | 04:15 |
| *** silvermane <silvermane!~silverton@50.80.229.133> has joined #yocto | 04:22 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 04:29 | |
| zeddii | ok. I identified the commit upstream, it's 5.15.17+, I have it ready and will send tomorrow | 04:33 |
| *** silvermane <silvermane!~silverton@50.80.229.133> has quit IRC (Quit: Leaving) | 04:34 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 272 seconds) | 04:55 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 05:10 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 05:35 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 05:58 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 05:59 | |
| *** jclsn77 <jclsn77!~jclsn@192.119.49.120.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 06:08 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-184-111.home.otenet.gr> has quit IRC (Remote host closed the connection) | 06:09 | |
| *** rber__ <rber__!~rber|res@ppp-2-86-184-111.home.otenet.gr> has joined #yocto | 06:09 | |
| *** jclsn7 <jclsn7!~jclsn@192.119.49.120.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 06:10 | |
| *** jclsn77 is now known as jclsn7 | 06:10 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC (Ping timeout: 240 seconds) | 06:22 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Remote host closed the connection) | 06:31 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 06:31 | |
| *** davidinux <davidinux!~davidinux@37.120.201.222> has quit IRC (Ping timeout: 250 seconds) | 06:33 | |
| *** davidinux <davidinux!~davidinux@37.120.201.246> has joined #yocto | 06:35 | |
| *** GillesM <GillesM!~gilles@135.65.132.77.rev.sfr.net> has joined #yocto | 07:11 | |
| *** GillesM <GillesM!~gilles@135.65.132.77.rev.sfr.net> has quit IRC (Client Quit) | 07:16 | |
| *** GillesM <GillesM!~gilles@135.65.132.77.rev.sfr.net> has joined #yocto | 07:16 | |
| *** GillesM <GillesM!~gilles@135.65.132.77.rev.sfr.net> has quit IRC (Client Quit) | 07:17 | |
| *** GillesM <GillesM!~gilles@135.65.132.77.rev.sfr.net> has joined #yocto | 07:18 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4b12:b100:24d7:51ff:fed6:906d> has joined #yocto | 07:19 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 07:21 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 07:39 | |
| *** lucaceresoli <lucaceresoli!~ceresoli@host-79-2-93-196.business.telecomitalia.it> has joined #yocto | 07:39 | |
| *** frieder <frieder!~frieder@mue-88-130-64-089.dsl.tropolys.de> has joined #yocto | 07:46 | |
| *** vladest <vladest!~Thunderbi@2a02:1210:3083:2200:cfde:5c2:4bfe:a30e> has quit IRC (Quit: vladest) | 07:46 | |
| *** frieder <frieder!~frieder@mue-88-130-64-089.dsl.tropolys.de> has quit IRC (Remote host closed the connection) | 07:46 | |
| *** frieder <frieder!~frieder@mue-88-130-64-089.dsl.tropolys.de> has joined #yocto | 07:46 | |
| *** Etheryon <Etheryon!~Etheryon@79.114.14.243> has joined #yocto | 07:47 | |
| jclsn[m] | Morning guy | 07:56 |
| jclsn[m] | Is anyone experienced with Chromium? It just doesn't run and I have no idea where to start | 07:56 |
| jclsn[m] | Ask in #chromium or something? | 07:56 |
| jclsn[m] | * to start debugging | 07:57 |
| jclsn[m] | Here is the output... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/cbfede473fb18bcf233f50c3a9f0e96296a44912) | 07:57 |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 07:59 | |
| *** vladest <vladest!~Thunderbi@2a02:1210:3083:2200:64b1:3011:5628:6e5b> has joined #yocto | 07:59 | |
| *** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 272 seconds) | 08:11 | |
| *** dev1990 <dev1990!~dev@78.8.203.136> has joined #yocto | 08:12 | |
| *** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto | 08:12 | |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 08:17 | |
| ziga_ | Does anybody know how to install DRM test programs. I am looking at the "libdrm" recipe here and I see that "install-test-programs" is a PACKAGECONFIG which is set by default. But I can't see "mmodetest" program on my target. I also tried creating a .bbappend file where I set PACKAGECONFIG:append = " install-test-programs" but the result is the same. No test programs are installed. How can I install "modetest" then? | 08:28 |
| ziga_ | Recipe for "libdrm" is here: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-graphics/drm/libdrm_2.4.109.bb | 08:28 |
| *** mckoan|away is now known as mckoan | 08:31 | |
| qschulz | ziga_: oe-pkgdata-util find-path '*modetest*' | 08:33 |
| qschulz | libdrm-tests I think it is | 08:33 |
| ziga_ | Ha! This also returned "libdrm-tests: /usr/bin/modetest" but when I try to run "modetest" on target, it does not reckognize it. How come? | 08:35 |
| ziga_ | I ccan see that it is not installed on the target. For some reason. | 08:36 |
| ziga_ | Maybee "bitbake -c cleansstate libdrm" could fix this but I am not sure. | 08:36 |
| LetoThe2nd | yo dudX | 08:37 |
| mckoan | good morning | 08:37 |
| qschulz | ziga_: you need to install the libdrm-tests package in your image | 08:38 |
| qschulz | mornin' :) | 08:39 |
| ziga_ | @qschulz How did you know this? I did read about this package on other distributions - here: https://www.ubuntuupdates.org/package/core/focal/universe/proposed/libdrm-tests but then I wasn't able to find it inside the Open Embedded layer index (https://layers.openembedded.org/layerindex/branch/master/recipes/?q=libdrm-tests) and I thought that it does not exist. | 08:40 |
| qschulz | ziga_: recipes create packages. You bake recipes and install packages. It happens that the main/default package is named after the recipe but they are different things | 08:41 |
| qschulz | ziga_: when you install libdrm, you install the main package, but there are others too | 08:41 |
| ziga_ | I understand. I meant: "I wasn't able to find "libdrm-tests" recipe in the Open Embedded Layer index. | 08:42 |
| qschulz | oe-pkgdata-util find-paht returns the name of the package containing the files you are looking for | 08:42 |
| qschulz | ziga_: you cannot, because the OpenEmbedded layer index returns stable "objects" | 08:42 |
| qschulz | a recipe, a class, a layer, a machine are all "stable" | 08:43 |
| qschulz | but a package isn't | 08:43 |
| qschulz | because a package can or can not be built depending on the distribution, bbappends, machines, etc... | 08:43 |
| qschulz | which means there's no way for us to know in which package the file you're looking for your specific layer+image+distro+machine configuration is | 08:43 |
| jclsn[m] | If `libVIVANTE.so` is not present, it means that the Vivante driver is not installed, doesn't it? | 08:45 |
| ziga_ | Ha! So should I rather just use some search tool like "ag-silversearcher" (I recommend) and search the fetched poky repository for recipes? Probably this is the best way then? | 08:45 |
| qschulz | jclsn[m]: libraries aren't from drivers. So you're missing a package that installs this library. oe-pkgdata-util find-path '*libvivante*' | 08:46 |
| qschulz | ziga_: you can find recipes with the OE Layer Index | 08:46 |
| qschulz | you can NOT find packages with the OE Layer Index | 08:46 |
| jclsn[m] | qschulz: I just searched for '*libvivante*' in root. There is nothing | 08:47 |
| qschulz | jclsn[m]: in root? root of what? where? | 08:47 |
| jclsn[m] | Ah you mean in bitbake | 08:47 |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 08:47 | |
| jclsn[m] | qschulz: On the board | 08:48 |
| jclsn[m] | oe-pkgdata-util also finds nothing | 08:48 |
| ziga_ | @qschulz So based on your replies. I probably have to write my own recipe that will fetch, compile & install the libdrm-tests package? I haven't yet found any existing recipe that does this. | 08:48 |
| qschulz | jclsn[m]: if oe-pkgdata-util finds nothing, then it means the recipe creating this library hasn't been built | 08:48 |
| jclsn[m] | The desktop environment is horribly slow. I am assuming that there is no graphics driver present at all | 08:48 |
| *** lucaceresoli_ <lucaceresoli_!~lucaceres@host-79-2-93-196.business.telecomitalia.it> has joined #yocto | 08:48 | |
| qschulz | ziga_: no. | 08:48 |
| jclsn[m] | qschulz: Okay | 08:49 |
| qschulz | jclsn[m]: libvivante is proprietary sw also, etnaviv is the open-source alternative | 08:49 |
| qschulz | (just FYI) | 08:49 |
| jclsn[m] | The driver should be part of the kernel actually | 08:49 |
| qschulz | I can't help much more for now | 08:49 |
| jclsn[m] | qschulz: I know but our collegues want Vivante | 08:50 |
| jclsn[m] | Everyone is telling me not to use it though | 08:50 |
| qschulz | jclsn[m]: the driver will probably create a /dev device (for mali it's /dev/mali0 IIRC or something like that, there's probably something similar for vivante | 08:50 |
| qschulz | jclsn[m]: don't remember which NXP SoC you're using | 08:50 |
| jclsn[m] | im8mm | 08:51 |
| jclsn[m] | imx8mm | 08:51 |
| qschulz | but except if you have a very niche usecase, you're probably better off with Etnvaiv since I assume most open-source software actually test and/or are happy to help you debug etnaviv integration | 08:51 |
| qschulz | I only had vivante running on the imx8mm | 08:52 |
| jclsn[m] | I know | 08:52 |
| jclsn[m] | They are just worried about performance | 08:52 |
| qschulz | it's imx-gpu something recipe | 08:52 |
| qschulz | jclsn[m]: also, etnaviv is supported for imx8mm only from 5.4 and mesa 20 or 21 don't remember exactly | 08:52 |
| qschulz | so if you're stuck on a super old kernel, the answer is pretty straightforward | 08:53 |
| qschulz | ziga_: libdrm-tests is the package you need to install | 08:53 |
| jclsn[m] | 5.10 here | 08:53 |
| jclsn[m] | imx-gpu-viv it is | 08:53 |
| qschulz | ziga_: if oe-pkgdata-util find-path returns something, it means this package was built | 08:53 |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 08:53 | |
| qschulz | jclsn[m]: the GPU stuff is hairy in meta layers for NXP SoCs... | 08:54 |
| qschulz | so be extra super duper sure the MACHINEOVERRIDES, SOC_FAMILY and all are correctly set | 08:54 |
| qschulz | ziga_: if you want to know which recipe provides the package which provides the file you're after, run oe-pkgdata-util lookup-recipe libdrm-tests (or something close to this) | 08:55 |
| qschulz | ziga_: you'll see that libdrm is the recipe which creates the libdrm-tests package | 08:55 |
| *** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has quit IRC (Ping timeout: 256 seconds) | 08:56 | |
| jclsn[m] | qschulz: Interesting. The thing is we have created our own machine name, so many packages complain that it isn't compatible although it is an imx8mm actually. I just tried building `imx-gpu-viv`and it says exactly that. So I guess I have to make a .bbappend to make it compatible. But this is annyoing actually. Maybe I should use mx8 as machine override | 08:56 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 08:56 | |
| qschulz | jclsn[m]: no no no | 08:57 |
| qschulz | jclsn[m]: you setup your machine to have the correct MACHINEOVERRIDES and you're settled | 08:57 |
| qschulz | (so yes to the last sentence actually :) ) | 08:57 |
| qschulz | but look how the other machines are created | 08:57 |
| *** lucaceresoli_ <lucaceresoli_!~lucaceres@host-79-2-93-196.business.telecomitalia.it> has quit IRC (Ping timeout: 240 seconds) | 08:57 | |
| qschulz | and either include one machine conf file which is close enough to yours, or take inspiration from it | 08:58 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 08:59 | |
| jclsn[m] | qschulz: But how would I add my device tree then? It is our custom board after all | 09:00 |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 09:00 | |
| ziga_ | @qschulz I think I now understand. I just installed "libdrm-tests" package and it installed without problems. AFTER IT WAS INSTALLED I used "oe-pkgdata-util lookup-recipe libdrm-tests" and it returned recipe "libdrm". SO NOW I FINALLY know that recipe "libdrm" is the one that builds the package "libdrm-tests" but only if PACKAGECONFIG has "install-test-tools" string. But I am missing the reverrse philosophy. For example. As a developer I only | 09:01 |
| ziga_ | know which package I want/need to install. So I need a way to search for this package and then locate a recipe that produces it. At this point you would probably suggest me to use "oe-pkgdata-util" as you already did, but does this tool work if package hasn't yet been ccompiled? In my experience it doesn't. So here is where the problem is, because In my first go, I can't locate the recipe for some desired package. | 09:01 |
| qschulz | ziga_: you don't want to install a package, you want to install a file. So your reverse philosophy starts there. "I want this file", "does a package I've already built install this file?" | 09:02 |
| qschulz | ziga_: if there is no package providing the file 1) either the recipe was misconfigured, 2) or the recipe was not built yet | 09:03 |
| qschulz | this one is harder, and you'll need to use Google to find which project provides this file, then try to find if there's a recipe that exists for it | 09:03 |
| qschulz | build it, if no package still | 09:03 |
| qschulz | then you need to look into the recipe if something needs to be adapted/fixed | 09:04 |
| ziga_ | @qscchulz Ah okay. So this is why you first suggested me to use "oe-pkgdata-util find-path '*modetest*'"! Okay. Got it got it! | 09:04 |
| qschulz | if no recipe, then ask here probably? otherwise create yours | 09:05 |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 252 seconds) | 09:07 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 252 seconds) | 09:08 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 09:08 | |
| qschulz | jclsn[m]: don't understand the question? you can include a machine configuration file in another machine configuration file, where you'll set your device tree if you want | 09:08 |
| qschulz | note that MACHINEOVERRIDES should contain MACHINE (the name of your machine configuration file without the .conf) and have it have the highest precedence | 09:09 |
| jclsn[m] | <qschulz> "jclsn: don't understand the..." <- I just don't know what to choose here. I could choose `imx8mm-evk-lpddr4` but then our board is not an evalutation board. Sure I could just add our device try by sourcing machine.conf for our board that contains it, but in the end we want to thin out the whole machine configuration. Then I would have to remove all the things from that configuration with :remove overrides. Is that really the way to | 09:14 |
| jclsn[m] | go? | 09:14 |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 09:14 | |
| jclsn[m] | Atm our machine configuration is based on imx8mm-evk-lpddr4 though | 09:14 |
| qschulz | jclsn[m]: look at what this machine configuration file does then and include the thing you need | 09:14 |
| qschulz | and adapt MACHINEOVERRIDES accordingly | 09:15 |
| jclsn[m] | MACHINEOVERRIDES are "imx-boot-container:mx8:mx8m:mx8mm:" | 09:15 |
| jclsn[m] | So no idea why bitbake thinks it is our board | 09:16 |
| *** florian <florian!~florian@dynamic-078-048-123-161.78.48.pool.telefonica.de> has joined #yocto | 09:16 | |
| jclsn[m] | I have only set our MACHINE in local.conf | 09:16 |
| jclsn[m] | had to add this for the kernel for example | 09:17 |
| jclsn[m] | COMPATIBLE_MACHINE = "(mx6|mx7|mx8|vti2)" | 09:17 |
| jclsn[m] | Else it wouldn't build | 09:17 |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 272 seconds) | 09:18 | |
| *** woky <woky!~woky@li1651-31.members.linode.com> has quit IRC (Quit: Nothing in this world is hopeless!) | 09:20 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 09:20 | |
| *** woky <woky!~woky@li1651-31.members.linode.com> has joined #yocto | 09:21 | |
| *** woky <woky!~woky@li1651-31.members.linode.com> has quit IRC (Remote host closed the connection) | 09:21 | |
| *** woky <woky!~woky@li1651-31.members.linode.com> has joined #yocto | 09:22 | |
| qschulz | jclsn[m]: what was the original value for COMPATIBLE_MACHINE in the kernel recipe? | 09:28 |
| qschulz | jclsn[m]: how did you check the MACHINEOVERRIDES content? | 09:28 |
| jclsn[m] | qschulz: mx8 | 09:29 |
| jclsn[m] | I did check them some time ago using `bitbake -e | grep MACHINEOVERRIDES` I think | 09:29 |
| jclsn[m] | `vti2` was added by default. You actually told me that | 09:30 |
| qschulz | jclsn[m]: your machine name is missing from it, it should be the rightmost entry in the colon separated list | 09:30 |
| jclsn[m] | What | 09:30 |
| jclsn[m] | I am pretty sure you told me not to add it because it is added by default | 09:30 |
| qschulz | jclsn[m]: yes | 09:30 |
| qschulz | not add it MANUALLY :) | 09:31 |
| qschulz | so wild guess right now, you are reassigning MACHINEOVERRIDES instead of prepending/appending to it | 09:31 |
| qschulz | how is MACHINEOVERRIDES variable modified in your machine configuration file | 09:31 |
| jclsn[m] | This is MACHINEOVERRIDES line from the our vti2.conf, which is our custom machine configuration file | 09:32 |
| qschulz | (though it should work just fine with the MACHINEOVERRIDES above if COMPATIBLE_MACHINE has mx8 in them.. | 09:32 |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 09:33 | |
| jclsn[m] | Got this though | 09:33 |
| jclsn[m] | imx-gpu-viv was skipped: incompatible with machine vti2 (not in COMPATIBLE_MACHINE) | 09:33 |
| qschulz | jclsn[m]: what is the line your vti2.conf for MACHINEOVERRIDES variable | 09:33 |
| jclsn[m] | And it is weird that this recipe wasn't built in the first place | 09:33 |
| jclsn[m] | qschulz: The one I sent you above | 09:33 |
| qschulz | jclsn[m]: ther'es no operator in the line you have me | 09:35 |
| qschulz | gave* | 09:35 |
| jclsn[m] | MACHINEOVERRIDES =. "imx-boot-container:mx8:mx8m:mx8mm:" | 09:36 |
| qschulz | jclsn[m]: and before any include right? seems about right, if you check with bitbake -e some-recipe | grep ^MACHINEOVERRIDES=, you should have vti2 in there | 09:37 |
| jclsn[m] | qschulz: It is in there | 09:38 |
| jclsn[m] | I am currently building chromium though | 09:39 |
| jclsn[m] | I just wonder why the recipes are only being passed vti2 | 09:39 |
| jclsn[m] | mx8 should also be passed, shouldn't it? | 09:39 |
| *** florian <florian!~florian@dynamic-078-048-123-161.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 250 seconds) | 09:40 | |
| *** m4ho <m4ho!~m4ho@81.20.119.6> has quit IRC (Read error: Connection reset by peer) | 09:40 | |
| jclsn[m] | It is tedious to add vti2 to COMPATIBLE_MACHINE in every recipe | 09:40 |
| jclsn[m] | CONFIG_MXC_GPU_VIV is also not added in the linux-fslc-imx defconfig | 09:41 |
| jclsn[m] | I still don't understand this kernel recipe fully | 09:41 |
| qschulz | jclsn[m]: kernel recipes are often complex so it's not surprise, it takes me time every time too | 09:42 |
| qschulz | no* | 09:42 |
| qschulz | jclsn[m]: I've seen some COMPATIBLE_MACHINE:machine = "machine" in some recipes, so you might be missing yours | 09:42 |
| qschulz | honestly I don't know | 09:42 |
| jclsn[m] | qschulz: This one is especially hard though because it is a kernel that is patched together from mainline and linux-imx | 09:43 |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 250 seconds) | 09:43 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Remote host closed the connection) | 09:53 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 09:53 | |
| *** m4ho <m4ho!~m4ho@p5098be52.dip0.t-ipconnect.de> has joined #yocto | 09:57 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 09:57 | |
| jclsn[m] | Why is it discouraged btw to edit defconfigs directly? Because some configurations might conflict and menuconfig can detect that? | 09:58 |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 250 seconds) | 10:02 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 10:02 | |
| *** dsueiro <dsueiro!~dsueiro@217.140.106.13> has quit IRC (Quit: Client closed) | 10:02 | |
| *** huseyinkozan <huseyinkozan!~hk@31.223.46.227> has joined #yocto | 10:08 | |
| qschulz | jclsn[m]: because some configurations have "depends on" you might not have added yourself, and you think you have enabled an option but actually you didn't | 10:10 |
| jclsn[m] | Okay thanks | 10:11 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:20 | |
| Etheryon | Hello, I have an ISO image that I built and burned to a USB stick to run live. Any was I can make the fs not read-only? I'm not even sure what sets it as RO | 10:31 |
| LetoThe2nd | Etheryon: adding read-only-rootfs to IMAGE_FEATURES should do the trick. | 10:36 |
| *** chep` <chep`!~chep@82-65-36-115.subs.proxad.net> has joined #yocto | 10:39 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 10:39 | |
| *** chep <chep!~chep@82-65-36-115.subs.proxad.net> has quit IRC (Read error: Connection reset by peer) | 10:40 | |
| *** chep` is now known as chep | 10:40 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds) | 10:43 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 272 seconds) | 10:48 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:49 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 10:49 | |
| *** Etheryon <Etheryon!~Etheryon@79.114.14.243> has quit IRC (Quit: Client closed) | 10:51 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 252 seconds) | 11:08 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 11:09 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 11:09 | |
| *** woky <woky!~woky@li1651-31.members.linode.com> has quit IRC (Quit: Nothing in this world is hopeless!) | 11:16 | |
| *** snapsd49 <snapsd49!~snapsd@061238109209.ctinets.com> has joined #yocto | 11:16 | |
| snapsd49 | Hello | 11:16 |
| snapsd49 | can I trigger a recipe build from another recipe (possibally from do_compile)? | 11:17 |
| *** woky <woky!~woky@li1651-31.members.linode.com> has joined #yocto | 11:18 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 272 seconds) | 11:18 | |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto | 11:19 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 11:19 | |
| RP | snapsd49: you can add a dependency? | 11:20 |
| LetoThe2nd | snapsd49: nope. | 11:20 |
| snapsd49 | I am getting what packages my recipe depends on after unpack task.. so need to build those pcakges | 11:20 |
| snapsd49 | so can't set in as RDEPENDS .. as dependencies are not known when I run bitbake xyz.recipe | 11:21 |
| LetoThe2nd | snapsd49: it doesn't work that way, sorry. | 11:21 |
| RP | snapsd49: as LetoThe2nd says, you can't do that dynamically | 11:21 |
| LetoThe2nd | snapsd49: meta data must be constructed in a way so all the dependencies can be calculated without running any tasts. | 11:22 |
| LetoThe2nd | tasks, even. | 11:22 |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 252 seconds) | 11:23 | |
| *** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 11:23 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 11:24 | |
| snapsd49 | okay, thanks.. that's what I was wondering.. for any recipe, the metadata / depchain is constructed before executing any task.. | 11:24 |
| snapsd49 | so any workaround / hack to add dependencies dynamically? or building packages? | 11:24 |
| snapsd49 | so any workaround / hack to add dependencies dynamically? or building packages dynamically from recipe? | 11:24 |
| LetoThe2nd | snapsd49: really bad hack: build everything in that one recipe. brute force hack: just add all dependencies statically. pipeline hack: build the thing at an earlier stage and just pack the artifact. | 11:25 |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Read error: Connection reset by peer) | 11:27 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 250 seconds) | 11:28 | |
| snapsd49 | LetoThe2nd - but I don't know what dependencies will be required to be built... I get that list after unpack stage.. | 11:28 |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 11:29 | |
| LetoThe2nd | snapsd49: i think you have some thinking to do then. | 11:29 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 240 seconds) | 11:30 | |
| *** Etheryon <Etheryon!~Etheryon@79.114.14.243> has joined #yocto | 11:32 | |
| Etheryon | I'd like it to be read-write | 11:32 |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 272 seconds) | 11:33 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 11:34 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 250 seconds) | 11:43 | |
| qschulz | Etheryon: then make sure this is not added anywhere | 11:43 |
| qschulz | Etheryon: also make sure you're not using squashfs for the root filesystem | 11:44 |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 11:44 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 11:49 | |
| *** Etheryon <Etheryon!~Etheryon@79.114.14.243> has quit IRC (Quit: Client closed) | 11:49 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 11:50 | |
| chrfle | hello, I'm stuck in a state where I get kernel logs about version magic mismatch for kernel modules. The version is the same except the hash that's different. I have tried to cleanall the kernel recipe, but I still end up in the same state. Anyone have any advice? | 11:51 |
| *** kriive <kriive!~kriive@user/kriive> has quit IRC (Remote host closed the connection) | 11:54 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 12:01 | |
| *** Kaa <Kaa!~Kaa@95.67.115.55> has joined #yocto | 12:17 | |
| dv__ | is it still discouraged to use do_install_append unless it is really necessary? | 12:26 |
| dv__ | IIRC, prefuncs and postfuncs are recommended over _append | 12:26 |
| LetoThe2nd | qschulz: ya but thats hard to avoid if you're outputting ISO | 12:27 |
| *** snapsd49 <snapsd49!~snapsd@061238109209.ctinets.com> has quit IRC (Quit: Ping timeout (120 seconds)) | 12:36 | |
| Kaa | Does anybody think that the current behavior of INITRAMFS_IMAGE_BUNDLE is weird? Linux image goes to initramfs and initramfs goes to Linux image :D | 12:47 |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 272 seconds) | 13:03 | |
| *** Etheryon <Etheryon!~Etheryon@79.114.14.243> has joined #yocto | 13:04 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 13:04 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 252 seconds) | 13:13 | |
| *** superdupond <superdupond!~Kev@2a01cb0400149f0020a63845738b1ffd.ipv6.abo.wanadoo.fr> has joined #yocto | 13:13 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 13:14 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 252 seconds) | 13:18 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 13:18 | |
| *** ar__ <ar__!~akiCA@user/akica> has joined #yocto | 13:21 | |
| Etheryon | IMAGE_FSTYPES = "iso" would do this? I've looked through env and couldn't find any read-only-rootfs | 13:26 |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 250 seconds) | 13:28 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 13:28 | |
| jclsn[m] | qschulz: I still don't get it sorry | 13:28 |
| *** codavi <codavi!~akiCA@user/akica> has joined #yocto | 13:28 | |
| jclsn[m] | I have those | 13:28 |
| jclsn[m] | PRISTINE_MACHINEOVERRIDES="aarch64:armv8a:imx:use-mainline-bsp:imx-boot-container:mx8:mx8m:mx8mm:vti2" | 13:28 |
| jclsn[m] | imx-gpu-viv expects mx8 as machine. Should I create a .bbappend now or find the reason why the machine is advertised as vti2? | 13:29 |
| jclsn[m] | I have quite a few overrides that had `:mx6` or `:mx8` before and since the honister upgrade they expect it to be `:vti2` | 13:30 |
| dv__ | otavio ^ | 13:31 |
| qschulz | jclsn[m]: PRISTINE_MACHINEOVERRIDES is not a common variable so can't say if it's correctly set up or no | 13:31 |
| *** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 240 seconds) | 13:31 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 13:31 | |
| otavio | jclsn[m]: which machine is this? | 13:32 |
| otavio | jclsn[m]: also check the final MACHINEOVERRIDES value | 13:32 |
| jclsn[m] | Is there a way to set a MACHINE alias? Like my MACHINE=vti2 but all recipes with mx8 are also valid | 13:33 |
| otavio | jclsn[m]: vti2 is the machine name? | 13:34 |
| otavio | jclsn[m]: please post the final MACHINEOVERRIDES value | 13:34 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 13:35 | |
| jclsn[m] | otavio: Our custom boards | 13:35 |
| jclsn[m] | with in im8mmm SoC | 13:35 |
| jclsn[m] | * with in im8mm SoC | 13:35 |
| otavio | jclsn[m]: please post the final MACHINEOVERRIDES value | 13:37 |
| qschulz | jclsn[m]: that's the whole point of MACHINEOVERRIDES, to not have to explicit each and every machine for recipes compatible with one specific SoC | 13:37 |
| otavio | qschulz: exactly | 13:38 |
| jclsn[m] | otavio: That is what I named it yes | 13:40 |
| jclsn[m] | https://pastebin.com/Kxgdnzim | 13:41 |
| qschulz | jclsn[m]: MACHINEOVERRIDES="aarch64:armv8a:use-mainline-bsp:imx-boot-container:vti2" | 13:42 |
| jclsn[m] | qschulz: I see. Then something funky is going on here | 13:42 |
| jclsn[m] | Wonder why mx8 is not included | 13:42 |
| qschulz | jclsn[m]: don't use grep, but less and check the variable history in the few lines above | 13:42 |
| qschulz | the one line starting with MACHINEOVERRIDES= | 13:43 |
| jclsn[m] | Guess I need to set a MACHINEOVERRIDES_EXTENDER for vti2 | 13:45 |
| *** Guest20 <Guest20!~Guest20@modemcable211.232-19-135.mc.videotron.ca> has joined #yocto | 13:46 | |
| qschulz | I don't think so | 13:49 |
| jclsn[m] | Hmm no | 13:49 |
| qschulz | the mx8mm MACHINEOVERRIDES_EXTENDER will be taken then | 13:49 |
| qschulz | just fix your MACHINEOVERRIDES fisrt, then look at the rest | 13:49 |
| qschulz | but your issue is *definitely* with *at least* MACHINEOVERRIDES | 13:49 |
| jclsn[m] | but I have this in my vti2.conf | 13:49 |
| jclsn[m] | MACHINEOVERRIDES =. "imx-boot-container:mx8:mx8m:mx8mm:" | 13:49 |
| otavio | jclsn[m]: it is using mainline; See https://github.com/Freescale/meta-freescale/blob/1ef228121d7777502f7ec6525d721a3b2727becc/conf/machine/include/imx-base.inc#L8-L17 | 13:49 |
| jclsn[m] | Why is it no appended? | 13:49 |
| jclsn[m] | otavio: That seemed to have worked | 13:52 |
| jclsn[m] | I aset IMX_DEFAULT_BSP:vti2 ?= "mx8" | 13:52 |
| jclsn[m] | s/aset/set/ | 13:52 |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 13:53 | |
| jclsn[m] | Is that a new feature? It wasn't necessary in gatesgarth | 13:53 |
| otavio | jclsn[m]: i.mx8 has moved to default to mainline | 13:55 |
| jclsn[m] | I should probably default to mainline as well haha | 13:56 |
| jclsn[m] | I like to step out of line though | 13:56 |
| qschulz | jclsn[m]: rmember you want vivante which is very likely not built when you use mainline in meta-freescale? | 14:00 |
| jclsn[m] | qschulz: I realized that | 14:01 |
| jclsn[m] | That was why I tried to append it manually and had this issue in the first place | 14:01 |
| smurray | RP: other than the double logging, your changes in poky-contrib work well, if I apply/remove my rename changes on top of bitbake and oe-core they seem to catch what I'd expect them to | 14:02 |
| jclsn[m] | But now linux-fslc-imx doesn't work anymore | 14:02 |
| jclsn[m] | I thought this was a patched linux-imx kernel with Vivante graphics | 14:02 |
| jclsn[m] | Ah no it is u-boot nevermind | 14:03 |
| RP | smurray: ok, cool. Do you have OE-Core changes? | 14:04 |
| RP | smurray: I didn't spot those, I was trying to pull together a test set of changes | 14:04 |
| RP | smurray: I have a couple of tweaks to your siggen changes so we preserve some compatibility there with old sigdata files | 14:05 |
| RP | smurray: https://git.yoctoproject.org/poky-contrib/log/?h=rpurdie/t222 has my bits so far | 14:06 |
| landgraf | RP: both hg fetcher and mercurial in general are broken badly :-/ | 14:06 |
| smurray | RP: okay. I've not posted my oe-core changes anywhere yet, they were effectively just grep | sed of the variables w/o going through and checking for anything else manually | 14:06 |
| RP | landgraf: sadly I'm not surprised :/ | 14:07 |
| RP | smurray: ok, I've a couple of patches in that branch for that then | 14:07 |
| * RP wonders about putting this in master-next | 14:07 | |
| *** pabigot <pabigot!~pab@67-1-16-117.tcso.qwest.net> has quit IRC (Remote host closed the connection) | 14:09 | |
| *** pabigot <pabigot!~pab@67-1-16-117.tcso.qwest.net> has joined #yocto | 14:11 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 14:13 | |
| otavio | jclsn[m]: qschulz: Etnaviv is a quite usable alternative for most projects; we use it for most of our customers | 14:28 |
| jclsn[m] | otavio: And NXP can't even host their files right. Again this imx-vpu-hantro-daemon fetcher failure | 14:29 |
| * RP updated master-next with the current inclusive language queue. Now I need to find the other patches people sent and try and merge these in | 14:31 | |
| * RP is extremely annoyed at being left with this | 14:32 | |
| JPEW | RP: Did you figure out that erroronce problem? | 14:32 |
| RP | JPEW: I think it is because I was testing early variables in the configuration datastore and the message filtering only works once knotty is running | 14:33 |
| qschulz | otavio: I have suggested Etnaviv to jclsn[m] already :) | 14:34 |
| * JPEW looks over the logging patches in master-next | 14:34 | |
| jclsn[m] | qschulz: Everyone does :D | 14:34 |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 272 seconds) | 14:34 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 14:34 | |
| *** rsalveti <rsalveti!uid117878@id-117878.uxbridge.irccloud.com> has quit IRC (Ping timeout: 240 seconds) | 14:36 | |
| *** Etheryon <Etheryon!~Etheryon@79.114.14.243> has quit IRC (Quit: Client closed) | 14:37 | |
| *** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Ping timeout: 240 seconds) | 14:38 | |
| *** bluelightning <bluelightning!~paul@2406:e003:151f:d701:f1da:160a:8af3:d659> has quit IRC (Ping timeout: 240 seconds) | 14:38 | |
| *** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 14:38 | |
| *** rsalveti <rsalveti!uid117878@id-117878.uxbridge.irccloud.com> has joined #yocto | 14:38 | |
| *** kanavin_ <kanavin_!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Remote host closed the connection) | 14:40 | |
| RP | sgw: I tweaked your blacklist.bbclass series to fit with the other changes and added to -next | 14:41 |
| *** Etheryon <Etheryon!~Etheryon@79.114.14.243> has joined #yocto | 14:43 | |
| smurray | RP: if you were mostly happy with those rename patches I did for BitBake, I can take a look at the few places in BitBake that still refer to "whitelist" and start on the "abort" changes tonight/tomorrow | 14:43 |
| RP | smurray: I think I'm ok with the ones in -next, yes | 14:44 |
| RP | I'm still not promising to merge any of this as we're still missing the conversion scripts and docs | 14:44 |
| *** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has joined #yocto | 14:45 | |
| RP | I just want to try and give this a chance with a baseline for people to work off | 14:45 |
| smurray | RP: okay. For docs it would be the migration guide entry? | 14:45 |
| RP | smurray: yes, that would be a good start. It doesn't have to be you but I'd like to have something | 14:46 |
| smurray | RP: okay, I'll check with sgw when he is on in a bit. I could maybe start a framework for it with these BitBake variables | 14:47 |
| JPEW | RP: With warnonce/erroronce, I think that the message will show up multiple times in the console log file (for example). More specifically, it will show up multiple times in any logger that doesn't explicitly use the designated filter. I *think* the solution here is to poke the "once" filter into the config in setLoggingConfig(), effectively making it mandatory. I have a patch to do this | 14:49 |
| RP | smurray: right, the PNBLACKLIST -> SKIP_RECIPE one also has patches | 14:49 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 14:50 | |
| RP | JPEW: Sounds good, I think I tried that and struggled | 14:50 |
| JPEW | I'll test and send it in then | 14:50 |
| smurray | RP: one note, I got a bitbake-selftest failure in test_parse_overrideimmediate with what's in poky-contrib atm | 14:51 |
| RP | smurray: sorry, there is a load of other junk in that branch including that test | 14:51 |
| RP | smurray: this is partly why I've moved to -next | 14:51 |
| smurray | RP: okay, cool | 14:52 |
| RP | smurray: from memory that is a new test where I was trying to debug something which needs fixing | 14:52 |
| smurray | gotcha | 14:52 |
| * RP has a long todo list :( | 14:52 | |
| sgw | RP : Morning, I woke up to a 6:00 am surprise meeting instead of trying to help you! | 14:52 |
| sgw | I will get to it shortly | 14:52 |
| *** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 14:53 | |
| smurray | sgw: wrt the discussion above, were you planning to work up the migration guide entry and/or the conversion script? | 14:54 |
| RP | smurray, sgw, jonmason: perhaps someone could also mail the list with a status on what is in -next and a list of what else needs doing. We now have some example patches of a conversion and the renames for core shouldn't be hard to write patches for | 14:56 |
| smurray | RP: somewhat related, is it halsted I should ping wrt getting my access to the wiki moved through approval process? | 14:56 |
| RP | smurray: it is halstead | 14:57 |
| smurray | RP: okay | 14:57 |
| smurray | RP: I'll update the table a bit once I get that sorted | 14:58 |
| RP | I'll run -next on the autobuilder, see how widespread the damage is there | 14:58 |
| sgw | smurray: I can work on the migration guide, if needed. I will be reading the log to catch up. | 14:59 |
| smurray | sgw: okay, let me know if you need help with it | 14:59 |
| *** Etheryon <Etheryon!~Etheryon@79.114.14.243> has quit IRC (Quit: Client closed) | 15:04 | |
| *** Kaa <Kaa!~Kaa@95.67.115.55> has quit IRC (Quit: Client closed) | 15:05 | |
| *** Guest83 <Guest83!~Guest83@2a02:a46d:50d4:1:44d:99c2:cb41:5c9f> has joined #yocto | 15:15 | |
| Guest83 | Hi, apologies if the following question is not a pure yocto question. In general, after writing a kernel driver, how are these drivers tested (e.g. a sensor)? Compile + insmod? | 15:17 |
| *** davidinux <davidinux!~davidinux@37.120.201.246> has quit IRC (Ping timeout: 272 seconds) | 15:17 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 272 seconds) | 15:18 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 15:18 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Ping timeout: 252 seconds) | 15:23 | |
| LetoThe2nd | Guest83: thats the classic approach, yes. | 15:23 |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has joined #yocto | 15:24 | |
| Guest83 | LetoThe2nd Thanks! | 15:26 |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds) | 15:30 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 15:32 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 15:33 | |
| JPEW | RP: Is it ok if I squash your erroronce/warnonce patching into a new single patch with fixes? | 15:40 |
| RP | JPEW: if that makes most sense, I guess yes | 15:44 |
| JPEW | There was another bug I had to fix, so I think it makes sense :) | 15:44 |
| RP | JPEW: what else did I break? :) | 15:45 |
| JPEW | The "once-ness" was global, so the message would only show up on a single logging output, and no where else | 15:45 |
| RP | JPEW: oh, ouch :/ | 15:45 |
| RP | JPEW: thanks for spotting that | 15:46 |
| JPEW | Each handler needs it's own copy of the filter so that it has it's own once state. I make setLoggingConfig() create one implicitly for each handler | 15:46 |
| RP | JPEW: makes sense, thanks | 15:46 |
| JPEW | np. Patch sent | 15:47 |
| *** Guest83 <Guest83!~Guest83@2a02:a46d:50d4:1:44d:99c2:cb41:5c9f> has quit IRC (Quit: Client closed) | 15:48 | |
| RP | JPEW: definitely looks cleaner, thanks | 15:48 |
| *** cengiz_io <cengiz_io!sid223191@id-223191.ilkley.irccloud.com> has quit IRC (Ping timeout: 245 seconds) | 15:53 | |
| *** cengiz_io <cengiz_io!sid223191@id-223191.ilkley.irccloud.com> has joined #yocto | 15:53 | |
| *** thierryE[m] <thierryE[m]!~thierryem@2001:470:69fc:105::1:5f46> has quit IRC (Quit: You have been kicked for being idle) | 16:00 | |
| otavio | jclsn[m]: if you're facing errors please report it on GitHub so I can ask them to check internally. | 16:00 |
| otavio | jclsn[m]: (fetch errors) | 16:01 |
| qschulz | otavio: if it's hosted on codeaurora, it's not uncommon to have downtime | 16:03 |
| Saur | RP: I just had a build failure with Honister on one of our Jenkins builders and this is what I got in the log: https://pastebin.com/Pt91PEXM It tells me nothing of what actually went wrong. I am pretty sure there used to be more information in cases like this. I know there has been changes to the logging to avoid duplicating logs. Is it possible that too much has been removed? | 16:08 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 16:14 | |
| RP | Saur: I suspect that is less about the logging changes and more about poor exception handling | 16:15 |
| Saur | Hmm, ok. | 16:15 |
| RP | Saur: subprocess has a habit of not showing the output from the failed command and I suspect bb.process inherited the problem | 16:15 |
| RP | Saur: it is interesting that is from the "if log:" branch so there should be output in the logs but that isn't being copied to the console | 16:16 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 16:16 | |
| RP | Saur: there are many issues like this, we just have to go through and fix them as we encounter them | 16:17 |
| RP | Saur: it might be we could just delete that if section now | 16:17 |
| RP | especially as it says "# Don't duplicate the output in the exception if logging it" | 16:18 |
| RP | sounds like we fixed the duplication elsewhere and now don't see it! | 16:18 |
| Saur | Yeah, unfortunately all our Jenkins builds are made in Docker containers that are thrown away afterwords so there is no way for me to get hold of that other log file. :( | 16:18 |
| * rfs613 has that problem too... makes it very challenging to debug! | 16:18 | |
| RP | Saur: making that function call fail should be an easy way to reproduce and debug the error handling itself. Doesn't solve your failure but would then help next time | 16:19 |
| Saur | RP: I'll see what I can come up with... | 16:20 |
| Saur | Should be easy enough to force some error to happen... | 16:20 |
| RP | Saur: Just put an "if PN = XX exit 1" into that function ;-) | 16:20 |
| RP | (into BUILDSPEC) | 16:21 |
| rfs613 | what's a good strategy for refreshing a patch (context lines need to be updated) when you can't touch the original layer? Can another layer replace individual patches? | 16:21 |
| JPEW | rfs613: If you are careful, but it can be fiddly | 16:22 |
| RP | rfs613: if you add a bbappend and add a new directory to the searchpath, yes | 16:22 |
| rfs613 | i've been trying to find documention to explain the search path ordering... if I use the same filename for the patch, will it take it from the higher priority layer? | 16:23 |
| Saur | rfs613: `devtool finish <recipe> <one of your layers>` will do it automatically for you. | 16:24 |
| RP | rfs613: there are example doing FILESEXTRAPATHS:prepend := "${THISDIR}/files:" in meta-poky | 16:25 |
| RP | rfs613: FILESPATH (via FILESEXTRAPATHS) works like a PATH search in shell | 16:26 |
| Saur | As long as you make sure your layer is earlier in the BBLAYERS variable than the original layer it should work. | 16:26 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 16:31 | |
| qschulz | rfs613: https://pretalx.com/media/yocto-project-summit-2021/submissions/WTT3UV/resources/Demystifying_the_OVERRIDES_mechan_no6J6fb.pdf I think I talked about this | 16:31 |
| qschulz | rfs613: you also have some slides in the bonus section about the selection algorithm | 16:32 |
| rfs613 | thanks everyone for the replies! I'm giving it a try now... | 16:34 |
| jclsn[m] | <otavio> "jclsn: if you're facing errors..." <- I already found the thread and you already saw I guess ;) | 16:36 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 16:47 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 16:49 | |
| *** lucaceresoli <lucaceresoli!~ceresoli@host-79-2-93-196.business.telecomitalia.it> has quit IRC (Quit: Leaving) | 16:57 | |
| rfs613 | qschulz: thanks, slide #79 is exactly what I was looking for... and for debugging, I also found it helpful to do 'bitbake -v -c do_patch pkgname'... it shows me each patch being applied, including path, so I can confirm it took the version from my layer and not the original layer. | 16:57 |
| rfs613 | Saur: minor item, I noticed devtool puts in "${THISDIR}/${PN}" whereas a lot of existing places use "${THISDIR}/files". Any particular reason to prefer one or the other? | 17:00 |
| qschulz | rfs613: it allows to have multiple recipes in the same directory | 17:00 |
| qschulz | and have patches/files for each recipe in logical directories | 17:01 |
| rfs613 | ok, gotcha | 17:01 |
| Saur | RP: If I revert fc58ad84a9deb2620ad90611684dad65dafedb11 in bitbake I get back the error logs. :) | 17:06 |
| RP | Saur: Hmm, of course it was me who did that and it looks like there was some other case where it did duplicate :( | 17:08 |
| RP | Saur: Would have been nice if I'd recorded the other case :/ | 17:08 |
| sgw | smurray: I updated the wiki with your name attached to the work RP has in -next so far. | 17:09 |
| sgw | Well never mind, looks like you got access and we collided! | 17:09 |
| smurray | sgw: heh, was just about to say I'd done that ;) | 17:09 |
| JPEW | Saur: What logs are missing? | 17:10 |
| RP | JPEW: it is the command output which was sent to the log file | 17:10 |
| JPEW | Hmm, I wouldn't expect that to be affected | 17:10 |
| sgw | smurray: are you going to work on the conversion script or shall I start on that. | 17:10 |
| smurray | sgw: if you have cycles atm, please start on it. If not, I can start working up something this evening | 17:11 |
| Saur | JPEW: See https://pastebin.com/Pt91PEXM With Hardknott, the content of .../build/build/tmp/work/<machine>-poky-linux/<recipe>/1.7.52-r0/temp/log.do_package_write_rpm.35734 is included in that error. Not so with Honister. | 17:12 |
| RP | Saur: you're saying the logfile itself didn't have it in either? | 17:14 |
| Saur | RP: No, the log.do_ file is there. | 17:15 |
| Saur | But it isn't in stdout/sterr of bitbake, and it is not in console-latest.log | 17:18 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 17:22 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.176> has quit IRC (Quit: Leaving.) | 17:22 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 17:23 | |
| sgw | smurray: Ok, starting on a script similar to others in scripts/contrib | 17:23 |
| *** frieder <frieder!~frieder@mue-88-130-64-089.dsl.tropolys.de> has quit IRC (Remote host closed the connection) | 17:25 | |
| smurray | sgw: yeah, that was going to be my starting point as well if I did it | 17:25 |
| RP | Saur: I have a vague memory of adding some logging tests for python and shell task failures. Not sure if that shows a regression with that change reverted or not? | 17:30 |
| Saur | RP: With bitbake -v and Hardknott I get the output twice, could that be the duplication you were trying to avoid? That said, I remember having error output show up twice (or maybe it was even thrice) before (and that was without bitbake -v). Not sure if that went away with Hardknott or if it was Honister. | 17:36 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 17:43 | |
| Saur | RP: I guess the tests you were referring to are commit 414020a9bd656ee61efe2f47db1b31d86b15c1c8 in meta. | 17:45 |
| RP | Saur: there was a separate change for the -v duplication issue :/ | 17:47 |
| RP | Saur: those tests are the ones I was thinking of, not sure how relevant they are. I did at least try and put some test cases in! | 17:48 |
| Saur | Yeah, I kind of guessed as I know I have had duplicated logs in the past, and I typically don't use bitbake -v. | 17:48 |
| *** huseyinkozan <huseyinkozan!~hk@31.223.46.227> has quit IRC (Quit: Konversation terminated!) | 17:49 | |
| Saur | RP: Hmm, bblogging.BitBakeLogging.test_shell_logging fails for me whether I have the test in bitbake/lib/bb/process.py or not. | 17:52 |
| Saur | And this is with poky without any of our own changes. | 17:53 |
| *** mckoan is now known as mckoan|away | 17:54 | |
| *** JrmeCarretero[m] <JrmeCarretero[m]!~cjzouglou@2001:470:69fc:105::1:8f50> has joined #yocto | 17:56 | |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC (Quit: Leaving) | 18:02 | |
| *** florian_kc <florian_kc!~florian@78.48.123.161> has joined #yocto | 18:05 | |
| RP | Saur: presumably that is passing on the autobuilder and for me locally so that is rather strange | 18:05 |
| moto-timo | kanavin: I see you already staged python3-pytest and python3-tomli upgrades... glad you figured out the src/tomli change | 18:08 |
| moto-timo | kanavin: python3-importlib-metadata 4.11.x dropped setup.py :/ | 18:09 |
| moto-timo | pedal faster! | 18:09 |
| kanavin | moto-timo, cheers, I trust you are meticulously working towards making those setup.py-less recipes work again :) | 18:10 |
| kanavin | tomli wasn't that hard, my cutoff time for this kind of thing is five minutes | 18:11 |
| *** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 18:13 | |
| *** unknown__ <unknown__!~creich@p200300f6af346e106be554d7e7588469.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving) | 18:14 | |
| *** creich <creich!~creich@p200300f6af346e106be554d7e7588469.dip0.t-ipconnect.de> has joined #yocto | 18:14 | |
| * RP wonders who is going to give in and sort that gstreamer test failure | 18:17 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 18:17 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 272 seconds) | 18:19 | |
| kanavin | RP: I just did | 18:19 |
| kanavin | Alex, the last resort guy | 18:19 |
| kanavin | (second-last I guess) | 18:20 |
| rfs613 | hmm, so now on a different recipe, i created a patch with devtool... but when trying to build the package, quilt fails to apply the patch ("No file to patch.") | 18:20 |
| RP | kanavin: ah, thanks! | 18:20 |
| RP | kanavin: I'm curious to see if your build sees the same mirror issues mine are seeing | 18:21 |
| RP | kanavin: I wasn't sure which of us would crack first on gstreamer :) | 18:21 |
| RP | kanavin: I "fixed" the ltp one | 18:21 |
| *** florian_kc <florian_kc!~florian@78.48.123.161> has quit IRC (Ping timeout: 252 seconds) | 18:22 | |
| kanavin | RP: I was hoping one of the gstreamer guys would send a followup :-/ | 18:23 |
| RP | kanavin: right, me too | 18:24 |
| Saur | RP: It appears I had BB_VERBOSE_LOGS = "1" in my configuration which affected those tests. | 18:24 |
| Saur | With that removed the tests pass. | 18:25 |
| Saur | And if I revert the change in process.py they fail... | 18:25 |
| rfs613 | ah, got it sorted... though it's odd, seems to be applying patch in a subdir of the repo, not at the top. | 18:25 |
| kanavin | RP: I know you aren't on linkedin much, but you should see this https://www.linkedin.com/posts/alexander-kanavin-94585686_remarkable-yocto-linux-activity-6899269502358683648-X54m | 18:26 |
| kanavin | RP: and yes, I sshd in, and it runs dunfell | 18:26 |
| *** bgreen0 <bgreen0!~bgreen0@38.133.97.72> has joined #yocto | 18:27 | |
| RP | Saur: well, I did document what I was fixing then :) | 18:28 |
| RP | Saur: that should help us find a way to fix this other case too | 18:28 |
| RP | kanavin: nice :). At least it is dunfell so supported too | 18:30 |
| RP | kanavin: I wonder if we should at that to the users list on the wiki? | 18:30 |
| bgreen0 | Hi. I have a question related to build reproducibility. I'm considering adding '-Wl,--build-id=none' to my compiler options because the the gnu build-id elf section is causing builds to differ when the build directory changes. The debug files are being thrown out for release builds anyway. I'm wondering if anyone knows of any potential | 18:31 |
| bgreen0 | downsides to removing this section altogether, when debuggability is not a factor? | 18:31 |
| *** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has joined #yocto | 18:32 | |
| bgreen0 | I'm using jethro (can't change) with some patches to support build reproducibility | 18:32 |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC (Ping timeout: 272 seconds) | 18:38 | |
| sgw | smurray: I ran my conversion script and noticed that you might have missed bitbake/lib/bb/siggen.py in your basehash/taskhash renames | 18:38 |
| sgw | Oh, never mind, I think that's the conversion code being overly agressive! | 18:39 |
| Saur | RP: On a totally unrelated note: you integrated most of my changes related to \n in mirror variables, but there are two patches sent to the poky list that are still not integrated (and there is one for the documentation too, but I guess I should ping Michael about that one). | 18:40 |
| RP | Saur: sorry, I must have missed the poky ones | 18:41 |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 18:42 | |
| Saur | No worries. Easy to do I guess when the changes are spread over three different repos and mailing lists. | 18:42 |
| RP | Saur: merged | 18:42 |
| Saur | :) | 18:42 |
| RP | Saur: please remind michaelo about the other one | 18:43 |
| Saur | Will do. | 18:43 |
| sgw | RP: I think you missed a meta-poky patch to poky-tiny in master-next | 18:43 |
| smurray | sgw: I'm a bit puzzled, I'd figure a conversion script would just be using the uppercase metadata variable names? The references in siggen.py in master-next are the internal variable name tweaking for signature compatibility | 18:44 |
| RP | sgw: well spotted, yes. queued for testing | 18:44 |
| sgw | RP: found with my conversion script ! | 18:44 |
| RP | sgw: handy | 18:45 |
| sgw | smurray: it's also looking for whitelist/blackslist | 18:45 |
| sgw | not changing them since they are context sensitive | 18:45 |
| sgw | smurray: sent you a early version to direction check. RP, I will push a WIP to the list before noon here. | 18:46 |
| smurray | sgw: as a prod for users to change language in their own layers? or for some form of CI? I figured we'd just be making a script that updated metadata so it'd work, a la the override syntax script | 18:47 |
| sgw | yes, as a prod, the problem is we have also removed some variables that can just convert, so it flags those also. | 18:47 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 18:48 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 18:48 | |
| smurray | sgw: I'm not convinced it's necessarily useful per se, but I'll take a look. It'd not work for e.g. "abort" necessarily, as I think there a couple of instances in toaster that are to functions in external libraries | 18:51 |
| sgw | smurray: That's true, this is a first pass, we can fine tune, it does not changes those, just inform. | 18:51 |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-123-161.78.48.pool.telefonica.de> has joined #yocto | 18:52 | |
| sgw | well meta-openembedded is looking relatively good, 80 forbidden words, and 12 recipes that the script changed (I think correctly)! | 19:01 |
| RP | sgw: we probably have a lot more conversions to go though! | 19:04 |
| sgw | Oh yes, just wanted to get the script started and testing, about to send it to oe-core list | 19:10 |
| sgw | Work@wr6 | 19:11 |
| sgw | oops! | 19:11 |
| otavio | sgw: every one does this once in a life ;) | 19:11 |
| sgw | Or more than once in my case, but it's been a while since the last one! | 19:12 |
| *** bluelightning <bluelightning!~paul@2406:e003:151f:d701:3c8a:ef64:4e89:8b20> has joined #yocto | 19:16 | |
| Saur | RP: I'm looking at the second test in bblogging.BitBakeLogging.test_shell_logging test, which corresponds to my case. When I look at the output returned by the bitbake() function it contains the error log and the test passes. However, if I look at the corresponding log that was stored in qemux86-64-selftest-st/tmp/log/cooker/qemux86-64 it does _not_ contain the error output... | 19:17 |
| RP | Saur: sounds like a bug | 19:18 |
| rfs613 | Over on cve.mitre.org I see some notices about upcoming changes to JSON format as well as the CVE List downloads... which will presumably affect cve-checker. | 19:28 |
| rfs613 | https://www.cve.org/Media/News/item/news/2022/01/11/Changes-Coming-to-CVE-Record | 19:30 |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds) | 19:35 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 19:40 | |
| *** marc2 <marc2!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has quit IRC (Quit: WeeChat 3.4) | 19:51 | |
| *** marc1 <marc1!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has joined #yocto | 19:57 | |
| *** amitk <amitk!~amit@103.59.74.32> has quit IRC (Ping timeout: 252 seconds) | 19:58 | |
| *** Bardon_ <Bardon_!~Bardon@user/Bardon> has joined #yocto | 19:59 | |
| *** Bardon <Bardon!~Bardon@user/Bardon> has quit IRC (Ping timeout: 272 seconds) | 19:59 | |
| *** dacav <dacav!~dacav@h94-245-9-196.cust.a3fiber.se> has quit IRC (Quit: leaving) | 20:01 | |
| *** dacav <dacav!~dacav@h94-245-9-196.cust.a3fiber.se> has joined #yocto | 20:01 | |
| *** dacav <dacav!~dacav@h94-245-9-196.cust.a3fiber.se> has quit IRC (Client Quit) | 20:02 | |
| *** dacav <dacav!~dacav@h94-245-9-196.cust.a3fiber.se> has joined #yocto | 20:02 | |
| *** dacav <dacav!~dacav@h94-245-9-196.cust.a3fiber.se> has quit IRC (Client Quit) | 20:04 | |
| *** dacav <dacav!~dacav@h94-245-9-196.cust.a3fiber.se> has joined #yocto | 20:04 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-123-161.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 272 seconds) | 20:10 | |
| *** dev1990 <dev1990!~dev@78.8.203.136> has quit IRC (Quit: Konversation terminated!) | 20:14 | |
| *** dev1990 <dev1990!~dev@78.8.203.136> has joined #yocto | 20:15 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds) | 20:15 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 20:17 | |
| RP | rfs613: sounds like we need to be ready with a patch to fix something :/ | 20:19 |
| RP | sgw: "descriptive" isn't going to work as naming/description for this script ;-) | 20:25 |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-123-161.78.48.pool.telefonica.de> has joined #yocto | 20:30 | |
| RP | smurray, sgw: I've tweaked master-next a bit based on various patches around and added the core renames to bitbake.conf | 20:35 |
| RP | sgw: surprisingly only two failures on oe-selftest on the first autobuilder run. I've stopped that one and started on the new series | 20:37 |
| RP | well, once sakoman and kanavin's builds finish with the workers I let go :) | 20:37 |
| rfs613 | RP: surely there's some AI or similar that can take care of this automatically, no? :P | 20:38 |
| RP | kanavin: your build was nearly worse than the inclusive language one | 20:38 |
| RP | rfs613: you are kidding? ;-) | 20:38 |
| rfs613 | RP: and where are the flying cars we were promised ;_) | 20:39 |
| JPEW | rfs613: https://xkcd.com/2173/ | 20:39 |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 20:40 | |
| RP | JPEW: :) | 20:42 |
| *** drewfustini <drewfustini!sid284109@id-284109.helmsley.irccloud.com> has left #yocto | 20:48 | |
| smurray | sgw: looking at your script, I don't think there's value checking for basewhitelist & taskwhitelist, AFAICT they're internal BitBake variables that nothing in oe-core at least tries to dig in to modify. The associated metadata variables are for changing their values... | 20:54 |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 21:00 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds) | 21:01 | |
| *** camus1 is now known as camus | 21:01 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds) | 21:02 | |
| kanavin | pro tip: if you want webkitgtk patches to be looked at by upstream, set 'component' in the bug tracker to webkitgtk | 21:03 |
| kanavin | otherwise, they'll be seen as 'generic bugs' that no one looks at | 21:04 |
| kanavin | I finally got movement with those patch submissions :) | 21:04 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds) | 21:06 | |
| *** bgreen0 <bgreen0!~bgreen0@38.133.97.72> has quit IRC (Quit: Client closed) | 21:06 | |
| *** aleblanc[m] <aleblanc[m]!~aleblancm@2001:470:69fc:105::1:c14f> has joined #yocto | 21:07 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-123-161.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 256 seconds) | 21:09 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 21:11 | |
| *** GillesM <GillesM!~gilles@135.65.132.77.rev.sfr.net> has quit IRC (Quit: Leaving) | 21:17 | |
| moto-timo | 🎉 | 21:20 |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 256 seconds) | 21:20 | |
| vd | do you have a valid scenario for a distro extending MACHINE_EXTRA_RDEPENDS/RRECOMMENDS or that is outrageous? | 21:22 |
| smurray | vd: we do for a few machines in AGL for things like where the BSP doesn't include some firmware dependencies that likely all users of a board would want | 21:28 |
| vd | hum I see | 21:29 |
| vd | that might fit with my usecase | 21:29 |
| smurray | vd: the rationale in AGL might be easier as downstream may not use any of the provided images, even as a base | 21:30 |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-123-161.78.48.pool.telefonica.de> has joined #yocto | 21:31 | |
| smurray | vd: but our visibility into what downstream auto folks actually do with it is very limited | 21:32 |
| vd | smurray: often bsp layers default to a simple boot mechanism, e.g. having the kernel in IMAGE_BOOT_FILES or in the rootfs with MACHINE_ESSENTIAL_EXTRA_RDEPENDS. But the thing is that the boot mechanism is often a distro choice, e.g. I might want to have redundant rootfs partitions which include the kernel and only the bootloader in the boot partition. | 21:33 |
| RP | kanavin: nice. I'm still waiting/hoping on the libtool ones! | 21:34 |
| vd | smurray: this is where the distro/machine glue needs to tweak one or the other and OE-Core enforces no strong practices on this, unless I'm mistaken | 21:35 |
| smurray | vd: yeah, that gets hazy. BSP folks want to be able to show something like core-image-minimal (or their own demo image) boots, so they provide configuration | 21:35 |
| vd | well core-image-minimal is indeed meant to showcase a machine while core-image-base is meant to showcase the base of a distro | 21:37 |
| vd | thanks to packagegroup-core-boot and packagegroup-distro-base, assuming they are properly configured | 21:38 |
| vd | (via MACHINE/DISTRO_*EXTRA_*) | 21:38 |
| kanavin | RP: yeah, I was wondering why none of the webkit patches I submitted 3 months ago are moving forward - but once I did the self-triage and assigned to 'webkitgtk', I got attention within minutes! | 21:42 |
| RP | kanavin: I wish libtool were that simple :) | 21:42 |
| RP | kanavin: we are making steady progress on the patch stats though | 21:43 |
| vd | smurray: you are relying on multiconfigs so far for the distro/machine glue, aren't you? | 21:44 |
| *** Guest20 <Guest20!~Guest20@modemcable211.232-19-135.mc.videotron.ca> has quit IRC (Quit: Connection closed) | 21:45 | |
| smurray | vd: no, there's a setup script that generates the configuration, as most folks target a single hardware target of the bunch AGL supports. There's some minimal multiconfig use in AGL, but it's for some non-default experimental system container stuff | 21:46 |
| kanavin | RP: yes, I'm looking at those weekly stats too, they go down as previously submitted things get dropped on upgrades | 21:47 |
| kanavin | now how do I squeeze in my revised patchbomb between all those Important Builds :-/ | 21:48 |
| smurray | vd: there are enough BSP layers that just bbappend random things that trying to make them work together in a single bblayers.conf has been considered out of scope for AGL | 21:48 |
| kanavin | RP: one trick is to jump out of bed at 6am, start a-full, then fall back and snooze for another 3 hours :-/ | 21:48 |
| *** chrfle <chrfle!~chrfle@217-209-195-249-no206.tbcn.telia.com> has left #yocto (Leaving) | 21:49 | |
| vd | smurray: making them work all nicely together is indeed possible but it takes a while to figure out how to integrate nicely. Unfortunately quick and dirty hacks like IMAGE_INSTALL:append in bsp layers is often chosen instead | 21:52 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 21:52 | |
| vd | smurray: having machine or distro variants (requiring a base config) is not the best but still a good way to isolate machine/distro glue | 21:54 |
| smurray | vd: that's more difficult with vendor BSP layers that have somewhat non-functional upstreams | 22:00 |
| vd | smurray: it's a good reason for adding a new machine requiring the broken upstream one in your downstream bsp layer, don't you think? | 22:04 |
| smurray | vd: I'm not sure I follow, include/require means using in the upstream layer, so you still get it's baggage you may not want. If you mean redefining MACHINE* in your own machine, sure | 22:06 |
| *** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection) | 22:06 | |
| vd | smurray: an example that comes to mind is having a gpu-friendly machine (e.g. beaglebone black) with accelerated graphics, while the upstream 'beaglebone' machine doesn't enable their drivers by default. One may add the necessary PREFERRED_PROVIDER* in their distro (or local.conf), or define a new machine require beaglebone.conf | 22:07 |
| vd | another example is chosing a different bootloader for your use case | 22:07 |
| vd | smurray: are you saying that you don't even rely on the upstream machine definition and create your own from scratch? like beaglebone-yocto from meta-yocto-bsp (which doesn't use meta-ti) | 22:08 |
| smurray | vd: we (AGL) rely on them, yes. It wasn't clear to me what you meant. I gathered you mean defining your own | 22:08 |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-123-161.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 250 seconds) | 22:10 | |
| RP | kanavin: queue it up, the AB will get to it overnight | 22:10 |
| kanavin | RP: right, I have this idea that starting another a-full will make already running a-fulls slower, so I tend to wait for a quiet moment | 22:11 |
| vd | should the kernel-modules package be added with RRECOMMENDS like other kernel-module-* packages or RDPENDS? | 22:13 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 22:14 | |
| RP | kanavin: yes and no. I'd prefer not to get the system too backlogged but.... | 22:23 |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4b12:b100:24d7:51ff:fed6:906d> has quit IRC (Quit: Leaving) | 22:34 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC (Ping timeout: 256 seconds) | 22:39 | |
| *** nsbdfl <nsbdfl!nsfbdl@user/nsbdfl> has joined #yocto | 23:05 | |
| *** dev1990 <dev1990!~dev@78.8.203.136> has quit IRC (Quit: Konversation terminated!) | 23:07 | |
| *** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 240 seconds) | 23:07 | |
| sgw | RP: are you OK with all the oe-core renames in one commit or do you want them broken down to groups like CVE* / SDK*/ ... | 23:21 |
| sgw | RP, nm you already did in oe-core master-next! | 23:23 |
| *** awafaa <awafaa!sid716@id-716.uxbridge.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** awafaa <awafaa!sid716@id-716.uxbridge.irccloud.com> has joined #yocto | 23:35 | |
| *** YogeshSiraswar_ <YogeshSiraswar_!sid500596@id-500596.uxbridge.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** halstead <halstead!sid505447@id-505447.ilkley.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** YogeshSiraswar_ <YogeshSiraswar_!sid500596@id-500596.uxbridge.irccloud.com> has joined #yocto | 23:35 | |
| *** halstead <halstead!sid505447@id-505447.ilkley.irccloud.com> has joined #yocto | 23:35 | |
| *** shivamurthy <shivamurthy!sid359794@id-359794.helmsley.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** dl9pf <dl9pf!sid395223@id-395223.helmsley.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** praneeth <praneeth!sid506451@id-506451.tinside.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** paulbarker <paulbarker!sid269702@id-269702.hampstead.irccloud.com> has quit IRC (Ping timeout: 252 seconds) | 23:35 | |
| *** CosmicPenguin <CosmicPenguin!sid489106@id-489106.uxbridge.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** ldts <ldts!sid269548@hampstead.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** xtopher_ <xtopher_!sid495823@id-495823.tinside.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** praneeth <praneeth!sid506451@id-506451.tinside.irccloud.com> has joined #yocto | 23:35 | |
| *** dl9pf <dl9pf!sid395223@id-395223.helmsley.irccloud.com> has joined #yocto | 23:35 | |
| *** ndec <ndec!sid219321@id-219321.tinside.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** CosmicPenguin <CosmicPenguin!sid489106@id-489106.uxbridge.irccloud.com> has joined #yocto | 23:35 | |
| *** rburton <rburton!rburton@user/rburton> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** jamestperk <jamestperk!sid520428@id-520428.tinside.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** georgem <georgem!sid210681@id-210681.tinside.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** fancer <fancer!fancer@id-180736.tinside.irccloud.com> has quit IRC (Write error: Connection reset by peer) | 23:35 | |
| *** xtopher_ <xtopher_!sid495823@id-495823.tinside.irccloud.com> has joined #yocto | 23:35 | |
| *** ernstp <ernstp!sid168075@id-168075.hampstead.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** thierryE <thierryE!sid286446@id-286446.lymington.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** ndec <ndec!sid219321@id-219321.tinside.irccloud.com> has joined #yocto | 23:35 | |
| *** darknighte <darknighte!sid214177@user/darknighte> has quit IRC (Read error: Connection reset by peer) | 23:35 | |
| *** ChanServ sets mode: +v ndec | 23:36 | |
| *** rburton <rburton!rburton@user/rburton> has joined #yocto | 23:36 | |
| *** jamestperk <jamestperk!sid520428@id-520428.tinside.irccloud.com> has joined #yocto | 23:36 | |
| *** shivamurthy <shivamurthy!sid359794@id-359794.helmsley.irccloud.com> has joined #yocto | 23:36 | |
| *** paulbarker <paulbarker!sid269702@id-269702.hampstead.irccloud.com> has joined #yocto | 23:36 | |
| *** darknighte <darknighte!sid214177@user/darknighte> has joined #yocto | 23:36 | |
| *** thierryE <thierryE!sid286446@id-286446.lymington.irccloud.com> has joined #yocto | 23:36 | |
| *** ldts <ldts!sid269548@2a03:5180:f:4::4:1cec> has joined #yocto | 23:36 | |
| *** fancer <fancer!fancer@2a03:5180:f::2:c200> has joined #yocto | 23:37 | |
| *** georgem <georgem!sid210681@id-210681.tinside.irccloud.com> has joined #yocto | 23:37 | |
| *** ernstp <ernstp!sid168075@id-168075.hampstead.irccloud.com> has joined #yocto | 23:37 | |
| *** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Remote host closed the connection) | 23:38 | |
| *** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has joined #yocto | 23:38 | |
| *** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Remote host closed the connection) | 23:49 | |
| *** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has joined #yocto | 23:52 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-123-161.78.48.pool.telefonica.de> has joined #yocto | 23:53 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!