Wednesday, 2022-02-16

smurrayRP: okay, I'm about to check out for the evening, but can take a whack at it tomorrow00:01
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)00:03
RPOh, 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 live00:03
* RP can live with a couple of duplicate lines00:03
RPsgw, smurray: the above commit should apply on top of the bitbake changes in master-next and be usable from there00:04
sgwLooking at this time.00:05
smurrayRP: 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
smurrayerr, would the plan be to have variables...00:06
sgwI 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
RPsmurray: 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 variable00:10
smurrayRP: okay00:10
RPsmurray: we need the bitbake ones in bitbake so it can scan the enviroment and bail early for those00:10
smurrayRP: yeah, I was more thinking about whether we'd need to carry a list of the OE ones in BitBake00:11
RPsmurray: we shouldn't have to00:12
RPI think these changes address issues 1+2 in my email. 3 remains and 4 is maybe partly handled00:13
* RP has best try and sleep00:14
*** superdupond <superdupond!> has quit IRC (Ping timeout: 252 seconds)00:14
*** florian <florian!> has quit IRC (Ping timeout: 252 seconds)00:26
*** prabhakarlad <prabhakarlad!> has quit IRC (Ping timeout: 256 seconds)00:45
*** jqua[m] <jqua[m]!~quaresmam@2001:470:69fc:105::1:2faa> has joined #yocto01:01
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 252 seconds)01:12
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)01:16
*** jclsn7 <jclsn7!> has joined #yocto01:18
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 252 seconds)01:23
*** jclsn7 <jclsn7!> has joined #yocto01:29
*** qschulz <qschulz!> has quit IRC (Quit: qschulz)01:32
*** mckoan|away <mckoan|away!> has quit IRC (Ping timeout: 240 seconds)01:32
*** qschulz <qschulz!> has joined #yocto01:35
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 252 seconds)01:36
*** mckoan|away <mckoan|away!> has joined #yocto01:39
*** jclsn7 <jclsn7!> has joined #yocto01:41
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 252 seconds)01:49
*** jclsn7 <jclsn7!> has joined #yocto01:55
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)01:56
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 272 seconds)02:10
*** jclsn7 <jclsn7!> has joined #yocto02:13
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 272 seconds)02:24
*** sakoman <sakoman!> has joined #yocto02:29
*** jclsn7 <jclsn7!> has joined #yocto02:30
*** RobertBerger <RobertBerger!~rber|> has joined #yocto02:32
*** rber|res <rber|res!~rber|> has quit IRC (Ping timeout: 252 seconds)02:34
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 240 seconds)02:38
*** jclsn7 <jclsn7!> has joined #yocto02:43
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 252 seconds)02:48
*** jclsn7 <jclsn7!> has joined #yocto02:54
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 252 seconds)02:59
*** jclsn7 <jclsn7!> has joined #yocto03:04
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 252 seconds)03:09
*** jclsn7 <jclsn7!> has joined #yocto03:16
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 240 seconds)03:25
*** jclsn7 <jclsn7!> has joined #yocto03:27
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 252 seconds)03:34
*** jclsn7 <jclsn7!> has joined #yocto03:40
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 272 seconds)03:51
*** amitk <amitk!~amit@> has joined #yocto03:51
*** jclsn7 <jclsn7!> has joined #yocto03:56
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 240 seconds)04:04
zeddiikhem: I'll have a look at it on Wednesday, that's for the heads up.04:07
*** jclsn7 <jclsn7!> has joined #yocto04:10
*** silvermane <silvermane!~silverton@> has joined #yocto04:22
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:29
zeddiiok. I identified the commit upstream, it's 5.15.17+, I have it ready and will send tomorrow04:33
*** silvermane <silvermane!~silverton@> 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 #yocto05:10
*** xmn <xmn!> has joined #yocto05:35
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:58
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)05:59
*** jclsn77 <jclsn77!> has joined #yocto06:08
*** RobertBerger <RobertBerger!~rber|> has quit IRC (Remote host closed the connection)06:09
*** rber__ <rber__!~rber|> has joined #yocto06:09
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 240 seconds)06:10
*** jclsn77 is now known as jclsn706:10
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Ping timeout: 240 seconds)06:22
*** Wouter0100 <Wouter0100!> has quit IRC (Remote host closed the connection)06:31
*** Wouter0100 <Wouter0100!> has joined #yocto06:31
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 250 seconds)06:33
*** davidinux <davidinux!~davidinux@> has joined #yocto06:35
*** GillesM <GillesM!> has joined #yocto07:11
*** GillesM <GillesM!> has quit IRC (Client Quit)07:16
*** GillesM <GillesM!> has joined #yocto07:16
*** GillesM <GillesM!> has quit IRC (Client Quit)07:17
*** GillesM <GillesM!> has joined #yocto07:18
*** mvlad <mvlad!~mvlad@2a02:2f08:4b12:b100:24d7:51ff:fed6:906d> has joined #yocto07:19
*** rob_w <rob_w!> has joined #yocto07:21
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:39
*** lucaceresoli <lucaceresoli!> has joined #yocto07:39
*** frieder <frieder!> has joined #yocto07:46
*** vladest <vladest!~Thunderbi@2a02:1210:3083:2200:cfde:5c2:4bfe:a30e> has quit IRC (Quit: vladest)07:46
*** frieder <frieder!> has quit IRC (Remote host closed the connection)07:46
*** frieder <frieder!> has joined #yocto07:46
*** Etheryon <Etheryon!~Etheryon@> has joined #yocto07:47
jclsn[m]Morning guy07:56
jclsn[m]Is anyone experienced with Chromium? It just doesn't run and I have no idea where to start07:56
jclsn[m]Ask in #chromium or something?07:56
jclsn[m]* to start debugging07:57
jclsn[m]Here is the output... (full message at
*** zpfvo <zpfvo!~fvo@> has joined #yocto07:59
*** vladest <vladest!~Thunderbi@2a02:1210:3083:2200:64b1:3011:5628:6e5b> has joined #yocto07:59
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 272 seconds)08:11
*** dev1990 <dev1990!~dev@> has joined #yocto08:12
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto08:12
*** rfuentess <rfuentess!> has joined #yocto08: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:
*** mckoan|away is now known as mckoan08:31
qschulzziga_: oe-pkgdata-util find-path '*modetest*'08:33
qschulzlibdrm-tests I think it is08: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
LetoThe2ndyo dudX08:37
mckoangood morning08:37
qschulzziga_: you need to install the libdrm-tests package in your image08:38
qschulzmornin' :)08:39
ziga_@qschulz How did you know this? I did read about this package on other distributions - here: but then I wasn't able to find it inside the Open Embedded layer index ( and I thought that it does not exist.08:40
qschulzziga_: 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 things08:41
qschulzziga_: when you install libdrm, you install the main package, but there are others too08:41
ziga_I understand. I meant: "I wasn't able to find "libdrm-tests" recipe in the Open Embedded Layer index.08:42
qschulzoe-pkgdata-util find-paht returns the name of the package containing the files you are looking for08:42
qschulzziga_: you cannot, because the OpenEmbedded layer index returns stable "objects"08:42
qschulza recipe, a class, a layer, a machine are all "stable"08:43
qschulzbut a package isn't08:43
qschulzbecause a package can or can not be built depending on the distribution, bbappends, machines, etc...08:43
qschulzwhich 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 is08:43
jclsn[m]If `` 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
qschulzjclsn[m]: libraries aren't from drivers. So you're missing a package that installs this library. oe-pkgdata-util find-path '*libvivante*'08:46
qschulzziga_: you can find recipes with the OE Layer Index08:46
qschulzyou can NOT find packages with the OE Layer Index08:46
jclsn[m]qschulz: I just searched for '*libvivante*' in root. There is nothing08:47
qschulzjclsn[m]: in root? root of what? where?08:47
jclsn[m]Ah you mean in bitbake08:47
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:47
jclsn[m]qschulz: On the board08:48
jclsn[m]oe-pkgdata-util also finds nothing08: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
qschulzjclsn[m]: if oe-pkgdata-util finds nothing, then it means the recipe creating this library hasn't been built08:48
jclsn[m]The desktop environment is horribly slow. I am assuming that there is no graphics driver present at all08:48
*** lucaceresoli_ <lucaceresoli_!> has joined #yocto08:48
qschulzziga_: no.08:48
jclsn[m]qschulz: Okay08:49
qschulzjclsn[m]: libvivante is proprietary sw also, etnaviv is the open-source alternative08:49
qschulz(just FYI)08:49
jclsn[m]The driver should be part of the kernel actually08:49
qschulzI can't help much more for now08:49
jclsn[m]qschulz: I know but our collegues want Vivante08:50
jclsn[m]Everyone is telling me not to use it though08:50
qschulzjclsn[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 vivante08:50
qschulzjclsn[m]: don't remember which NXP SoC you're using08:50
qschulzbut 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 integration08:51
qschulzI only had vivante running on the imx8mm08:52
jclsn[m]I know08:52
jclsn[m]They are just worried about performance08:52
qschulzit's imx-gpu something recipe08:52
qschulzjclsn[m]: also, etnaviv is supported for imx8mm only from 5.4 and mesa 20 or 21 don't remember exactly08:52
qschulzso if you're stuck on a super old kernel, the answer is pretty straightforward08:53
qschulzziga_: libdrm-tests is the package you need to install08:53
jclsn[m]5.10 here08:53
jclsn[m]imx-gpu-viv it is08:53
qschulzziga_: if oe-pkgdata-util find-path returns something, it means this package was built08:53
*** tnovotny <tnovotny!> has joined #yocto08:53
qschulzjclsn[m]: the GPU stuff is hairy in meta layers for NXP SoCs...08:54
qschulzso be extra super duper sure the MACHINEOVERRIDES, SOC_FAMILY and all are correctly set08:54
qschulzziga_: 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
qschulzziga_: you'll see that libdrm is the recipe which creates the libdrm-tests package08: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 override08:56
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto08:56
qschulzjclsn[m]: no no no08:57
qschulzjclsn[m]: you setup your machine to have the correct MACHINEOVERRIDES and you're settled08:57
qschulz(so yes to the last sentence actually :) )08:57
qschulzbut look how the other machines are created08:57
*** lucaceresoli_ <lucaceresoli_!> has quit IRC (Ping timeout: 240 seconds)08:57
qschulzand either include one machine conf file which is close enough to yours, or take inspiration from it08:58
*** prabhakarlad <prabhakarlad!> has joined #yocto08:59
jclsn[m]qschulz: But how would I add my device tree then? It is our custom board after all09:00
*** rfuentess <rfuentess!> 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 only09: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
qschulzziga_: 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
qschulzziga_: if there is no package providing the file 1) either the recipe was misconfigured, 2) or the recipe was not built yet09:03
qschulzthis 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 it09:03
qschulzbuild it, if no package still09:03
qschulzthen you need to look into the recipe if something needs to be adapted/fixed09: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
qschulzif no recipe, then ask here probably? otherwise create yours09:05
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 252 seconds)09:07
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 252 seconds)09:08
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:08
qschulzjclsn[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 want09:08
qschulznote that MACHINEOVERRIDES should contain MACHINE (the name of your machine configuration file without the .conf) and have it have the highest precedence09: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 to09:14
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto09:14
jclsn[m]Atm our machine configuration is based on imx8mm-evk-lpddr4 though09:14
qschulzjclsn[m]: look at what this machine configuration file does then and include the thing you need09:14
qschulzand adapt MACHINEOVERRIDES accordingly09:15
jclsn[m]MACHINEOVERRIDES are "imx-boot-container:mx8:mx8m:mx8mm:"09:15
jclsn[m]So no idea why bitbake thinks it is our board09:16
*** florian <florian!> has joined #yocto09:16
jclsn[m]I have only set our MACHINE in local.conf09:16
jclsn[m]had to add this for the kernel for example09:17
jclsn[m]COMPATIBLE_MACHINE = "(mx6|mx7|mx8|vti2)"09:17
jclsn[m]Else it wouldn't build09:17
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)09:18
*** woky <woky!> has quit IRC (Quit: Nothing in this world is hopeless!)09:20
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)09:20
*** woky <woky!> has joined #yocto09:21
*** woky <woky!> has quit IRC (Remote host closed the connection)09:21
*** woky <woky!> has joined #yocto09:22
qschulzjclsn[m]: what was the original value for COMPATIBLE_MACHINE in the kernel recipe?09:28
qschulzjclsn[m]: how did you check the MACHINEOVERRIDES content?09:28
jclsn[m]qschulz: mx809:29
jclsn[m]I did check them some time ago using `bitbake -e | grep MACHINEOVERRIDES` I think09:29
jclsn[m]`vti2` was added by default. You actually told me that09:30
qschulzjclsn[m]: your machine name is missing from it, it should be the rightmost entry in the colon separated list09:30
jclsn[m]I am pretty sure you told me not to add it because it is added by default09:30
qschulzjclsn[m]: yes09:30
qschulznot add it MANUALLY :)09:31
qschulzso wild guess right now, you are reassigning MACHINEOVERRIDES instead of prepending/appending to it09:31
qschulzhow is MACHINEOVERRIDES variable modified in your machine configuration file09:31
jclsn[m]This is MACHINEOVERRIDES line from the our vti2.conf, which is our custom machine configuration file09:32
qschulz(though it should work just fine with the MACHINEOVERRIDES above if COMPATIBLE_MACHINE has mx8 in them..09:32
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:33
jclsn[m]Got this though09:33
jclsn[m]imx-gpu-viv was skipped: incompatible with machine vti2 (not in COMPATIBLE_MACHINE)09:33
qschulzjclsn[m]: what is the line your vti2.conf for MACHINEOVERRIDES variable09:33
jclsn[m]And it is weird that this recipe wasn't built in the first place09:33
jclsn[m]qschulz: The one I sent you above09:33
qschulzjclsn[m]: ther'es no operator in the line you have me09:35
jclsn[m]MACHINEOVERRIDES =. "imx-boot-container:mx8:mx8m:mx8mm:"09:36
qschulzjclsn[m]: and before any include right? seems about right, if you check with bitbake -e some-recipe | grep ^MACHINEOVERRIDES=, you should have vti2 in there09:37
jclsn[m]qschulz: It is in there09:38
jclsn[m]I am currently building chromium though09:39
jclsn[m]I just wonder why the recipes are only being passed vti209:39
jclsn[m]mx8 should also be passed, shouldn't it?09:39
*** florian <florian!> has quit IRC (Ping timeout: 250 seconds)09:40
*** m4ho <m4ho!~m4ho@> has quit IRC (Read error: Connection reset by peer)09:40
jclsn[m]It is tedious to add vti2 to COMPATIBLE_MACHINE in every recipe09:40
jclsn[m]CONFIG_MXC_GPU_VIV is also not added in the linux-fslc-imx defconfig09:41
jclsn[m]I still don't understand this kernel recipe fully09:41
qschulzjclsn[m]: kernel recipes are often complex so it's not surprise, it takes me time every time too09:42
qschulzjclsn[m]: I've seen some COMPATIBLE_MACHINE:machine = "machine" in some recipes, so you might be missing yours09:42
qschulzhonestly I don't know09:42
jclsn[m]qschulz: This one is especially hard though because it is a kernel that is patched together from mainline and linux-imx09:43
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)09:43
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)09:53
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:53
*** m4ho <m4ho!> has joined #yocto09:57
*** zpfvo <zpfvo!~fvo@> has joined #yocto09: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@> has quit IRC (Ping timeout: 250 seconds)10:02
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:02
*** dsueiro <dsueiro!~dsueiro@> has quit IRC (Quit: Client closed)10:02
*** huseyinkozan <huseyinkozan!~hk@> has joined #yocto10:08
qschulzjclsn[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't10:10
jclsn[m]Okay thanks10:11
*** florian <florian!> has joined #yocto10:20
EtheryonHello, 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 RO10:31
LetoThe2ndEtheryon: adding read-only-rootfs to IMAGE_FEATURES should do the trick.10:36
*** chep` <chep`!> has joined #yocto10:39
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)10:39
*** chep <chep!> has quit IRC (Read error: Connection reset by peer)10:40
*** chep` is now known as chep10:40
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds)10:43
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)10:48
*** florian_kc <florian_kc!> has joined #yocto10:49
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:49
*** Etheryon <Etheryon!~Etheryon@> has quit IRC (Quit: Client closed)10:51
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 252 seconds)11:08
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:09
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)11:09
*** woky <woky!> has quit IRC (Quit: Nothing in this world is hopeless!)11:16
*** snapsd49 <snapsd49!> has joined #yocto11:16
snapsd49can I trigger a recipe build from another recipe (possibally from do_compile)?11:17
*** woky <woky!> has joined #yocto11:18
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)11:18
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto11:19
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:19
RPsnapsd49: you can add a dependency?11:20
LetoThe2ndsnapsd49: nope.11:20
snapsd49I am getting what packages my recipe depends on after unpack task.. so need to build those pcakges11:20
snapsd49so can't set in as RDEPENDS .. as dependencies are not known when I run bitbake xyz.recipe11:21
LetoThe2ndsnapsd49: it doesn't work that way, sorry.11:21
RPsnapsd49: as LetoThe2nd says, you can't do that dynamically11:21
LetoThe2ndsnapsd49: meta data must be constructed in a way so all the dependencies can be calculated without running any tasts.11:22
LetoThe2ndtasks, even.11:22
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 252 seconds)11:23
*** pgowda_ <pgowda_!> has joined #yocto11:23
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:24
snapsd49okay, thanks.. that's what I was wondering.. for any recipe, the metadata / depchain is constructed before executing any task..11:24
snapsd49so any workaround / hack to add dependencies dynamically? or building packages?11:24
snapsd49so any workaround / hack to add dependencies dynamically? or building packages dynamically from recipe?11:24
LetoThe2ndsnapsd49: 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!> has quit IRC (Read error: Connection reset by peer)11:27
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)11:28
snapsd49LetoThe2nd - 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@> has joined #yocto11:29
LetoThe2ndsnapsd49: i think you have some thinking to do then.11:29
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)11:30
*** Etheryon <Etheryon!~Etheryon@> has joined #yocto11:32
EtheryonI'd like it to be read-write11:32
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)11:33
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:34
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)11:43
qschulzEtheryon: then make sure this is not added anywhere11:43
qschulzEtheryon: also make sure you're not using squashfs for the root filesystem11:44
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:44
*** tnovotny <tnovotny!> has joined #yocto11:49
*** Etheryon <Etheryon!~Etheryon@> has quit IRC (Quit: Client closed)11:49
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto11:50
chrflehello, 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@> has joined #yocto12:01
*** Kaa <Kaa!~Kaa@> has joined #yocto12: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 _append12:26
LetoThe2ndqschulz: ya but thats hard to avoid if you're outputting ISO12:27
*** snapsd49 <snapsd49!> has quit IRC (Quit: Ping timeout (120 seconds))12:36
KaaDoes anybody think that the current behavior of INITRAMFS_IMAGE_BUNDLE is weird? Linux image goes to initramfs and initramfs goes to Linux image :D12:47
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)13:03
*** Etheryon <Etheryon!~Etheryon@> has joined #yocto13:04
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:04
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 252 seconds)13:13
*** superdupond <superdupond!> has joined #yocto13:13
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:14
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 252 seconds)13:18
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:18
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto13:21
EtheryonIMAGE_FSTYPES = "iso" would do this? I've looked through env and couldn't find any read-only-rootfs13:26
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)13:28
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:28
jclsn[m]qschulz: I still don't get it sorry13:28
*** codavi <codavi!~akiCA@user/akica> has joined #yocto13:28
jclsn[m]I have those13: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
qschulzjclsn[m]: PRISTINE_MACHINEOVERRIDES is not a common variable so can't say if it's correctly set up or no13: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
otaviojclsn[m]: which machine is this?13:32
otaviojclsn[m]: also check the final MACHINEOVERRIDES value13:32
jclsn[m]Is there a way to set a MACHINE alias? Like my MACHINE=vti2 but all recipes with mx8 are also valid13:33
otaviojclsn[m]: vti2 is the machine name?13:34
otaviojclsn[m]: please post the  final MACHINEOVERRIDES value13:34
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)13:35
jclsn[m]otavio: Our custom boards13:35
jclsn[m]with in im8mmm SoC13:35
jclsn[m] * with in im8mm SoC13:35
otaviojclsn[m]: please post the  final MACHINEOVERRIDES value13:37
qschulzjclsn[m]: that's the whole point of MACHINEOVERRIDES, to not have to explicit each and every machine for recipes compatible with one specific SoC13:37
otavioqschulz: exactly13:38
jclsn[m]otavio: That is what I named it yes13:40
qschulzjclsn[m]: MACHINEOVERRIDES="aarch64:armv8a:use-mainline-bsp:imx-boot-container:vti2"13:42
jclsn[m]qschulz: I see. Then something funky is going on here13:42
jclsn[m]Wonder why mx8 is not included13:42
qschulzjclsn[m]: don't use grep, but less and check the variable history in the few lines above13:42
qschulzthe one line starting with MACHINEOVERRIDES=13:43
jclsn[m]Guess I need to set a MACHINEOVERRIDES_EXTENDER for vti213:45
*** Guest20 <Guest20!> has joined #yocto13:46
qschulzI don't think so13:49
jclsn[m]Hmm no13:49
qschulzthe mx8mm MACHINEOVERRIDES_EXTENDER will be taken then13:49
qschulzjust fix your MACHINEOVERRIDES fisrt, then look at the rest13:49
qschulzbut your issue is *definitely* with *at least* MACHINEOVERRIDES13:49
jclsn[m]but I have this in my vti2.conf13:49
jclsn[m]MACHINEOVERRIDES =. "imx-boot-container:mx8:mx8m:mx8mm:"13:49
otaviojclsn[m]: it is using mainline; See
jclsn[m]Why is it no appended?13:49
jclsn[m]otavio: That seemed to have worked13:52
jclsn[m]I aset IMX_DEFAULT_BSP:vti2 ?= "mx8"13:52
*** sakoman <sakoman!> has joined #yocto13:53
jclsn[m]Is that a new feature? It wasn't necessary in gatesgarth13:53
otaviojclsn[m]: i.mx8 has moved to default to mainline13:55
jclsn[m]I should probably default to mainline as well haha13:56
jclsn[m]I like to step out of line though13:56
qschulzjclsn[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 that14:01
jclsn[m]That was why I tried to append it manually and had this issue in the first place14:01
smurrayRP: 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 to14:02
jclsn[m]But now linux-fslc-imx doesn't work anymore14:02
jclsn[m]I thought this was a patched linux-imx kernel with Vivante graphics14:02
jclsn[m]Ah no it is u-boot nevermind14:03
RPsmurray: ok, cool. Do you have OE-Core changes?14:04
RPsmurray: I didn't spot those, I was trying to pull together a test set of changes14:04
RPsmurray: I have a couple of tweaks to your siggen changes so we preserve some compatibility there with old sigdata files14:05
RPsmurray: has my bits so far14:06
landgrafRP: both hg fetcher and mercurial in general are broken badly :-/14:06
smurrayRP: 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 manually14:06
RPlandgraf: sadly I'm not surprised :/14:07
RPsmurray: ok, I've a couple of patches in that branch for that then14:07
* RP wonders about putting this in master-next14:07
*** pabigot <pabigot!> has quit IRC (Remote host closed the connection)14:09
*** pabigot <pabigot!> has joined #yocto14:11
*** xmn <xmn!> has joined #yocto14:13
otaviojclsn[m]: qschulz: Etnaviv is a quite usable alternative for most projects; we use it for most of our customers14:28
jclsn[m]otavio: And NXP can't even host their files right. Again this imx-vpu-hantro-daemon fetcher failure14: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 in14:31
* RP is extremely annoyed at being left with this14:32
JPEWRP: Did you figure out that erroronce problem?14:32
RPJPEW: I think it is because I was testing early variables in the configuration datastore and the message filtering only works once knotty is running14:33
qschulzotavio: I have suggested Etnaviv to jclsn[m] already :)14:34
* JPEW looks over the logging patches in master-next14:34
jclsn[m]qschulz: Everyone does :D14:34
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)14:34
*** zpfvo <zpfvo!~fvo@> has joined #yocto14:34
*** rsalveti <rsalveti!> has quit IRC (Ping timeout: 240 seconds)14:36
*** Etheryon <Etheryon!~Etheryon@> has quit IRC (Quit: Client closed)14:37
*** pgowda_ <pgowda_!> 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_!> has joined #yocto14:38
*** rsalveti <rsalveti!> has joined #yocto14:38
*** kanavin_ <kanavin_!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Remote host closed the connection)14:40
RPsgw: I tweaked your blacklist.bbclass series to fit with the other changes and added to -next14:41
*** Etheryon <Etheryon!~Etheryon@> has joined #yocto14:43
smurrayRP: 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/tomorrow14:43
RPsmurray: I think I'm ok with the ones in -next, yes14:44
RPI'm still not promising to merge any of this as we're still missing the conversion scripts and docs14:44
*** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has joined #yocto14:45
RPI just want to try and give this a chance with a baseline for people to work off14:45
smurrayRP: okay.  For docs it would be the migration guide entry?14:45
RPsmurray: yes, that would be a good start. It doesn't have to be you but I'd like to have something14:46
smurrayRP: okay, I'll check with sgw when he is on in a bit.  I could maybe start a framework for it with these BitBake variables14:47
JPEWRP: 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 this14:49
RPsmurray: right, the PNBLACKLIST -> SKIP_RECIPE one also has patches14:49
*** goliath <goliath!~goliath@user/goliath> has joined #yocto14:50
RPJPEW: Sounds good, I think I tried that and struggled14:50
JPEWI'll test and send it in then14:50
smurrayRP: one note, I got a bitbake-selftest failure in test_parse_overrideimmediate with what's in poky-contrib atm14:51
RPsmurray: sorry, there is a load of other junk in that branch including that test14:51
RPsmurray: this is partly why I've moved to -next14:51
smurrayRP: okay, cool14:52
RPsmurray: from memory that is a new test where I was trying to debug something which needs fixing14:52
* RP has a long todo list :(14:52
sgwRP : Morning, I woke up to a 6:00 am  surprise meeting instead of trying to help you!14:52
sgwI will get to it shortly14:52
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto14:53
smurraysgw: wrt the discussion above, were you planning to work up the migration guide entry and/or the conversion script?14:54
RPsmurray, 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 for14:56
smurrayRP: somewhat related, is it halsted I should ping wrt getting my access to the wiki moved through approval process?14:56
RPsmurray: it is halstead14:57
smurrayRP: okay14:57
smurrayRP: I'll update the table a bit once I get that sorted14:58
RPI'll run -next on the autobuilder, see how widespread the damage is there14:58
sgwsmurray: I can work on the migration guide, if needed.  I will be reading the log to catch up.14:59
smurraysgw: okay, let me know if you need help with it14:59
*** Etheryon <Etheryon!~Etheryon@> has quit IRC (Quit: Client closed)15:04
*** Kaa <Kaa!~Kaa@> has quit IRC (Quit: Client closed)15:05
*** Guest83 <Guest83!~Guest83@2a02:a46d:50d4:1:44d:99c2:cb41:5c9f> has joined #yocto15:15
Guest83Hi, 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@> has quit IRC (Ping timeout: 272 seconds)15:17
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)15:18
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:18
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 252 seconds)15:23
LetoThe2ndGuest83: thats the classic approach, yes.15:23
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:24
Guest83LetoThe2nd Thanks!15:26
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds)15:30
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)15:32
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto15:33
JPEWRP: Is it ok if I squash your erroronce/warnonce patching into a new single patch with fixes?15:40
RPJPEW: if that makes most sense, I guess yes15:44
JPEWThere was another bug I had to fix, so I think it makes sense :)15:44
RPJPEW: what else did I break? :)15:45
JPEWThe "once-ness" was global, so the message would only show up on a single logging output, and no where else15:45
RPJPEW: oh, ouch :/15:45
RPJPEW: thanks for spotting that15:46
JPEWEach 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 handler15:46
RPJPEW: makes sense, thanks15:46
JPEWnp. Patch sent15:47
*** Guest83 <Guest83!~Guest83@2a02:a46d:50d4:1:44d:99c2:cb41:5c9f> has quit IRC (Quit: Client closed)15:48
RPJPEW: definitely looks cleaner, thanks15:48
*** cengiz_io <cengiz_io!> has quit IRC (Ping timeout: 245 seconds)15:53
*** cengiz_io <cengiz_io!> has joined #yocto15: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
otaviojclsn[m]: if you're facing errors please report it on GitHub so I can ask them to check internally.16:00
otaviojclsn[m]: (fetch errors)16:01
qschulzotavio: if it's hosted on codeaurora, it's not uncommon to have downtime16:03
SaurRP: I just had a build failure with Honister on one of our Jenkins builders and this is what I got in the log: 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
RPSaur: I suspect that is less about the logging changes and more about poor exception handling16:15
SaurHmm, ok.16:15
RPSaur: subprocess has a habit of not showing the output from the failed command and I suspect bb.process inherited the problem16:15
RPSaur: 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 console16:16
*** prabhakarlad <prabhakarlad!> has joined #yocto16:16
RPSaur: there are many issues like this, we just have to go through and fix them as we encounter them16:17
RPSaur: it might be we could just delete that if section now16:17
RPespecially as it says "# Don't duplicate the output in the exception if logging it"16:18
RPsounds like we fixed the duplication elsewhere and now don't see it!16:18
SaurYeah, 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
RPSaur: 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 time16:19
SaurRP: I'll see what I can come up with...16:20
SaurShould be easy enough to force some error to happen...16:20
RPSaur: Just put an "if PN = XX exit 1" into that function ;-)16:20
RP(into BUILDSPEC)16:21
rfs613what'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
JPEWrfs613: If you are careful, but it can be fiddly16:22
RPrfs613: if you add a bbappend and add a new directory to the searchpath, yes16:22
rfs613i'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
Saurrfs613: `devtool finish <recipe> <one of your layers>` will do it automatically for you.16:24
RPrfs613: there are example doing FILESEXTRAPATHS:prepend := "${THISDIR}/files:" in meta-poky16:25
RPrfs613: FILESPATH (via FILESEXTRAPATHS) works like a PATH search in shell16:26
SaurAs 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
qschulzrfs613: I think I talked about this16:31
qschulzrfs613: you also have some slides in the bonus section about the selection algorithm16:32
rfs613thanks 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 #yocto16:47
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)16:49
*** lucaceresoli <lucaceresoli!> has quit IRC (Quit: Leaving)16:57
rfs613qschulz: 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
rfs613Saur: 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
qschulzrfs613: it allows to have multiple recipes in the same directory17:00
qschulzand have patches/files for each recipe in logical directories17:01
rfs613ok, gotcha17:01
SaurRP: If I revert fc58ad84a9deb2620ad90611684dad65dafedb11 in bitbake I get back the error logs. :)17:06
RPSaur: Hmm, of course it was me who did that and it looks like there was some other case where it did duplicate :(17:08
RPSaur: Would have been nice if I'd recorded the other case :/17:08
sgwsmurray: I updated the wiki with your name attached to the work RP has in -next so far.17:09
sgwWell never mind, looks like you got access and we collided!17:09
smurraysgw: heh, was just about to say I'd done that ;)17:09
JPEWSaur: What logs are missing?17:10
RPJPEW: it is the command output which was sent to the log file17:10
JPEWHmm, I wouldn't expect that to be affected17:10
sgwsmurray: are you going to work on the conversion script or shall I start on that.17:10
smurraysgw: if you have cycles atm, please start on it.  If not, I can start working up something this evening17:11
SaurJPEW: See 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
RPSaur: you're saying the logfile itself didn't have it in either?17:14
SaurRP: No, the log.do_ file is there.17:15
SaurBut it isn't in stdout/sterr of bitbake, and it is not in console-latest.log17:18
*** florian <florian!> has quit IRC (Quit: Ex-Chat)17:22
*** zpfvo <zpfvo!~fvo@> has quit IRC (Quit: Leaving.)17:22
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)17:23
sgwsmurray: Ok, starting on a script similar to others in scripts/contrib17:23
*** frieder <frieder!> has quit IRC (Remote host closed the connection)17:25
smurraysgw: yeah, that was going to be my starting point as well if I did it17:25
RPSaur: 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
SaurRP: 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 #yocto17:43
SaurRP: I guess the tests you were referring to are commit 414020a9bd656ee61efe2f47db1b31d86b15c1c8 in meta.17:45
RPSaur: there was a separate change for the -v duplication issue :/17:47
RPSaur: 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
SaurYeah, 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@> has quit IRC (Quit: Konversation terminated!)17:49
SaurRP: Hmm, bblogging.BitBakeLogging.test_shell_logging fails for me whether I have the test in bitbake/lib/bb/ or not.17:52
SaurAnd this is with poky without any of our own changes.17:53
*** mckoan is now known as mckoan|away17:54
*** JrmeCarretero[m] <JrmeCarretero[m]!~cjzouglou@2001:470:69fc:105::1:8f50> has joined #yocto17:56
*** manuel1985 <manuel1985!~manuel198@> has quit IRC (Quit: Leaving)18:02
*** florian_kc <florian_kc!~florian@> has joined #yocto18:05
RPSaur: presumably that is passing on the autobuilder and for me locally so that is rather strange18:05
moto-timokanavin: I see you already staged python3-pytest and python3-tomli upgrades... glad you figured out the src/tomli change18:08
moto-timokanavin: python3-importlib-metadata 4.11.x dropped :/18:09
moto-timopedal faster!18:09
kanavinmoto-timo, cheers, I trust you are meticulously working towards making those recipes work again :)18:10
kanavintomli wasn't that hard, my cutoff time for this kind of thing is five minutes18:11
*** pgowda_ <pgowda_!> has quit IRC (Quit: Connection closed for inactivity)18:13
*** unknown__ <unknown__!> has quit IRC (Quit: Leaving)18:14
*** creich <creich!> has joined #yocto18:14
* RP wonders who is going to give in and sort that gstreamer test failure18:17
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto18:17
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 272 seconds)18:19
kanavinRP: I just did18:19
kanavinAlex, the last resort guy18:19
kanavin(second-last I guess)18:20
rfs613hmm, 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
RPkanavin: ah, thanks!18:20
RPkanavin: I'm curious to see if your build sees the same mirror issues mine are seeing18:21
RPkanavin: I wasn't sure which of us would crack first on gstreamer :)18:21
RPkanavin: I "fixed" the ltp one18:21
*** florian_kc <florian_kc!~florian@> has quit IRC (Ping timeout: 252 seconds)18:22
kanavinRP: I was hoping one of the gstreamer guys would send a followup :-/18:23
RPkanavin: right, me too18:24
SaurRP: It appears I had BB_VERBOSE_LOGS = "1" in my configuration which affected those tests.18:24
SaurWith that removed the tests pass.18:25
SaurAnd if I revert the change in they fail...18:25
rfs613ah, got it sorted... though it's odd, seems to be applying patch in a subdir of the repo, not at the top.18:25
kanavinRP: I know you aren't on linkedin much, but you should see this
kanavinRP: and yes, I sshd in, and it runs dunfell18:26
*** bgreen0 <bgreen0!~bgreen0@> has joined #yocto18:27
RPSaur: well, I did document what I was fixing then :)18:28
RPSaur: that should help us find a way to fix this other case too18:28
RPkanavin: nice :). At least it is dunfell so supported too18:30
RPkanavin:  I wonder if we should at that to the users list on the wiki?18:30
bgreen0Hi.  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 potential18:31
bgreen0downsides 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 #yocto18:32
bgreen0I'm using jethro (can't change) with some patches to support build reproducibility18:32
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Ping timeout: 272 seconds)18:38
sgwsmurray: I ran my conversion script and noticed that you might have missed bitbake/lib/bb/ in your basehash/taskhash renames18:38
sgwOh, never mind, I think that's the conversion code being overly agressive!18:39
SaurRP: 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
RPSaur: sorry, I must have missed the poky ones18:41
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto18:42
SaurNo worries. Easy to do I guess when the changes are spread over three different repos and mailing lists.18:42
RPSaur: merged18:42
RPSaur: please remind michaelo about the other one18:43
SaurWill do.18:43
sgwRP: I think you missed a meta-poky patch to poky-tiny in master-next18:43
smurraysgw: I'm a bit puzzled, I'd figure a conversion script would just be using the uppercase metadata variable names?  The references in in master-next are the internal variable name tweaking for signature compatibility18:44
RPsgw: well spotted, yes. queued for testing18:44
sgwRP: found with my conversion script !18:44
RPsgw: handy18:45
sgwsmurray: it's also looking for whitelist/blackslist18:45
sgwnot changing them since they are context sensitive18:45
sgwsmurray: sent you a early version to direction check.  RP, I will push a WIP to the list before noon here.18:46
smurraysgw: 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 script18:47
sgwyes, 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@> has quit IRC (Quit: ZNC 1.8.2 -
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto18:48
smurraysgw: 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 libraries18:51
sgwsmurray: 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!> has joined #yocto18:52
sgwwell meta-openembedded is looking relatively good, 80 forbidden words, and 12 recipes that the script changed (I think correctly)!19:01
RPsgw: we probably have a lot more conversions to go though!19:04
sgwOh yes, just wanted to get the script started and testing, about to send it to oe-core list19:10
otaviosgw: every one does this once in a life ;)19:11
sgwOr 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 #yocto19:16
SaurRP: 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
RPSaur: sounds like a bug19:18
rfs613Over on 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
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds)19:35
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto19:40
*** marc2 <marc2!> has quit IRC (Quit: WeeChat 3.4)19:51
*** marc1 <marc1!> has joined #yocto19:57
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 252 seconds)19:58
*** Bardon_ <Bardon_!~Bardon@user/Bardon> has joined #yocto19:59
*** Bardon <Bardon!~Bardon@user/Bardon> has quit IRC (Ping timeout: 272 seconds)19:59
*** dacav <dacav!> has quit IRC (Quit: leaving)20:01
*** dacav <dacav!> has joined #yocto20:01
*** dacav <dacav!> has quit IRC (Client Quit)20:02
*** dacav <dacav!> has joined #yocto20:02
*** dacav <dacav!> has quit IRC (Client Quit)20:04
*** dacav <dacav!> has joined #yocto20:04
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 272 seconds)20:10
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)20:14
*** dev1990 <dev1990!~dev@> has joined #yocto20:15
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds)20:15
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto20:17
RPrfs613: sounds like we need to be ready with a patch to fix something :/20:19
RPsgw: "descriptive" isn't going to work as naming/description for this script ;-)20:25
*** florian_kc <florian_kc!> has joined #yocto20:30
RPsmurray, sgw: I've tweaked master-next a bit based on various patches around and added the core renames to bitbake.conf20:35
RPsgw: surprisingly only two failures on oe-selftest on the first autobuilder run. I've stopped that one and started on the new series20:37
RPwell, once sakoman and kanavin's builds finish with the workers I let go :)20:37
rfs613RP: surely there's some AI or similar that can take care of this automatically, no? :P20:38
RPkanavin: your build was nearly worse than the inclusive language one20:38
RPrfs613: you are kidding? ;-)20:38
rfs613RP: and where are the flying cars we were promised ;_)20:39
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto20:40
RPJPEW: :)20:42
*** drewfustini <drewfustini!> has left #yocto20:48
smurraysgw: 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@> has joined #yocto21:00
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)21:01
*** camus1 is now known as camus21:01
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds)21:02
kanavinpro tip: if you want webkitgtk patches to be looked at by upstream, set 'component' in the bug tracker to webkitgtk21:03
kanavinotherwise, they'll be seen as 'generic bugs' that no one looks at21:04
kanavinI 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@> has quit IRC (Quit: Client closed)21:06
*** aleblanc[m] <aleblanc[m]!~aleblancm@2001:470:69fc:105::1:c14f> has joined #yocto21:07
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 256 seconds)21:09
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto21:11
*** GillesM <GillesM!> has quit IRC (Quit: Leaving)21:17
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 256 seconds)21:20
vddo you have a valid scenario for a distro extending MACHINE_EXTRA_RDEPENDS/RRECOMMENDS or that is outrageous?21:22
smurrayvd: 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 want21:28
vdhum I see21:29
vdthat might fit with my usecase21:29
smurrayvd: the rationale in AGL might be easier as downstream may not use any of the provided images, even as a base21:30
*** florian_kc <florian_kc!> has joined #yocto21:31
smurrayvd: but our visibility into what downstream auto folks actually do with it is very limited21:32
vdsmurray: 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
RPkanavin: nice. I'm still waiting/hoping on the libtool ones!21:34
vdsmurray: 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 mistaken21:35
smurrayvd: 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 configuration21:35
vdwell core-image-minimal is indeed meant to showcase a machine while core-image-base is meant to showcase the base of a distro21:37
vdthanks to packagegroup-core-boot and packagegroup-distro-base, assuming they are properly configured21:38
vd(via MACHINE/DISTRO_*EXTRA_*)21:38
kanavinRP: 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
RPkanavin: I wish libtool were that simple :)21:42
RPkanavin: we are making steady progress on the patch stats though21:43
vdsmurray: you are relying on multiconfigs so far for the distro/machine glue, aren't you?21:44
*** Guest20 <Guest20!> has quit IRC (Quit: Connection closed)21:45
smurrayvd: 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 stuff21:46
kanavinRP: yes, I'm looking at those weekly stats too, they go down as previously submitted things get dropped on upgrades21:47
kanavinnow how do I squeeze in my revised patchbomb between all those Important Builds :-/21:48
smurrayvd: 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 AGL21:48
kanavinRP: 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!> has left #yocto (Leaving)21:49
vdsmurray: 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 instead21:52
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)21:52
vdsmurray: having machine or distro variants (requiring a base config) is not the best but still a good way to isolate machine/distro glue21:54
smurrayvd: that's more difficult with vendor BSP layers that have somewhat non-functional upstreams22:00
vdsmurray: 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
smurrayvd: 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, sure22:06
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection)22:06
vdsmurray: 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.conf22:07
vdanother example is chosing a different bootloader for your use case22:07
vdsmurray: 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
smurrayvd: we  (AGL) rely on them, yes.  It wasn't clear to me what you meant.  I gathered you mean defining your own22:08
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 250 seconds)22:10
RPkanavin: queue it up, the AB will get to it overnight22:10
kanavinRP: 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 moment22:11
vdshould 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 #yocto22:14
RPkanavin: 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@> has quit IRC (Ping timeout: 256 seconds)22:39
*** nsbdfl <nsbdfl!nsfbdl@user/nsbdfl> has joined #yocto23:05
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)23:07
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 240 seconds)23:07
sgwRP: 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
sgwRP, nm you already did in oe-core master-next!23:23
*** awafaa <awafaa!> has quit IRC (Read error: Connection reset by peer)23:35
*** awafaa <awafaa!> has joined #yocto23:35
*** YogeshSiraswar_ <YogeshSiraswar_!> has quit IRC (Read error: Connection reset by peer)23:35
*** halstead <halstead!> has quit IRC (Read error: Connection reset by peer)23:35
*** YogeshSiraswar_ <YogeshSiraswar_!> has joined #yocto23:35
*** halstead <halstead!> has joined #yocto23:35
*** shivamurthy <shivamurthy!> has quit IRC (Read error: Connection reset by peer)23:35
*** dl9pf <dl9pf!> has quit IRC (Read error: Connection reset by peer)23:35
*** praneeth <praneeth!> has quit IRC (Read error: Connection reset by peer)23:35
*** paulbarker <paulbarker!> has quit IRC (Ping timeout: 252 seconds)23:35
*** CosmicPenguin <CosmicPenguin!> has quit IRC (Read error: Connection reset by peer)23:35
*** ldts <ldts!> has quit IRC (Read error: Connection reset by peer)23:35
*** xtopher_ <xtopher_!> has quit IRC (Read error: Connection reset by peer)23:35
*** praneeth <praneeth!> has joined #yocto23:35
*** dl9pf <dl9pf!> has joined #yocto23:35
*** ndec <ndec!> has quit IRC (Read error: Connection reset by peer)23:35
*** CosmicPenguin <CosmicPenguin!> has joined #yocto23:35
*** rburton <rburton!rburton@user/rburton> has quit IRC (Read error: Connection reset by peer)23:35
*** jamestperk <jamestperk!> has quit IRC (Read error: Connection reset by peer)23:35
*** georgem <georgem!> has quit IRC (Read error: Connection reset by peer)23:35
*** fancer <fancer!> has quit IRC (Write error: Connection reset by peer)23:35
*** xtopher_ <xtopher_!> has joined #yocto23:35
*** ernstp <ernstp!> has quit IRC (Read error: Connection reset by peer)23:35
*** thierryE <thierryE!> has quit IRC (Read error: Connection reset by peer)23:35
*** ndec <ndec!> has joined #yocto23:35
*** darknighte <darknighte!sid214177@user/darknighte> has quit IRC (Read error: Connection reset by peer)23:35
*** ChanServ sets mode: +v ndec23:36
*** rburton <rburton!rburton@user/rburton> has joined #yocto23:36
*** jamestperk <jamestperk!> has joined #yocto23:36
*** shivamurthy <shivamurthy!> has joined #yocto23:36
*** paulbarker <paulbarker!> has joined #yocto23:36
*** darknighte <darknighte!sid214177@user/darknighte> has joined #yocto23:36
*** thierryE <thierryE!> has joined #yocto23:36
*** ldts <ldts!sid269548@2a03:5180:f:4::4:1cec> has joined #yocto23:36
*** fancer <fancer!fancer@2a03:5180:f::2:c200> has joined #yocto23:37
*** georgem <georgem!> has joined #yocto23:37
*** ernstp <ernstp!> has joined #yocto23: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 #yocto23: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 #yocto23:52
*** florian_kc <florian_kc!> has joined #yocto23:53

Generated by 2.17.2 by Marius Gedminas - find it at!