Wednesday, 2021-08-04

*** vmeson <vmeson!> has quit IRC (Ping timeout: 250 seconds)00:01
*** vmeson <vmeson!> has joined #yocto00:14
*** RP <RP!~richard@2001:8b0:aba:5f3c:96de:80ff:fe6d:2d2b> has joined #yocto00:16
*** prabhakarlad <prabhakarlad!> has quit IRC (Ping timeout: 246 seconds)00:21
*** Guest97 <Guest97!~Guest97@> has quit IRC (Ping timeout: 246 seconds)00:22
*** qschulz <qschulz!> has quit IRC (Read error: Connection reset by peer)00:32
*** qschulz <qschulz!> has joined #yocto00:34
*** mattsm <mattsm!> has quit IRC (Quit: Ping timeout (120 seconds))00:55
*** mattsm <mattsm!> has joined #yocto01:01
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)01:12
vmesonRP valgrind is working on fixes, I'll check on strace, elfutils tomorrow if no one gets there first.01:30
vmesonactually valgrind has a few commits that aim to deal with glibc-2.34 already on master but not released yet01:36
vmesonstrace has a new releae: 5.13 that deals with some of the glibc-2.34 borkage so patch coming for that tomorrow/this week depending on how keen you are.01:40
*** mihai- <mihai-!~mihai@user/mihai> has joined #yocto02:37
*** mihai <mihai!~mihai@user/mihai> has quit IRC (Ping timeout: 265 seconds)02:41
override gets installed as a command line tool, can someone help me understand how I run it in a python script by importing the bmaptools module (and using
overridelet me know if that makes sense..03:37
*** mranostaj <mranostaj!> has quit IRC (Remote host closed the connection)03:59
*** boo <boo!> has quit IRC (Ping timeout: 256 seconds)04:23
*** yates_work <yates_work!> has joined #yocto04:24
yates_workis there a default number of cores bitbake uses to process tasks?04:24
*** xmn <xmn!> has joined #yocto04:35
mihai-yates_work: yes, all :)04:56
*** mihai- is now known as mihai04:56
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 -
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto04:58
*** rpcme <rpcme!~rpcme@> has quit IRC (Ping timeout: 246 seconds)05:00
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 258 seconds)05:33
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:20
*** frieder <frieder!> has joined #yocto06:35
*** 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
*** zpfvo <zpfvo!~fvo@> has joined #yocto06:57
*** prabhakarlad <prabhakarlad!> has joined #yocto07:10
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 258 seconds)07:25
*** vd <vd!> has quit IRC (Ping timeout: 246 seconds)07:26
*** davidinux <davidinux!> has joined #yocto07:27
*** davidinux <davidinux!> has quit IRC (Ping timeout: 245 seconds)07:31
*** davidinux <davidinux!~davidinux@> has joined #yocto07:32
*** LetoThe2nd <LetoThe2nd!> has joined #yocto07:38
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)07:39
qschulzmichaelo: for bitbake-devel, I sent a diff on the ML as an answer to RP's original patch if that's what you were talking about? Or are you talking about yocto-docs?07:44
*** florian <florian!> has joined #yocto07:45
*** mranostaj <mranostaj!~mranostaj@> has joined #yocto07:49
qschulzRP: ok this is SUPER confusing now that some are overrides and some not. I see that tlwoerner and you were talking about SRC_URI for example yesteday. What's the logic behind whether overrides are used or not?07:56
qschulz(but I guess it's going to be answered in some of the comments in the diff I sent by mail since this SRC_URI_%s SRC_URI:%s change I did was one for which I had my doubts :)07:57
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:07
*** florian_kc <florian_kc!> has joined #yocto08:14
LetoThe2ndyo dudX08:15
florianhi all08:24
*** vmeson <vmeson!> has quit IRC (Ping timeout: 245 seconds)08:24
michaeloqschulz: yes, I was talking about about yocto-docs :)08:27
*** vmeson <vmeson!> has joined #yocto08:28
*** goliath <goliath!~goliath@user/goliath> has joined #yocto08:33
*** bizulk <bizulk!> has joined #yocto08:34
qschulzmichaelo: haven't started working on it. Did RP run his script on it (yocto-docs) by any chance so we don't have to start from scratch?08:51
RPqschulz: the script is in oe-core so anyone can run it. I did have a test run which I could share, or re-run it08:55
qschulzRP: no manual modification on top of that script run?08:56
qschulzmichaelo: There are a few _<something> which aren't overrides and shouldn't use the new syntax (since they are not overrides). The thing is, I don't know when they are overrides and when they aren't :/08:58
qschulzSo I'm not sure how to review docs patch or make them :/08:59
RPqschulz: I've not got to that, no09:01
RPqschulz: you could just mark those up and we could then check?09:02
michaeloqschulz, RP: I have already run the script. That's easy but maybe you could send me a patch first (if you have time) to mark as comments the statements you're thinking about, before I run the script.09:30
qschulzWe've discussedabout LAYERSERIES_COMPAT_<layer-name>, SRCREV_<src-name>, PREFERRED_VERSION_<pn-name>, IMAGE_TYPEDEP_<img-type>, etc...09:33
qschulzI won't probably send a patch first, so please go ahead :)09:33
qschulzmichaelo: I guess the first step is to commit the output of the script first09:36
qschulzmaybe we can share taskload by committing changes per file?09:37
qschulzusing a contrib branch or something, I don't know09:37
qschulzalso just so we're clear, I've just fixed a few issues in files modified by RP in his original patch for bitbake's doc but I haven't done a whole pass on the documentation to check if there's something he missed in some other files09:39
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 245 seconds)09:47
*** davidinux <davidinux!~davidinux@> has joined #yocto09:49
michaeloqschulz: thanks, I'll do that.09:51
yates_workmihai: truly? bitbake will auto-detect the number of cores and use them all?11:05
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto11:09
RPyates_work: yes, why wouldn't it?11:10
RPyates_work: you can override it (BB_NUMBER_THREADS and PARALLEL_MAKE)11:10
jsandmanHi again. I am getting this error still: "failed with exit code 'setscene whitelist'" when building the extensible sdk for my target machine. I tried runing a plain core-image-minimal using MACHINE=qemuarm and it worked ok but when trying for my own MACHINE I always get that at random tasks. I tried removing al the sstate_cache dire but did not11:11
jsandmanI have no idea where to start looking for that error.11:11
*** mranostaj <mranostaj!~mranostaj@> has quit IRC (Ping timeout: 258 seconds)11:11
RPjsandman: that error is a nightmare to debug :(11:12
yates_workRP: i guess that's no great feat. i just feel like i must vette everything that passes the optic nerve into the brain...11:12
RPjsandman: it means that the computed hash in the eSDK isn't matching what it was originally locked down to during the earlier build. Sadly bitbake doesn't know why :/11:13
jsandmanRP Do yo have any ideas of what things I can try to solve it? Maybe running everything from scratch may help re-generating those hashes?11:15
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)11:17
RPjsandman: I kind of doubt that would help much. I'd try and get the sigdata files for the hashes that are changing and try and understand why they're changing. Something about the things the MACHINE is setting must not be entirely deterministic11:18
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto11:19
RPjsandman: when you build that machine normally in a build are there recipes which always rebuild?11:19
jsandmanRP No that I know of. I just tried with the image build and got "Attempted 5007 tasks of which 5007 didn't need to be rerun and all succeeded." That is usually the case if nothing changes11:22
RPjsandman: right, it would have just been a much easier issue to debug if it were that11:22
RPjsandman: this issue with the eSDK really bugs me, I just wish I knew how to explain how to debug it in a sensible way :(11:23
jsandmanRP Yeah. Painful one. I have no idea where to start. I really appreciate any comment on this so thank you very much ;)11:25
RPjsandman: is it a public machine layer?11:29
jsandmanNope. This Machine configuration is part of this closed layer :S11:30
RPjsandman: I have echos of a memory of leaving in there as it was useful for some of these cases11:35
RPjsandman: I think if you enable that, the stamps dir should have basehash info in it and if it is the basehash component of the hash that varies, that would help11:36
RPyou'd have to figure out where the stamps dir esdk was using was11:36
RPand compare to your main stamps dir11:36
RPjsandman: what I can't tell is whether your base hashes are varying or whether it is the second task components that vary11:37
jsandmanAh great. That seems helpfull. I'll try to play with that and see if I can gather some info. How am I supposed to enable that code?11:45
RPjsandman: uncomment it11:46
RPjsandman: trying to improve this is something I've wanted to do for a long time11:47
jsandmanAh ok. Sorry I missed the line bit :D11:55
wyrehi guys, I'm following this answer to make a custom device tree, I'm following the Option two: Manual, the problem right now is that bitbake cannot generate the wic image because it cannot stat my custom .dtb file, maybe I need to add the .dts file to the Makefile like in here
wyreis this right?11:56
wyrei.e. do I need to patch the Makefile?11:58
jsandmanRP Thank you! I'll be trying that and I'll come back with what I see.11:58
qschulzwyre: yes11:59
*** mranostaj <mranostaj!~mranostaj@> has joined #yocto12:00
RPhmm, I think I may have figured out how to make devupstream work with native recipes. rburton might like that12:06
wyreqschulz, where should I place the patch file? apparently I could place into linux/linux-engicam/ because this dir has prepended to FILESEXTRAPATHS, right?12:11
qschulzwyre: yes12:15
JaMaRP: I see your IMAGE_TYPEDEP in master-next, thanks, next var should probably be CONVERSION_CMD to match with IMAGE_CMD behavior12:26
JaMaRP: and there is a missing quote in master-next branch in imagevars = ["IMAGE_CMD", "EXTRA_IMAGECMD", IMAGE_TYPEDEP"]12:29
*** xmn <xmn!> has quit IRC (Ping timeout: 256 seconds)12:33
RPJaMa: will fix, thanks12:44
*** vd <vd!> has joined #yocto12:48
RPJaMa: and then COMPRESS_CMD. I'll do those as well12:50
JaMaRP: found another maybe interesting case, VIRTUAL-RUNTIME_com.webos.service.flowmanager_armv4 isn't replaced because of dots before the override, will adjust the script for meta-webosose where I see many cases like this, then re-run it on oe-core/meta-oe to see how common it is12:50
wyreqschulz, apparently it's not patching the Makefile despite the file is fetched
wyrewhy is this?12:50
wyreoh, the problem was I was appending .dts instead .dtb to KERNEL_DEVICETREE var 😁12:58
RPJaMa: ah, interesting. I didn't know dots worked in variable names :/13:00
RPJaMa: I've sent a patch for CONVERSION_CMD and dropping COMPRESS_CMD13:00
*** frieder <frieder!> has quit IRC (Ping timeout: 268 seconds)13:08
JaMaRP: thanks13:10
JaMaRP: the dot might be also in package name, I've just noticed it in RDEPENDS:gstreamer1.0-meta-base:remove as well13:13
RPJaMa: ah, right, that will be why we support it13:13
*** frieder <frieder!> has joined #yocto13:20
*** BobPungartnik <BobPungartnik!~Pung@> has joined #yocto13:21
*** rpcme <rpcme!~rpcme@> has joined #yocto13:29
*** BobPungartnik <BobPungartnik!~Pung@> has quit IRC (Quit: Leaving)13:30
rpcmeIs layercheck broken on master?  It's weird that I'm getting an error 2 but nothing in the log itself shows there's an actual issue- maybe the commandline for layercheck is not correct but "it was working" before
*** boo <boo!> has joined #yocto13:32
rpcmePerhaps it is buried in the log somewhere. I'm running it thru an automated build system so if I can repro local that might help13:34
Alban[m]Is there some guidelines / best practices on how to choose a layer priority?13:37
LetoThe2ndAlban[m]: best practise: don't use priorities :)13:38
Alban[m]But openembedded-core and most layers define one13:39
LetoThe2ndAlban[m]: and bitbake-layers create-layer will also set one for your newly created layer. but if you rely on the priorities for some dirty trick to work, it's... a not-best practise.13:40
LetoThe2ndhence, just leave as-is.13:40
Alban[m]But if I override a file provided in one layer in another one the priority select the file used, or is that already a "dirty trick"?13:41
LetoThe2ndi think the standard values from poky/oe-core and layer creation will have that covered?13:42
Alban[m]so you mean that it is recommended to always use the default value, but what is the default value?13:43
LetoThe2ndnot "always" by defintion, but "stick to it until a different need actually arises"13:44
LetoThe2nda current generated layer.conf looks like this.
qschulzAlban[m]: depends of the order in FILESEXTRAPATHS and the name of your directory and subdirectory where your file resides13:45
qschulzbut yes, that could be a reason for a higher priority13:46
qschulzthough there are other ways to do it, use overrides or a "stronger" override for example13:47
Alban[m]right, i got confused here. What I'm hitting currently is that I need to backport psplash from dunfell to zeus. I have a layer I use for backporting but both recipe have the same version, just different revision, so here only the priority is useful.13:47
*** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:8c98:dc94:e871:3fdb> has joined #yocto13:49
qschulzAlban[m]: PREFERRED_VERSION_psplash in one of the configuration file ;)13:51
RPrpcme: I suspect it was the new dependencies change13:52
rpcmeRP: thank you - will look to tweak the command line.13:55
*** fitzsim <fitzsim!> has quit IRC (Quit: ERC (IRC client for Emacs 28.0.50))13:57
Alban[m]qschulz: That would also be a solution, although I would prefer a more generic one. I'm just surprised that the layer priorities don't seems to be clearly defined or documented.13:57
*** fitzsim <fitzsim!> has joined #yocto13:57
wyreqschulz, I've removed this part in a new custom dts file (called imx6ull-joifi.dts, as you have seen in previous links I pasted) and bitbake is building it and producing its corresponding dtb file, but when I flash and boot the system ... the gpios are still requested 😞13:59
wyrewhy do you think is this?13:59
Alban[m]qschulz: I mean regarding the values to use, not what it does13:59
wyremaybe is not enough just removing the gpio_export node πŸ€”13:59
qschulzAlban[m]: it's an integer so not sure to understand the question?14:00
qschulzwyre: very likely that you're still booting the old device tree14:00
Alban[m]why has oe-core 5., what would be the recommended value for a bsp layer, for a distr layer, and so on14:01
qschulzyou'll need to do modifications in your u-boot logic to boot the correct one14:01
LetoThe2ndAlban[m]: i would say "usually the lowest possible", but... it depends.14:01
Alban[m]depends on what?14:02
LetoThe2ndAlban[m]: but then, thats what i meant by: if you rely on the priorities to make your build work, you're in trouble anyways.14:02
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:02
wyreqschulz, I've flashed the NAND with the new dtb so ... could be the old device tree being loaded?14:02
LetoThe2ndAlban[m]: first and foremost, on your layer stack.14:02
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto14:02
LetoThe2ndAlban[m]: because a) layers are meant to be shared and reused b) your way of using a layer might be different from somebody elses.14:03
qschulzwyre: cat /proc/device-tree/* to check the device tree being used14:03
wyreyes, sorry, it was my fault14:03
qschulznot directly this command but files in those dirs/subdirs14:03
LetoThe2ndso if you're imposing a hard rule on the priority structure, for example "middleware takes precedence over BSP", then you define that one use case is better than the other.14:03
wyreI was pasting the normal dtb as imx6ull-joifi.dtb in the tftp14:04
wyreso sure, I was flashing again the very same πŸ˜₯14:04
Alban[m]LetoThe2nd: let say I have a backport layer, shouldn't it make sure that its recipes override the ones from oe-core?14:04
LetoThe2ndAlban[m]: and if you stick to the defaults, it will have right from the start, or did i get that wrong?14:04
Alban[m]well some recipes, like psplash, didn't increased their version between oe-core releases14:05
Alban[m]so which version is taken depend on the lexical order of git git revision, so it is basically random14:06
wyrenow its working qschulz 😁14:06
wyrethank you14:06
LetoThe2ndAlban[m]: what is the difference then? because then a) theres either a bug (internal version change without recipe version bump) or b) backporting an unchanged version doesn't make much sense to me.14:07
Alban[m]dunfell has version  0.1+gitAUTOINC+0a902f7cd8 and zeus has 0.1+gitAUTOINC+2015f7073e14:08
Alban[m]so on version compare the zeus version win, although it is older14:08
LetoThe2ndAlban[m]: and what is the PR, respectively?14:08
wyrewhat are those fixed regulators for? πŸ€”14:09
wyreI'm wondering if I could remove them also14:09
qschulzAlban[m]: not random, depends on BBFILE_PRIORITY and the order in which the layers are listed in global BBLAYERS in bblayers.conf14:09
Alban[m]both have r1514:09
Alban[m]random if both layer have the same priority14:09
qschulzwyre: regulators are for power, so you might disable power for some things if you do it. Sometimes (often) they are required14:10
LetoThe2ndAlban[m]: but in that case i would call that a bug: the recipe has been modified, but no PR increase.14:10
qschulzAlban[m]: no, then it depends of the order in BBLAYERS14:10
Alban[m]random because the git revision hash is basically random14:10
wyreqschulz, you mean for internal things in the SoM? or in the carrier?14:10
qschulzwyre: both14:11
LetoThe2ndhah well ok, git is injected into PV then... problematic.14:11
LetoThe2ndi might be wrong, but technically i would call the recipe buggy.14:12
Alban[m]it looks like many recipe in oe-core are doing exaclty this14:15
RPAlban[m]: in the final packages, AUTOINC should become a number which is increased by the PR server14:16
Alban[m]does that help if the wrong recipe is parsed?14:17
LetoThe2ndRP: but if PR isn't being incremented, then?14:17
RPLetoThe2nd: is the PR server enabled?14:17
LetoThe2ndRP: can that be assumed as given for any build based on oe-core?14:18
RPLetoThe2nd: I don't think we default to that being on by default any more14:18
Alban[m]but wouldn't it need to build both version to then select the correct one?14:19
LetoThe2ndAlban[m]: parse, but not build.14:19
LetoThe2ndRP: but them bumping SRCREV without bumping PR shouldn't be allowed? or am i missing something stupid?14:19
Alban[m]AUTOINC doesn't seems to come into play at parse time14:21
RPLetoThe2nd: it is only an issue if trying to do package manager upgrades on target14:24
LetoThe2ndRP: then we are obviously now seeing a new case - what happens if both versions happen to be present in the metadata?14:25
LetoThe2ndi *think* just slapping on a priority is going to make it fly, but it feels wrong (at least to me)14:26
Alban[m]setting the priority works, raising PR doesn't14:27
LetoThe2ndthen it's very possible that my brain has a massive misconception of things there :-(14:27
Alban[m]all this wouldn't be a problem if psplash version had been increased between oe-core relases14:28
LetoThe2ndAlban[m]: well many problems stick to a version for a long time and only git bump, so thats not exactly a good argument for the generic case.14:30
LetoThe2ndproblems = projects.14:30
JPEWLetoThe2nd: I liked the original wording better :)14:31
LetoThe2ndJPEW: hehe14:31
Alban[m]sure, but that's probably the reason why this didn't showed very often14:32
Alban[m]so currently for a backport layer to work properly it need to have a priority higher than all the layer it wants to override14:32
LetoThe2ndAlban[m]: which it will already have in the vast majority of cases without even thinking about it.14:33
LetoThe2ndso from my POV: this is a corner case which seems to be handled improperly at the moment technically, but without much trouble being caused due to good choice of defaults.14:36
Alban[m]I would be nice if these "good choice of defaults" were documented somewhere. The current doc is barely understandable:14:39
Alban[m]A larger value for the BBFILE_PRIORITY variable results in a higher precedence. For example, the value 6 has a higher precedence than the value 5. If not specified, the BBFILE_PRIORITY variable is set based on layer dependencies (see the LAYERDEPENDS variable for more information. The default priority, if unspecified for a layer with no dependencies, is the lowest defined priority + 1 (or 1 if no priorities are defined).14:40
Alban[m]This doesn't help at all in choosing a correct value14:40
LetoThe2ndAlban[m]: feel free to send improvements! :)14:40
Alban[m]I would need, beside time, to know what the "good defaults" are to be able to do that14:41
LetoThe2ndAlban[m]: i told you. essentially, an hour ago.14:41
LetoThe2nda current generated layer.conf looks like this.
LetoThe2ndgenerated ==  uses the default value, obviously14:42
Alban[m]So 6 is the recommended default?14:42
Alban[m]but meta-python for example has 714:42
LetoThe2ndAlban[m]: 6 is the default value for a newly created layer. if that qualifies as "recommended", i can't judge.14:42
Alban[m]that's why I asked for recommendation before, the answer was "don't set it"14:45
LetoThe2ndno. i said, create your layer with bitbake-layer layer-create, and leave as is.14:45
LetoThe2nd(at least i'm pretty sure i did)14:46
LetoThe2ndanyways - i think there is little more to say. we have found, identified and discussed a corner case. action needed? questionable. a hard recommandation? probably won't be. so, thats it from my side unless something really new is brought to the table now.14:47
Alban[m]action needed would be better documentation, but that's not possible as long as there is no clear explanations on how to select a "good" value14:49
qschulzAlban[m]: because the good value depends on the context. what we would probably welcome in the documentation would be that bitbake-layers create-layer provides a default (and should actually be used to avoid user errors/typos). I'm not sure it makes much sense to define a "good default" since it depends on context and which layers you include14:54
Alban[m]I understand that, but some general advice would be helpful. Telling ppl to just blindly use a tool doesn't help those that have to deal with existing setups or want to understand14:56
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto14:58
qschulzif the existing setup isn't doing what you want, you need to increase/decrease the priority as explained in the documentation of BBFILE_PRIORITY. If you want to understand what's going on, looking at the priorities of all layers and the documentation of BBFILE_PRIORITY should help. If you are creating your own layer, use bitbake-layers create-layer which provides some default. Then go back to the14:59
qschulzbeginning of this message if it does not work the way you want14:59
*** goliath <goliath!~goliath@user/goliath> has joined #yocto15:00
qschulzif there could be better wording of the documentation of the variable is debattable but I'm not sure there's a way to define a 'good value'/general advice15:00
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto15:05
*** rpcme <rpcme!~rpcme@> has quit IRC (Quit: Client closed)15:11
*** rpcme <rpcme!~rpcme@> has joined #yocto15:15
Alban[m]qschulz: thank you15:20
*** bizulk <bizulk!> has quit IRC (Quit: Client closed)16:09
*** zpfvo <zpfvo!~fvo@> has quit IRC (Remote host closed the connection)16:24
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 258 seconds)16:31
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:33
*** frieder <frieder!> has quit IRC (Remote host closed the connection)16:33
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 258 seconds)16:37
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)16:38
*** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:8c98:dc94:e871:3fdb> has quit IRC (Quit: Client closed)16:39
*** sakoman <sakoman!~steve@> has joined #yocto16:56
*** vd <vd!> has quit IRC (Quit: Client closed)16:58
RPvmeson: since the strace upgrade seems simple, I've queued an upgrade for testing for that17:00
*** rpcme <rpcme!~rpcme@> has quit IRC (Quit: Client closed)17:01
*** rpcme <rpcme!~rpcme@> has joined #yocto17:02
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto17:02
RPvmeson: bug filed to compile info on elfutils ptest issue:
khemRP:  where can I find the ptest logs for strace and valgrind? IIRC valgrind issue was reported earlier too17:25
RPkhem: here:
RPkhem: I have an upgrade patch for strace in master-next to test, see if that helps. valgrind sounds like we need some backports from master17:25
*** LetoThe2nd <LetoThe2nd!> has quit IRC (Quit: Connection closed for inactivity)17:26
khemRP:  I see use of FILES_${PN} on RHS see
khemshould new override seprate work in this case ?17:27
RPkhem: no, that needs to be converted to :17:28
RPkhem: well, yes, if you convert it, it will work17:28
khemright ok17:28
smurrayRP:  I seem to be having some issues getting either the python "-X dev" or PYTHONDEVMODE=1 env variable down into bitbake child processes w/o ending up overly invasive and ending up in target build env, any suggestions?17:41
RPsmurray: I think the question is why bitbake processes? Things started by the server or by the worker?17:45
smurrayRP: there's some asyncio debugging enabled with it that I want to see on both the server and hashequiv/prserver children17:46
smurrayRP: there's also PYTHONASYNCIODEBUG=1 as a hook for that, but it looks like dev mode also makes debug logging the default for the logging module w/o having to hack that17:47
RPsmurray: those are started from the server so it sounds like you want bitbake's server started with that?17:48
smurrayRP: I tried hacking it into the bitbake-server wrapper but it didn't seem to take effect that way17:49
smurrayRP: I then wrapped python3 with a script, but that ends up too invasive17:50
RPsmurray: hmm. It should :/17:50
smurrayRP: I can try again, maybe I missed something17:50
smurrayRP: semi-related, is there a hook for changing the logging level other than passing -d to bitbake?17:51
RPsmurray: you can pass a custom log levels definition17:52
smurrayRP: okay, I guess I'll pick apart the oe-selftest that fails and work out running it by hand so I can try that17:53
RPsmurray: logconfig = args.builddir + "/../bitbake/contrib/autobuilderlog.json" os.environ["BB_LOGCONFIG"] = logconfig17:53
smurrayRP: okay17:54
RPvmeson, khem: I pulled in a few valgrind patches and tried a build17:55
*** florian_kc <florian_kc!> has joined #yocto17:56
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)18:00
smurrayRP: do the bb.debug/note/etc. messages go through the logging module at this point, or do they use a separate mechanism altogether?18:02
RPsmurray: they should go through it18:02
smurrayRP: okay, trying to wrap my head around where messages are ending up18:03
RPsmurray: our logging needs work, its a mess18:04
RPsmurray: I sometimes resort to writing things to a file18:05
*** amitk <amitk!~amit@> has quit IRC (Remote host closed the connection)18:05
smurrayRP: I've instrumented a bunch with bb.note, but I'll have to try to correlate with multiple files or hack the config json if I can get this other stuff enabled18:06
RPsmurray: fair enough, just mentioning what I sometimes resort to18:09
smurrayRP: yeah, I might end up there ;)18:10
rpcmeRP: just to let you know I'm back in the green on the yocto-check-layer.  It was the dependencies for sure.  Takes more than 1h to run on 2 VCPU so I bumped it up to 72 VCPU to finish in 11 minutes.  That might be a reasonable duration for PR checks as well.18:12
moto-timothere are some commented out settings in local.conf.sample that will also need the new override syntax conversion such as PACKAGECONFIG_append_*18:17
*** amitk <amitk!~amit@> has joined #yocto18:23
RPrpcme: that code does metadata parses which can take advantage of cpu cores18:26
RPmoto-timo: hmm, I thought I got those :(18:27
RPmoto-timo: hmm, the extended one?18:27
moto-timoI just noticed it because I had to upgrade my auh local.conf…18:28
RPmoto-timo: got it, will fix18:29
* moto-timo being lazy18:29
moto-timoAlso I’m not 100% confident on the new syntax just yet18:30
RPmoto-timo: well, I've fixed it as I can do that in the time it would take to discuss it18:30
moto-timo(My own understanding needs practice)18:30
moto-timoThank you. Apologies for being lazy18:31
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)18:40
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 258 seconds)18:56
*** rfried <rfried!> has quit IRC (Quit: The Lounge -
*** yates_work <yates_work!> has quit IRC (Remote host closed the connection)19:00
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto19:00
*** wing0 <wing0!~wing0@2804:431:c7ec:d24:d63c:1018:c1ed:8754> has joined #yocto19:02
*** rfried <rfried!~rfried@> has joined #yocto19:18
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 258 seconds)19:20
*** vd <vd!> has joined #yocto19:28
*** stwcx <stwcx!> has joined #yocto19:34
stwcxHello. I'm trying to build an image using hardknott and running into a problem that I have no idea how to debug.  Uninative vs sysroot-native is something I've not really dug enough into before.19:36
stwcx| re2c: .../tmp/sysroots-uninative/x86_64-linux/usr/lib/ version `GLIBCXX_3.4.29' not found (required by re2c)19:36
stwcxMy system has GCC 11, and it seems like re2c was built against my system libstdc++, but...19:36
stwcxWhen it gets used during the build of `ninja` it ends up using the out of the uninative.19:37
RPstwcx: are you using the latest uninative?19:37
RPstwcx: it is expected it would switch to use uninative as that is how it works19:37
stwcxRP: I think the "latest" that comes with hardknott, yes.19:37
stwcxShouldn't re2c have built with the uninative libstdc++ then too?19:38
RPstwcx: do you have ?19:38
RPstwcx: it builds against the host, then switches at install time for 'reasons'19:39
stwcxRP: checking that I haven't messed something up with that
stwcxAh, I don't have that uninative bump.  It takes me 3 hops to get subtree updates with the build that we have, so ... :(19:41
RPstwcx: hence my question :) that would explain it19:42
stwcx> it builds against the host, then switches at install time for 'reasons' --- this is interesting to know.  For some reason I thought everything always built against the uninative libraries.19:42
RPstwcx: uninative doesn't ship with headers and if it did, it gets very confused with the host's headers. It is much easier to link against the host, then switch19:43
RPIt just means the uninative needs to be equal or newer than the host19:43
*** roussinm <roussinm!> has joined #yocto19:43
stwcxSorry for the distraction.  It is too bad the whole #freenode bifurcation happened.  #openbmc went to Discord instead so I don't really log in here to IRC anymore.19:43
RPit is supposed to detect and error about that but detecting all the versions of gcc/glibc can be tricky19:44
RPstwcx: that whole business is rather sad :(19:44
*** rpcme <rpcme!~rpcme@> has quit IRC (Quit: Client closed)19:45
stwcx"uninative needs to be equal or newer than the host" ... this is partially surprising for doing ancient builds.  We still have some images that we use Rocko as the base for.  I've been lucky thus far that the crops/poky Docker image works for me.19:45
stwcxAnything Rocko I use that crops/poky image but anything newish I use my host.19:46
RPstwcx: the nice thing is that newer uninatives tend to work fine with older releases19:46
stwcxSo in theory we could just backport a change to the checksums and pick up a new uninative?19:46
RPstwcx: in theory yes19:46
stwcxSounds good.  I'll keep that in the back of my mind.19:47
stwcxThanks much for your help and explaination.19:47
RPstwcx: np, nice to have an easy answer to something :)19:48
smurrayRP: I think I have a theory now, during PR export the code in creates a connection and caches it in the datastore.  With the rework as it is ATM, this means every parsing process doing export calls uses the same asyncio loop, which eventually splodes...19:52
*** vmeson <vmeson!> has quit IRC (Quit: Konversation terminated!)20:00
vdIMAGE_INSTALL_append_pn-some-image-recipe = " foo" works, right?20:01
vdif I want to add the "foo" package to some-image-recipe from a multiconfig20:05
smurrayyes, barring the change in override syntax in latest master20:07
smurrayit'd be IMAGE_INSTALL:append:pn-some-image-recipe now, I believe20:07
vdI guess it'll fail or warn when I'll bump, no big deal.20:08
vdI have a complex set of stacked images, and appending packages this way to the images from the same multiconfig file is quite neat20:09
vdit gives a complete view of the customization for a specific build20:10
*** rpcme <rpcme!~rpcme@> has joined #yocto20:12
*** vmeson <vmeson!> has joined #yocto20:14
*** florian_kc <florian_kc!> has joined #yocto20:17
stwcxI'm learning about this new override syntax today too. :/  Since there is no backwards compatibility for the old _ syntax that means it is pretty much impossible to have a single metalayer support two different branches now?20:20
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)20:20
rpcmethat's right - that is why layer maintainers had to change the layer compat20:26
*** wing0 <wing0!~wing0@2804:431:c7ec:d24:d63c:1018:c1ed:8754> has quit IRC (Quit: WeeChat 3.1)20:27
stwcxThat's really ugly.20:28
rpcmeI was very unnerved about the change on Monday but after working with it a couple days I'm liking it a lot. Although we're maintaining 4 releases and breakfix on four more, I'm OK with it20:28
stwcxUnfortunately we maintain a single tree and swap out the poky stuff depending on which system we're targeting.20:28
rpcmeYah we tried that but there were too many nuances requiring conditions, it made it worse to maintain and hard to tell what was bitrot or not.  Then I became a YP release branch convert...20:30
*** boo <boo!> has quit IRC (Ping timeout: 272 seconds)20:32
*** wing0 <wing0!~wing0@2804:431:c7ec:d24:d63c:1018:c1ed:8754> has joined #yocto20:39
smurraystwcx: there's forward compatibility in bitbake for dunfell forward, so doing the conversion in a layer that needs to support in that range forward is hopefully doable20:44
stwcxOooh.  That sounds better.  So you're saying that in theory you could convert recipes that are targeting at least Dunfell and they'll work?  I assume this means there is a bitbake update for them also?20:45
RPstwcx: we did backport changes to dunfell/gatesgarth/hardknott which mean the new syntax works over those releases and master20:46
RPstwcx: just realised smurray covered it :) Yes, there was a bitbake update to do that20:46
smurrayRP: my phrasing wasn't great20:47
RPsmurray: not sure mine is either tbh :)20:47
vdwhat is the recommended way to package ${DEPLOY_DIR_IMAGE}/some-image-recipe.img into the rootfs?20:49
smurrayRP: I'm pretty sure now what I mentioned above is the issue with the prservice selftest hangs with the rework, same issue JPEW's change last week addressed but in a different context20:50
stwcxI must be misunderstanding this:20:51
stwcx>     Supporting mixed syntax isn't possible, it is only feasible to have20:51
stwcx>    one internal representation of overrides.20:51
stwcxSo if you've backported the changes to bitbake, how does it know which one to use?20:52
RPstwcx: it just converts ":" into "_" in older bitbakes20:52
*** EdTanous <EdTanous!~ed@> has joined #yocto20:52
RPsmurray: ah, I missed that comment. That sounds like a promising lead20:53
smurrayRP: the simple fix is to pull out the caching of the client connection object in meta/lib/oe/, I'm currently debating if there's something to be gained by trying to keep that while hacking on things to delay connecting20:55
*** boo <boo!> has joined #yocto20:57
smurrayRP: there's no obvious way to open the connection once and then reuse that connection now, since the connection is done with an asyncio call.  I suspect a minor diff in export performance isn't a big deal, though...20:59
RPsmurray: I suspect it would be best to pull it out and then we can look at performance again if it is an issue21:02
smurrayRP: yeah.  I don't see a way with asyncio to reuse an open socket, but I could be missing something21:05
*** vd <vd!> has quit IRC (Ping timeout: 246 seconds)21:09
smurrayRP: I'll bang on it in a test loop for a while before declaring victory.  I start some vacation tomorrow, but I can pick at it a bit remotely and try to get an updated patch set out in the next few days21:15
smurrayRP: one of the changes in my stack ATM is from JPEW, it'll need to go in IMO21:15
*** dkl <dkl!> has quit IRC (Remote host closed the connection)21:15
*** dkl <dkl!> has joined #yocto21:16
RPsmurray: it'd be great to get this in and resolved!21:16
smurrayRP: you're not alone in that thinking ;)21:16
*** ant__ <ant__!> has joined #yocto21:16
RPsmurray: I'm just wary as the last thing I need is another weird autobuilder intermittent issue!21:17
smurrayRP: definitely21:17
smurrayRP: I think with JPEW's change to move the loop creation for the server side and this fix it'll hopefully hold up now21:19
RPsmurray: it sounds promising21:22
JaMaRP: I've reproduced that systemd-boot issue on one of my hosts, it looks like it uses hosttools/ld.bfd when available instead of ld.bfd from binutils-cross21:26
RPJaMa: ah, that sounds a bit nasty but good to know the issue21:28
JaMaRP: I will use ${BUILD_PREFIX}ld.bfd which should match with what ${LD}[0] has except the .bfd suffix21:29
RPJaMa: sounds good21:33
RPvmeson, khem: just to keep up to date, the list of valgrind issues with reduced with backported patches. I opened a bug to keep track from here21:34
RPand there is an elfutils patch available I can try testing21:34
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)21:36
moto-timofor the python3-scons upgrade to 4.2.0 I tested a build of serf (the only component in core that inherits scons) but if anybody depends on it for other things please test21:39
stwcxHas any issues with a high amount of "pseudo aborts" been reported lately?  I'm seeing them pretty frequently with simple package rebuilds.21:54
smurrayit's almost always an indicator of a recipe doing untoward things:
RPstwcx: we should have fixed the ones in core but if you have a bug in your own layer...22:02
*** rpcme <rpcme!~rpcme@> has quit IRC (Quit: Client closed)22:27
*** creich <creich!> has quit IRC (Remote host closed the connection)22:27
stwcxsmurray: Yes, I'm aware of the usual cause.  These are simple "compiled with meson" C/C++ packages that aren't doing anything odd.22:30
stwcxRP: Hmm.  Yes, I saw you had some fixes but I think I picked all those up now and am still seeing them.  I'll double check.22:30
*** stwcx <stwcx!> has quit IRC (Quit: Connection closed)22:36
*** alejandr1 <alejandr1!> has quit IRC (Read error: Connection reset by peer)22:40
*** alejandr1 <alejandr1!> has joined #yocto22:41
*** rpcme <rpcme!~rpcme@> has joined #yocto22:54
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)22:58
*** otavio <otavio!> has quit IRC (Ping timeout: 245 seconds)23:35
*** otavio <otavio!> has joined #yocto23:37
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)23:41
*** otavio <otavio!> has quit IRC (Read error: Connection reset by peer)23:56

Generated by 2.17.2 by Marius Gedminas - find it at!