Monday, 2021-08-02

*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:04
*** RobertBerger <RobertBerger!~rber|> has joined #yocto01:32
*** rber|res <rber|res!~rber|> has quit IRC (Ping timeout: 272 seconds)01:34
*** nerdboy_ <nerdboy_!~nerdboy@> has joined #yocto01:40
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 265 seconds)01:42
*** camus1 <camus1!~Instantbi@> has joined #yocto01:53
*** camus1 <camus1!~Instantbi@> has quit IRC (Client Quit)01:54
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)02:11
*** linkliu59 <linkliu59!~user_name@> has quit IRC (Quit: Lost terminal)02:23
*** linkliu59 <linkliu59!~user_name@> has joined #yocto02:24
*** boo <boo!> has quit IRC (Ping timeout: 272 seconds)03:11
*** amitk <amitk!~amit@> has joined #yocto03:41
*** goliath <goliath!~goliath@user/goliath> has joined #yocto05:48
*** rob_w <rob_w!> has joined #yocto06:16
*** sbach <sbach!~sbach@user/sbach> has quit IRC (Read error: Connection reset by peer)06:40
*** sbach <sbach!~sbach@user/sbach> has joined #yocto06:40
*** frieder <frieder!> has joined #yocto06:43
*** Fanfwe42 is now known as Fanfwe06:47
*** frieder <frieder!> has quit IRC (Ping timeout: 272 seconds)06:48
*** zpfvo <zpfvo!~fvo@> has joined #yocto06:57
*** g0hl1n <g0hl1n!> has joined #yocto07:10
*** g0hl1n <g0hl1n!> has quit IRC (Client Quit)07:10
*** g0hl1n <g0hl1n!> has joined #yocto07:11
*** g0hl1n <g0hl1n!> has quit IRC (Client Quit)07:11
*** g0hl1n <g0hl1n!> has joined #yocto07:11
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)07:14
*** frieder <frieder!> has joined #yocto07:34
*** goliath <goliath!~goliath@user/goliath> has joined #yocto08:08
*** ykrons <ykrons!~guillaume@> has joined #yocto08:15
*** bizulk <bizulk!~bizulk@> has joined #yocto08:17
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 250 seconds)08:19
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto08:23
*** florian <florian!> has joined #yocto08:27
*** Bardon <Bardon!~Bardon@user/Bardon> has joined #yocto08:36
BardonHello, I'm trying to build an image which has dropbear in it and I'd like to enable key based authentication and disable password authentication08:44
BardonI'm very new to yocto poky. This is my first time compiling it08:45
BardonI have a meta/recipes-core/dropbear/ directory, in which there is a file. I added a few lines in do_install(): "mkdir -p ${D}/home/root/.ssh/; echo "my_key" > ${D}/home/root/.ssh/authorized_keys:"08:47
BardonI also added "DROPBEAR_EXTRA_ARGS="-s"" to disable password authentication in dropbear/init08:47
BardonI tried compiling this module with bitbake -b but I get "QA Issue: dropbear: Files/directories were installes but not shipped /home /home/root /home/root/.ssh /home/root/.ssh/authorized_keys"08:48
BardonRunning the command I used to build the whole image (bitbake asus-image) doesn't seem to recompile any module08:50
BardonSo I'm wondering, did I do anything wrong? Can anyone help me?08:51
BardonI added "FILES_${PN} += "/home /home/root /home/root/.ssh /home/root/.ssh/authorized_keys"". It doesn't complain anymore, yet `bitbake asus-image` still doesn't seem to recompile any module08:58
BardonAnd I don't know if I'm doing this right08:59
paulbarkerBardon: where did you add that FILES_${PN} setting?09:01
Bardonpaulbarker: Right after the do_install() function, in meta/recipes-core/dropbear/dropbear.inc09:02
paulbarkerBardon: Ok. Does the dropbear recipe include that .inc file? Are you modifying this directly in the core layer or are you putting the modifications in your own layer?09:03
Bardonpaulbarker: The dropbear recipe is the .bb file, right? If so, I have "require" in the .bb file next to it09:06
Bardonpaulbarker: I'm not familiar with layers. I'm in meta/recipes-core/dropbear/. Since it says "recipes-core", could I be in the core layer?09:06
paulbarkerBardon: By "core layer" I mean the openembedded-core or poky repositories09:07
Bardonpaulbarker: I'm not using these repositories. I'm using
BardonFull instructions are in
BardonThis is a few years old I believe so this may have changed on poky's side09:09
paulbarkerBardon: The best people to give advice on that is your vendor then09:15
paulbarkerI can give a couple of general tips though09:15
BardonI'm on my own on this one I believe. There's no support from raptorengineering anymore I believe09:16
paulbarkerIf you look in ${TMPDIR}/work/<arch>/dropbear/<version>/temp, you should see log.do_install & run.do_install files, check those. Particularly check if your commands appear in the run file09:16
paulbarkerYou can also run `bitbake -e dropbear` to dump the bitbake environment (all variables and functions). Pipe that to a file and look at it to see if your modifications are applied09:17
paulbarkerI also recommend following some tutorials on how to create your own layer and use bbappend files. It's not trivial but a few days of learning will get you a long way09:18
Bardonpaulbarker: tmp/work/armv5e-poky-linux-gnueabi/dropbear/2014.66-r0/ only has an empty build directory. bitbake -e dropbear show my modified do_install() function09:23
*** UmbrellaMan <UmbrellaMan!~UmbrellaM@> has quit IRC (Quit: Client closed)09:41
Bardonpaulbarker: Thanks a lot for your help :). I'll look into what you said09:46
wyrecould I prevent to build the tar image file?10:01
qschulzwyre: don't have it in IMAGE_FSTYPES :)10:02
wyreqschulz, I'd say I haven't it ... but in my local.conf I have IMAGE_FSTYPES += "ubifs wic"10:03
wyreso I'm not sure if some recipe is bringing tar to IMAGE_FSTYPES10:03
qschulzwyre: bitbake -e <image recipe> and look for IMAGE_FSTYPES in it10:04
qschulzalso, try to avoid using += in local.conf, use _append instead10:04
wyreqschulz, I can see IMAGE_FSTYPES=" ubifs wic tar.xz ubifs" but also IMAGE_FSTYPES_DEBUGFS="tar.gz"10:06
wyreI'm not sure why is ubifs duplicaded and algo which one is actually producing the tar file10:06
wyrewell apparently both, because there are a tar.xz and tgz files 🤔10:07
qschulzwyre: just read above this line and you'll see the history of the variable10:11
wyreqschulz, well, I can see this so apparently the machine conf file is appending tar.xz and ubifs, ... but where come from wic.bmap and wic.gz ?10:18
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto10:27
wyreqschulz, apparently when I don't set IMAGE_FSTYPES in local.conf wic image cannot be built
qschulzwhere did you set it?10:30
wyreqschulz, I didn't set it10:30
wyrebut when I don't set it I can see it's set as IMAGE_FSTYPES="wic.bmap wic.gz tar.xz ubifs"10:31
wyreso it should build something, right?10:32
*** jkolasa <jkolasa!> has joined #yocto10:33
wyrethis can be seen in here
*** jkolasa <jkolasa!> has quit IRC (Client Quit)10:35
*** florian_kc <florian_kc!> has joined #yocto10:38
qschulzprobably an incorrect dependency in wic.gz or wic, you're missing the wks file which is required to build wic, and since wic.gz will build wic before compressing it (I assume), it fails10:40
qschulzif you want to remove tar.gz from the IMAGE_FSTYPES, you can override IMAGE_FSTYPES in your image recipe or machine configuration file10:41
*** jmiehe1 <jmiehe1!~Thunderbi@user/jmiehe> has joined #yocto10:42
wyreqschulz, and what about the local.conf?10:43
qschulzwyre: what's the question?10:44
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Ping timeout: 272 seconds)10:44
*** jmiehe1 is now known as jmiehe10:44
wyreqschulz, if I could override IMAGE_FSTYPES in the local.conf10:45
wyreand how could I fix the wic dependency problem?10:45
wyreI mean, where am I missing the wks file? 🤔10:45
qschulzwyre: no, because your machine configuration is setting it and the machine configuration file is parsed after local.conf IIRC10:45
qschulzwyre: question to ask your vendor, but just add wic for now if it fixes it10:45
qschulzwyre: you could also add IMAGE_FSTYPES_remove = "tar.gz" to your local.conf but it's really not best practice10:46
qschulz(especially since you're not supposed to share your local.conf, so it's going to be lost for other devs or your build systems)10:46
wyreqschulz, so you do recommend me to set it in my image recipe, right?10:46
wyreto override it, I mean10:47
qschulzwyre: if you never want it for a given recipe, you should probably have your own machine configuration file that sets it correctly instead of your image recipe10:47
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto10:57
wyreqschulz, just appending the .wks file doesn't solve the problem 🤔10:57
wyremaybe I should nuke the whole tmp folder 🤔10:58
wyreI've tried the clean command but it doesn't remove the images folder so I've used clean and remove manually the images folder10:58
qschulzwyre: appending the wks file to what?11:00
wyreqschulz, appending wic to IMAGE_FSTYPES11:00
wyresorry, I meant appending wic to IMAGE_FSTYPES11:00
qschulzwyre: because you probably removed the wks file provided by the recipe and didn't force a deploy again11:04
qschulzjust don't modify or remove things from the deploy dir11:04
wyrehow can I force the deploy?11:05
qschulzclean the recipe and rebuild it I guess?11:06
wyrethat's what I did, but removing the images folder11:07
qschulzbut you'll just run into problems until you've done that for all missing artifacts in the deploy dir11:07
qschulzwyre: no, I assume you did that only for the image recipe11:07
qschulzyou'd need to do that for the recipe providing the wks file too11:07
wyreqschulz, you mean the clean?11:08
*** ljh <ljh!~ljh@2804:14d:baa3:44f4:6c91:1e7b:7d2d:215a> has joined #yocto11:12
ljhGood morning/evening/afternoon, folks!11:12
wyreqschulz, and how can I figure out which one is that recipe?11:13
qschulzwyre: grep's your friend I guess11:14
*** georgem <georgem!> has joined #yocto11:14
wyreqschulz, well, I guess it must be this one tmp/deploy/images/imx6ull-microgea/joifi-displays-imx-uboot-bootpart.wks11:15
wyresince I've nuked the whole tmp/deploy/images/imx6ull-microgea/ folder11:15
*** UmbrellaMan <UmbrellaMan!~UmbrellaM@> has joined #yocto11:26
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)11:35
*** frieder <frieder!> has quit IRC (Ping timeout: 272 seconds)11:38
*** frieder <frieder!> has joined #yocto11:49
*** bizulk <bizulk!~bizulk@> has quit IRC (Quit: Client closed)11:54
*** otavio_ <otavio_!> has quit IRC (Remote host closed the connection)11:55
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)12:10
*** argonautx <argonautx!> has joined #yocto12:21
*** yates_work <yates_work!> has quit IRC (Ping timeout: 252 seconds)12:22
*** Acki <Acki!~Acki@2a02:8109:a280:2d8d:a8b8:61e8:b7a1:56f9> has joined #yocto12:32
*** vd <vd!> has joined #yocto12:52
vdhi all -- the parent folder recipe-* doesn't matter for the location of a .bbappend file, right?13:10
vdIt doesn't have to match the original path, for example I can place all my bbappend in recipes-append if I want to, correct?13:10
*** ljh <ljh!~ljh@2804:14d:baa3:44f4:6c91:1e7b:7d2d:215a> has quit IRC (Quit: Client closed)13:12
qschulzvd: correct, it should just be in a path matching the BBFILES globs13:16
qschulzof the layer in which they are (can be found in conf/layer.conf of said layer)13:16
qschulzvd: you anyway can check with bitbake-layers show-appends IIRC13:17
vdI'm using overrides and bbappend files, but it looks like the image I'm running isn't the appended one. How can I make sure the changes are applied?13:17
vdqschulz: :)13:18
qschulzyou can check the value of variables and tasks/functions after parsing by running bitbake -e <recipe>13:18
*** frieder <frieder!> has quit IRC (Ping timeout: 256 seconds)13:22
vdI have SSTATE_DIR outside of TOPDIR, every time I rm -rf build/ and rebuild, linux-ti-staging recompiles. It doesn't seem expected. Any idea?13:23
qschulzvd: bitbake-diffsigs to start debugging the issue, but no, no idea on my side13:24
vdbitbake -e <recipe> is like the very final instructions for a recipe?13:31
vdlike a very basic bitbake implementation could do `bitbake -e recipe >; bitbake ./`?13:32
*** frieder <frieder!> has joined #yocto13:37
vdqschulz how's diffsigs supposed to work? should I build, dumpsig, rm rebuild and compare?13:39
qschulzsave the sigdata which is in stamps directory IIRC13:39
qschulzthen rebuild13:39
qschulzthen diffsigs between both sigdata13:40
*** yates_work <yates_work!> has joined #yocto13:43
yates_workif a layer has a <name>.bbappend file, will that bbappend be applied to any version of <name>.bb? e.g., <name> ?13:45
yates_workthis appears to be the way it works, but i don't see that operation documented in the bitbake manual13:45
vdyates_work <name>_%.bbappend13:45
yates_workvd: yes, i see that's the normative way to do things. but i've created a <name>.bbappend and it is getting applied to <name>_0.4.2.bb13:46
yates_workis that a quirk?13:46
yates_workunadvertised feature? :)13:46
yates_workbasically, i screwed up and found it worked!13:47
yates_worknow i'm wondering why.13:47
*** Acki <Acki!~Acki@2a02:8109:a280:2d8d:a8b8:61e8:b7a1:56f9> has quit IRC (Ping timeout: 246 seconds)13:50
yates_workspecifically i'm working with poky/meta/recipes-devtools/meson/ i created a poky/meta-csky/recipes-devtools/meson/meson.bbappend and it's working13:51
yates_workit has a "BBCLASSEXTEND" - i wonder if that somehow impacts how .bbappends are applied?13:51
*** otavio <otavio!> has joined #yocto13:51
yates_workor maybe in bitbake's logic <name>.bbappend is taken to be <name>_%.bbappend?13:53
qschulzyates_work: bitbake -e meson, you'll be able to check that you really are using 0.55.1 version, and also that your bbappend is applied (with the variable history of e.g. BBCLASSEXTEND)13:54
yates_workqschulz: ok thanks - i will check it out.13:56
vdI split my custom image recipes into multiconfig appending a single generic image recipe, and total tasks went from ~5k to ~15k tasks :-S13:57
qschulzwhy are you using multiconfig?13:58
*** sakoman <sakoman!> has joined #yocto13:59
vdqschulz because I have various build variants, they are combinations of a machine and image tweaks for different customers (like forcing a specific package version or tweaking default values like user passwords)14:01
qschulzvd: I don't think that's a good use of multiconfig14:02
qschulzfor me multiconfig is for when you have a product with multiple SoCs involved, e.g. one with some cortex-axx cores running Linux, and another possibly MCU only running something else14:03
qschulzthe description of your "issue" seems to be what most people do? You just build Yocto multiple times, have separate image recipes, possibly distro and/or machine configuration files14:04
qschulzif the distro and machines are identical, you can build multiple image recipes at once by passing them to bitbake directly (it can take more than one recipe as argument)14:04
vdbut since multiple build should ideally use different TMPDIR and the machine may vary, why not using multiconfig with a single bitbake invokation rather than wrapping multiple calls to bitbake with custom local.conf changes every time?14:06
vdAt the moment I use kas and I could indeed have one .yml file per build variant (a.k.a. customer), but I figured using bitbake's native support for a multiconfig (referred by BB_CURRENT_MC) with its own TMPDIR and OVERRIDES was quite elegant14:12
*** sgw <sgw!~swold_loc@user/sgw> has joined #yocto14:17
vdqschulz: also appending a common recipe avoids duplicating every recipes for every variants14:17
*** matthiasklein <matthiasklein!~matthiask@2a02:908:4c17:2d40:95cb:9074:6988:38d> has joined #yocto14:18
matthiaskleinI want to create an image which I can specify to QEMU with the -sd option. Without "qemu-img resize ... 1024M" I get the error message: SD card size has to be a power of 2. Is it possible to specify the exact size of a WIC image?14:23
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:32
*** Guest26 <Guest26!~Guest26@> has joined #yocto14:44
RPmichaelo: Am I up to date with the bitbake patches for the docs? Also, we're ready for the docs override translation14:52
*** berton[m] <berton[m]!~fabiobert@2001:470:69fc:105::ce36> has joined #yocto14:57
michaeloHi RP. No I believe you're missing a few. Thanks for asking. I'll highlight the ones I'm missing in a private reply.14:59
RPmichaelo: if you want to put together a branch somewhere... :)15:01
RPmichaelo: I thought it easier just to ask which I was missing!15:01
*** RobertBerger <RobertBerger!~rber|> has quit IRC (Quit: Leaving)15:08
*** frieder <frieder!> has quit IRC (Remote host closed the connection)15:16
wyrehi guys, how can I associate the GPIO pins in here (page 13) with their gpio chip in here ?15:18
qschulzwyre: cat /sys/kernel/debug/gpio should help. Otherwise, ask your vendor :)15:23
*** roussinm <roussinm!> has joined #yocto15:23
*** Acki <Acki!~Acki@2a02:8109:a280:2d8d:a8b8:61e8:b7a1:56f9> has joined #yocto15:26
Ackihow does yocto checks out code wit the git fetcher? I have problem with applying a patch because of different line endings15:27
Ackidoes it force to checkout with certain line ending?15:27
*** hpsy <hpsy!~hpsy@> has joined #yocto15:28
qschulzAcki: Yocto applies patches with quilt by default15:30
Ackiwhat does quilt mean?15:30
qschulzyou can switch to git by adding PATCHTOOL = "git" in your recipe15:30
qschulzAcki: it's the name of a SW15:30
qschulzbut I've had some issues with patches that were happily applied by git but quilt complained about them15:31
AckiDo you know what is the command which yocto uses to apply the patch with quilt?15:36
*** goliath <goliath!~goliath@user/goliath> has joined #yocto15:38
*** boo <boo!> has joined #yocto15:43
*** Guest5 <Guest5!> has joined #yocto15:44
*** Guest5 <Guest5!> has quit IRC (Client Quit)15:45
*** marcus65 <marcus65!> has joined #yocto15:45
marcus65ran into an issue trying to build with the latest gcc 11.215:46
smurrayRP: for the override syntax conversion, I notice the " _<layer name>" use in layer.conf is unchanged, I guess that's a different parser?15:46
marcus65anyone else try it?15:46
RPsmurray: those are never used as overrides15:47
smurrayRP: so LAYER*_layer is the full variable name, I guess?15:47
RPsmurray: partly as layer setup happens before OVERRIDES is constructed15:47
marcus65parsing chokes gcc/ unparsed line: 'ARM_INSTRUCTION_SET:armv6 = "arm"'15:47
RPsmurray: correct, as things stand those are just variables15:48
kergothmarcus65: sounds like you need to update your bitbake15:48
smurrayRP: okay, just wanted to double-check I wasn't missing something15:49
*** davidinux <davidinux!~davidinux@> has joined #yocto15:49
marcus65kergoth: BitBake Build Tool Core version 1.46.015:49
marcus65kergoth, this is the latest, no?15:50
RPsmurray: making the overrides would be kind of cool but probably for another time15:50
kergothit's nice that it's actually clear when overrides are used and when not, now15:51
smurrayRP: at least post-conversion it can be assumed they're just variables ;)15:51
smurrayoops, ninja-ed15:51
*** argonautx <argonautx!> has quit IRC (Quit: Leaving)15:51
kergothmarcus65: not even close, no. you can't use an old stable branch bitbake with oe-core master, that's a branch mismatch15:52
kergothmarcus65: bitbake master is 1.51.115:52
marcus65kergoth: thanks, I'll update and try again15:53
RPkergoth: I think it will raise some questions but yes, good questions to raise in some cases!15:53
kergothyeah, there's clearly cases where we might or might not want to use it, but at least it's obvious which is the case now :)15:53
RPkergoth: I'm kind of dreading my inbox having pushed this...15:54
kergothi'm sure there'll be fallout and complaining, because there always is with anything like this. i just hope we don't get too many folks refusing to leave an LTS now15:55
RPkergoth: right, the bigger risk in my mind is we get too afraid of change15:55
* RP is finding there are some nasty bugs buried in bugzilla reports :/15:56
yates_worki am sorry to report that i was totally screwed up. my filename was the expected meson_0.55.1.bbappend and not meson.bbappend15:59
qschulzyates_work: :) Case of the mondays :)15:59
yates_workin my defense, i believe i was looking at some stale emacs buffer and had tried meson.bbappend at one point.16:00
yates_workqschulz: yah, i'll go with that!16:00
*** matthiasklein <matthiasklein!~matthiask@2a02:908:4c17:2d40:95cb:9074:6988:38d> has quit IRC (Quit: Client closed)16:01
kergothrecipetool newappend -e or devtool edit-recipe can be of use :)16:01
yates_worknew question: is there a patch utility, outside of git, that takes as input two files and generates a patch usable by yocto?16:01
kergothoh, now i want to watch office space. it's been a while16:01
kergothyates_work: diff -urNd16:02
yates_workkergoth: thanks i'll give it a go16:02
kergothN handles missing files, r recurses for directories, u is unified format, -d tries to minimize the set of changes16:02
kergothfor just two single files, diff -u will do16:02
kergoththat's the key, unified, not context format16:02
smurrayRP: checking conversion after running the script on meta-agl, it did touch variables in a sub-layer layer.conf, might need to mask that out16:03
smurrayRP: and I notice it's touched some blah/blah_arm64 paths inside quote strings in variable definitions16:05
smurrayRP: but since it's documented that manual verification is required, not a big deal, maybe16:05
*** zpfvo <zpfvo!~fvo@> has quit IRC (Quit: Leaving.)16:07
RPsmurray: it is definitely not intended to be 100% automated16:11
*** Guest4565 <Guest4565!> has joined #yocto16:20
*** Guest4565 is now known as thierryE16:21
*** ant__ <ant__!> has quit IRC (Ping timeout: 272 seconds)16:21
*** ant__ <ant__!> has joined #yocto16:23
*** thierryE_ <thierryE_!> has joined #yocto16:30
*** thierryE_ <thierryE_!> has quit IRC (Client Quit)16:34
*** thierryE <thierryE!> has left #yocto16:34
*** thierryE_ <thierryE_!> has joined #yocto16:36
*** thierryE_ <thierryE_!> has quit IRC (Client Quit)16:38
*** thierryE_ <thierryE_!> has joined #yocto16:39
*** thierryE_ <thierryE_!> has left #yocto16:39
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:45
*** hpsy <hpsy!~hpsy@> has quit IRC (Read error: Connection reset by peer)16:45
*** thierryE <thierryE!> has joined #yocto16:48
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)16:48
*** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has joined #yocto16:50
*** Acki <Acki!~Acki@2a02:8109:a280:2d8d:a8b8:61e8:b7a1:56f9> has quit IRC (Ping timeout: 246 seconds)17:02
*** UmbrellaMan <UmbrellaMan!~UmbrellaM@> has quit IRC (Quit: Client closed)17:08
overrideive tried bitbake -e etc but I cant figure out what recipe writes boot.scr17:18
*** marcus65 <marcus65!> has quit IRC (Quit: Client closed)17:24
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto17:30
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 265 seconds)17:33
*** davidinux <davidinux!> has joined #yocto17:35
*** florian_kc <florian_kc!> has joined #yocto17:53
overridethe partitions I setup using .wks file should be showing up under .dev on the board?18:08
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Quit: Textual IRC Client:
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto18:15
*** vd <vd!> has quit IRC (Quit: Client closed)18:16
*** Guest26 <Guest26!~Guest26@> has quit IRC (Quit: Client closed)18:17
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto18:32
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Remote host closed the connection)18:32
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto18:34
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 272 seconds)18:45
*** davidinux <davidinux!> has quit IRC (Ping timeout: 272 seconds)18:48
*** davidinux <davidinux!~davidinux@> has joined #yocto18:48
overridecan someone give me the idea behind mkimage ? iv usually only dealt with python packages, maybe thsts why I havent come across it before?18:55
*** kroon <kroon!> has joined #yocto18:57
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 258 seconds)18:57
kroonI think the new warning messages about the old-style overrides needs to mention which file is causing the warning19:01
kroon"ERROR: Variable PACKAGECONFIG_append_pn-qemu-system-native contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake."19:01
smurrayhaving hit that earlier, at least that one's not commonly used ;)19:06
smurrayon a side note, if you've a custom local.conf template that sets that, bump CONF_VERSION to "2" while you're in there, as that's also required now19:08
*** Tokamak <Tokamak!> has joined #yocto19:11
Guest63is there a way to run bitbake for all packages matching a pattern?19:25
*** Guest63 is now known as Xagen19:26
Xageni want to do a `-c cleanall` for all the python packages i currently have built19:26
Xagenbut `bitbake python* -c cleanall` doesn't work19:27
*** _whitelogger <_whitelogger!> has quit IRC (Ping timeout: 250 seconds)19:33
*** _whitelogger <_whitelogger!> has joined #yocto19:40
khemRP:  finally I have glibc 2.34 upgrade under control, so today I updated to use new override syntax, its quite a bunch of changes but Martin has done soem prework so it helped, finally I am on way to build an image19:42
khemRP:  in meta-oe we have SRCREV_opencv = "xxx" etc. should they change as well to SRCREV:opencv and so on ?19:43
kroonXagen, if nothing else, "bitbake $(shell-magic-to-find-python-recipes) -c cleanall"19:44
Xagenthat's basically the route i ended up going with as there didn't seem to be anything built in19:44
*** florian_kc <florian_kc!> has joined #yocto19:48
khemXagen:  bitbake does not support wildchars for targets19:50
Xagenkhem: thanks for the confirmation. i didn't find anything, but just wanted to make sure that was indeed the case.19:51
kroonsmurray, yeah thanks for the reminder, i did need to refresh my local.conf aswell19:59
*** xmn <xmn!> has joined #yocto20:01
RPkhem: If opencv is used in OVERRIDES yes20:03
RPkhem: It is a bit of work but hopefully manageable and worthwhile in the end20:03
RPkhem: I tried the 2.34 patch but I think a patch I merged in master conflicts :/.20:03
*** Tokamak <Tokamak!> has quit IRC (Ping timeout: 240 seconds)20:06
*** kroon <kroon!> has quit IRC (Quit: Leaving)20:06
*** Tokamak <Tokamak!> has joined #yocto20:11
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 252 seconds)20:28
*** lexano <lexano!~lexano@2607:fea8:5bc0:12:12c3:7bff:fe95:9fc1> has quit IRC (Ping timeout: 250 seconds)20:50
*** Acki <Acki!~Acki@2a02:8109:a280:2d8d:a8b8:61e8:b7a1:56f9> has joined #yocto21:06
*** lexano <lexano!~lexano@2607:fea8:5bc0:12:12c3:7bff:fe95:9fc1> has joined #yocto21:06
*** Tokamak <Tokamak!> has quit IRC (Ping timeout: 240 seconds)21:06
*** bluelightning <bluelightning!~paul@2406:e003:1328:2101:b007:8272:e69d:ffd2> has quit IRC (Quit: Konversation terminated!!!111)21:11
khemyeah try the contrib branch21:13
khemRP: I realized that this will require us to create release specific branches for own layers, so far we have been keeping single branch working across multiple oe releases21:15
khembut that also has its own downsides21:15
khemI also see lot of BSP layers using similar model so it will take a while for these changes to travel to all layers21:16
*** nerdboy_ is now known as nerdboy21:18
smurraykhem: hopefully dunfell and newer being forward compatible helps with that?21:19
khemhow does that help21:20
RPkhem: you can use the new syntax with older bitbakes as long as they're updated to the version on that series21:22
khemyeah one way it will but not two way :)21:22
khemhas anyone adapted bitbake.vim21:23
*** Tokamak <Tokamak!> has joined #yocto21:25
RPkhem: hmm, that will probably need tweaking21:27
smurrayRP: I've got meta-agl-core converted and building, but am seeing a runtime issue with one of the test images that I'm trying to pin down (might be some other change in poky master in the last week)21:27
RPsmurray: hmm, what kind of issue?21:28
smurrayRP: weston doesn't start in our agl-image-weston.  I couldn't reproduce with core-image-weston in a standalone build, so I'm a bit puzzled21:29
smurrayRP: by standalone build I mean poky on its own21:30
RPsmurray: hmm, that doesn't sound very specific :/21:30
RPsmurray: comapred the image manifests before/after?21:30
smurrayRP: I took a glance at it and didn't see anything obvious by eye, I'll diff once I finish a test build that's running now of pre-syntax change21:33
*** Tokamak <Tokamak!> has quit IRC (Read error: Connection reset by peer)21:35
*** bluelightning <bluelightning!~paul@2406:e003:1328:2101:1964:4968:91fb:9231> has joined #yocto21:38
khemRP: kergoth
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto21:55
*** vd <vd!> has joined #yocto21:56
*** rpcme <rpcme!> has joined #yocto22:25
RPkhem: cool :)22:26
RPabelloni: I think the current -next build tagged for swat may have an issue with the datastore fix in mesa :/22:27
RPI'll look tomorrow22:27
*** rpcme78 <rpcme78!> has joined #yocto22:27
*** rpcme <rpcme!> has quit IRC (Ping timeout: 246 seconds)22:30
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 272 seconds)22:43
*** rpcme78 <rpcme78!> has quit IRC (Quit: Client closed)22:45
*** rpcme <rpcme!> has joined #yocto22:46
*** Acki <Acki!~Acki@2a02:8109:a280:2d8d:a8b8:61e8:b7a1:56f9> has quit IRC (Ping timeout: 246 seconds)22:54
rpcmeI'm working on master-next so I can rework a layer for the override change.  When using bitbake on a clean run it's fine but when I run the target immediately after I'm getting a bad cache error.  Any thoughts?
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto23:18
rpcmeso I went back to master and it seems like meta-openembedded has this problem ... I giess will need to fix local: meta-openembedded/meta-oe/conf/layer.conf:NON_MULTILIB_RECIPES_append = " crash"23:20
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)23:21
rpcmeNow I have this: ERROR: Layer openembedded-layer is not compatible with the core layer which only supports these series: honister (layer is compatible with hardknott)23:23
rpcmeguess go back the master-next and just remove all the build directories for every test :(23:24
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)23:29

Generated by 2.17.2 by Marius Gedminas - find it at!