Thursday, 2021-09-23

*** dev1990 <dev1990!~dev@> has joined #yocto00:04
*** jessequinn <jessequinn!~jessequin@2804:30c:92b:df00:c181:f92e:73c8:3f5f> has quit IRC (Ping timeout: 264 seconds)00:12
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)00:29
*** camus1 <camus1!~Instantbi@> has joined #yocto00:50
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 265 seconds)00:52
*** camus1 is now known as camus00:52
*** jwillikers <jwillikers!> has quit IRC (Read error: Connection reset by peer)00:54
*** jwillikers <jwillikers!> has joined #yocto00:55
tlwoernerndec_: on the dragonboard-410c, is it possible to stop the boot in the bootloader (lk?) and modify a variable? i'd like to change the kernel's cmdline args01:01
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:c506:d5e9:1cbc:a4ba> has joined #yocto01:12
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:c506:d5e9:1cbc:a4ba> has quit IRC (Ping timeout: 246 seconds)01:19
*** sakoman <sakoman!~steve@> has quit IRC (Read error: Connection reset by peer)01:29
*** sakoman <sakoman!> has joined #yocto01:46
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)01:51
*** jwillikers <jwillikers!> has quit IRC (Remote host closed the connection)02:08
zeddiitlwoerner: was it you that had the bsp config question ? If so, I'll dig something up tomorrow. I was buried in trying to get 5.14 out for review.02:19
tlwoernerzeddii: yes that was me, sorry. i knew you were busy and asked anyway :-(02:19
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)02:53
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:f91c:1508:8151:e3ae> has joined #yocto03:12
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:f91c:1508:8151:e3ae> has quit IRC (Ping timeout: 246 seconds)03:18
*** arlen <arlen!> has quit IRC (Ping timeout: 265 seconds)03:29
*** amitk <amitk!~amit@> has joined #yocto04:17
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 -
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto04:34
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:c48e:c11e:e435:2f4> has joined #yocto05:11
*** ThomasD13 <ThomasD13!> has joined #yocto05:18
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:c48e:c11e:e435:2f4> has quit IRC (Ping timeout: 264 seconds)05:19
*** vd <vd!> has quit IRC (Quit: Client closed)05:25
*** rob_w <rob_w!> has joined #yocto06:36
*** tnovotny <tnovotny!> has joined #yocto06:45
*** mckoan|away is now known as mckoan06:45
mckoangood morning06:45
JosefHolzmayr[m]yo dudX and mckoans06:46
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:a1df:b4f8:5d2e:2f3e> has joined #yocto06:46
*** fbre <fbre!~fbre@> has joined #yocto06:49
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:a1df:b4f8:5d2e:2f3e> has quit IRC (Ping timeout: 246 seconds)06:50
ndec_tlwoerner: there is no 'shell' in lk. so you can't do that at run time, you need to update the boot image on the host. the bootargs are in the boot image, so you don't need to rebuild anything, abootimg can do it.06:52
*** frieder <frieder!> has joined #yocto06:53
*** frieder <frieder!> has quit IRC (Remote host closed the connection)06:54
*** frieder <frieder!> has joined #yocto06:55
*** roussinm <roussinm!> has quit IRC (Quit: WeeChat 3.3-dev)06:56
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)06:57
*** zpfvo <zpfvo!~fvo@> has joined #yocto06:58
*** rob_w <rob_w!> has joined #yocto07:03
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 265 seconds)07:07
*** Sion <Sion!> has joined #yocto07:08
*** mattsm <mattsm!> has quit IRC (Read error: Connection reset by peer)07:08
*** mattsm <mattsm!> has joined #yocto07:08
*** camus <camus!~Instantbi@> has joined #yocto07:10
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 260 seconds)07:12
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto07:14
*** argonautx <argonautx!> has joined #yocto07:27
*** camus1 <camus1!~Instantbi@> has joined #yocto07:31
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:32
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)07:33
*** camus1 is now known as camus07:33
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto07:36
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Read error: Connection reset by peer)07:37
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto07:37
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto07:48
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Client Quit)07:50
qschulztlwoerner: re meta-rockchip and the mmc interface ordering, it's just a patch or two to apply to the device tree. Basically you need mmc aliases in the dts/dtsis07:59
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto08:05
*** florian <florian!> has joined #yocto08:26
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)08:29
*** camus <camus!~Instantbi@> has joined #yocto08:30
ThomasD13Hi guys. I have a lot of machine configuration appends scattered in recipes. I've added now a second machine. Is there a mechnizm by yocto supplied to apply all these appends "j7-evm" also to my new machine configuration?08:30
ThomasD13Without copying and replace these appends with the new machine configuration08:30
qschulzThomasD13: MACHINEOVERRIDES08:31
ThomasD13thanks qschulz I ll investigate :)08:32
ThomasD13I've read this term, but didn't fully understand what it does exactly08:33
ThomasD13Lets assume I have a variable SRC_URI_j7-evm = "github". When I start the build for machine j7-evm, the variable SRC_URI is set to "github". When I start the build for machine j7-paradise it is not.08:38
fbreHi! Is there a command line call which outputs the used yocto linux version?08:38
ThomasD13Adding in j7-paradise machine configuration MACHINEOVERRIDE = "j7-evm" will set SRC_URI to "github" when I execute the build for j7-paradise?08:38
fbre...on my target device which is running yocto Linux08:39
dwagenktheyoctojester: I send those patches regarding the license implications of INITRAMFS_IMAGE_BUNDLE. Another possibly mistaken interpretation I have got: Adding the kernel and the initramfs to a combined FIT image does NOT make the kernel+initramfs a derivative work in the sense of GPLv2. Thus the initramfs may contain proprietary (GPL incompatible) programms. Any take (or pointers to documentation saying otherwise?)08:39
qschulzThomasD13: yes, except you should use MACHINEOVERRIDES =. "j7-evm" before any include in your machine configuration file08:40
dwagenkon that?08:40
qschulzdwagenk: fitimage is just a container for artifacts08:40
*** xmn <xmn!> has joined #yocto08:41
JosefHolzmayr[m]dwagenk: nothing that i can comment on, sorry.08:41
qschulzso yes, to me this is just fine (and the industry would sweat big time if that wasn't the case as many use initramfs for RO rootfs), but no lawyer again08:41
ThomasD13Thank you very much qschulz :)08:42
dwagenkThanks for the comments anyhow. Just trying to get a grasp of what is considered industry-standard and OK in this context.08:43
qschulzdwagenk: I would say that initrd should be pretty rare since it means you need to recompile (and reflash) the kernel every time you do a rootfs change08:44
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Remote host closed the connection)08:46
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto08:46
dwagenkBefore diving deeper into INITRAMFS_IMAGE_BUNDLE and theyoctojester s pointer to the kernel docs I was not aware of the initramfs actually being passed into the kernel build and thus beeing affected by the GPL. I hope the proposed note in the yocto manual makes this potential problem obvious to users.08:47
*** goliath <goliath!~goliath@user/goliath> has joined #yocto08:48
qschulzI didn't know either tbf :)08:49
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 252 seconds)08:52
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto08:53
*** camus1 <camus1!~Instantbi@> has joined #yocto08:59
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)09:00
*** camus1 is now known as camus09:00
*** meego <meego!~meego@2001:41d0:fe7e:c800:102d:4773:7c5b:de6b> has joined #yocto09:07
*** kayterina <kayterina!> has joined #yocto09:13
*** meego <meego!~meego@2001:41d0:fe7e:c800:102d:4773:7c5b:de6b> has quit IRC (Quit: Leaving...)09:16
*** meego <meego!~meego@2001:41d0:fe7e:c800:102d:4773:7c5b:de6b> has joined #yocto09:16
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 265 seconds)09:24
*** camus1 <camus1!~Instantbi@> has joined #yocto09:24
*** camus1 is now known as camus09:27
JosefHolzmayr[m]i guess i'm missing something super obvious, but why does this recipe err out during parsing?
JosefHolzmayr[m]override syntax biting me?09:39
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Ping timeout: 246 seconds)09:40
*** guid <guid!> has joined #yocto09:40
JosefHolzmayr[m]yup. needs. :${PN}09:40
ThomasD13MACHINE=j7-paradise bitbake image gives me an build error at specific package. MACHINE=j7-paradise bitbake specific-image however says "package specific-package was skipped: incompatible with with machine j7-paradise".09:42
guidHi. I have a recipe A that installs a file foo.cert in /usr/local/share/ca-certificates. Now, I've got a recipe B that install a file and I need to inject the foo.cert of the recipe A into my (via sed). I added A as a dependency of B (DEPENDS = "A") but I don't know what task I should use for the injection. Can I do it in the09:43
guiddo_install task?09:43
ThomasD13How does this make sense? Why is this package build for the image, even it is not compatible to the machine?09:43
mckoanJosefHolzmayr[m]: that will be a frequent error in the future :-(09:44
qschulzThomasD13: because something pulls it in for you10:03
*** beneth <beneth!~beneth@2001:41d0:c:a71:1000:25::> has quit IRC (Quit: Gateway shutdown)10:21
*** GillesM <GillesM!> has joined #yocto10:23
barathis there documentation on what could cause something like `ERROR: Setscene task /var/jenkins/persistent_environment/layers/poky/meta/recipes-core/packagegroups/ in both covered and notcovered.` ?10:26
barathI assume it has something to do with dependencies, run-order and the sstate cache...10:26
kanavinmoto-timo, how's your progress with phosh?10:32
*** camus1 <camus1!~Instantbi@> has joined #yocto10:32
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 268 seconds)10:34
*** camus1 is now known as camus10:34
*** Net147 <Net147!~Net147@user/net147> has quit IRC (Quit: Quit)10:35
*** Net147 <Net147!> has joined #yocto10:37
*** mckoan is now known as mckoan|away10:38
RPbarath: there was a bug open for that and it had fixes in master recently. Which version of the project is that?10:41
barathyeah just found that one, but we're not seeing any warnings about "Runqeueue deadlocked on deferred tasks"10:43
barathit's dunfell10:44
barathwe've never consciously seen this before. I'm trying to read the but I haven't fully grokked what covered and notcovered actually mean in this context10:45
*** jorschulko <jorschulko!> has joined #yocto10:45
RPbarath: the same task should never be on both so there is a bug somewhere :(10:45
RPbarath: I think dunfell and hardknott are getting some of these fixes queued up for them and they might help your case too10:46
barathRP: alright, thanks. so at least we're not alone. but does it make sense that we're not seeing the warnings about deferred tasks? form the issue ticket it seems like that's an indication10:46
barathand what's notcovered/covered? stuff "already run"?10:47
barathor already parsed?10:47
*** Guest4 <Guest4!> has joined #yocto10:47
*** Guest4 <Guest4!> has quit IRC (Client Quit)10:47
RPbarath: there are two stages to execution of tasks, "from sstate" and "real". covered and notcovered are two lists that real tasks get put into depending on whether the sstate was available and meant they weren't needed or not. One task should never be both10:48
*** martin31821 <martin31821!> has joined #yocto10:49
RPThat check was added as a sanity check to find problems and give a warning before bad things happen10:49
barathhm okay. so "real" tasks get put into "notcovered" when no sstate cache is available for them?10:51
barathwe've recently changed our build setup to hopefully reuse previously generated sstate cache files more, so maybe it's a symptom of that10:51
RPbarath: effectively but real and sstate tasks aren't one to one mappings10:51
RPbarath: that would make this worse, yes10:51
barathRP: alright, thanks! then we have something to go on. if necessary I'll try backporting the fixes for us locally and otherwise I'll keep a watch out for any fixes that trickle down to dunfell10:55
RPbarath: it was a pain to track down and debug but I'm hoping it is at least fixed in master10:57
jorschulkoHi, we are currently in the process of reworking the google repo fetcher and have the following problem: We need to run repo sync every time, as checking for SRCREV changes within the manifest repo is not enough. That's because the manifest itself might reference a branch within the sources repo and thus the sources can still change. The easiest way to accomplish this that we could think about is adding10:57
barathsounds like it10:57
jorschulkoa timestamp to the latest revision. That would force yocto to rerun do_fetch every time. However, this would also make offline builds impossible. Any ideas on how we could implement this in a smart way?10:57
*** GillesM <GillesM!> has quit IRC (Quit: Leaving)10:59
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto11:00
RPjorschulko: could we detect the manifest referencing a branch and make that an error?11:02
guidHi. I have a recipe A that installs a file foo.cert in /usr/local/share/ca-certificates. Now, I've got a recipe B that install a file and I need to inject the foo.cert of the recipe A into my (via sed). I added A as a dependency of B (DEPENDS = "A") but I don't know what task I should use for the injection. Can I do it in the11:05
guiddo_install task? What path can I use to access the foo.crt file from the B recipe?11:05
jorschulkothat wouldn't really be useful, as referencing a branch during the development process ist vital. However, you just gave me an idea. Say, we could detect, if the manifest is referencing a branch, then we could use a timestamp to force a do_fetch. If we do not detect a reference to a branch, we could just return the manifest SRCREV and therefore support offline builds for fixed refspecs. What do you11:05
RPjorschulko: wouldn't you just add the head revision of the branch rather than a timestamp?11:07
jorschulkoah, that's an option? :D11:07
jorschulkothat would cause yocto to run do_fetch every time right?11:08
*** pidge <pidge!~pidge@> has joined #yocto11:08
RPjorschulko: the idea is the configuration is meant to be deterministic so if gitsm is referring to floating stuff, the configuration should either be pinning it down or explictly floating11:08
RPjorschulko: i.e. either you set SRCREVS which match the branches, or it is configured to be floating. You'd not want to run do_fetch unless it changes, which you'd see if the branch revision changes11:09
martin31821RP: I'm working with jorschulko on that and want to add my thoughts. Basically, the repo fetcher takes the src URL of the git repository where the XML manifest for google repo lives. That manifest can reference branches, tags or specific revisions for every sub-git-repository. When having something like branch=master specified for the11:21
martin31821main-repository, we would then need to do an lsremote, resolve the revision, inspect the XML at that revision and for each referenced repository do an lsremote again to do it correctly. then we could return a revision key that contains *all* git hashes of all referenced repositories.11:21
martin31821the border between pinned down SRCREVS and floating is very unclear in google repo, since the branches are so decoupled11:22
RPmartin31821: right, I think you will have to do something like that11:22
RPmartin31821: the fetcher does have  the concept of multiple revisions against a git repository so you may be able to use that here too. The hard part is creating a sensible user facing revision but as you say, you could create a hash of the values for that11:23
martin31821RP: in your thoughts, what would be the best option for offline builds, e.g. having a specific SRCREV or tag set for the main-repository? I still would somehow need to enforce that the XML manifest is completely pinned down in order to enforce reprodcability11:24
RPmartin31821: I'm thinking that you'd want multiple SRCREV values set as you'd do with a git repo where you use multiple branches11:24
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Ping timeout: 252 seconds)11:24
RPThat way it would be totally pinned down and reproducible11:25
martin31821one for each referenced repository in the xml manifest?11:25
RPmartin31821: each one that can change11:25
RPmartin31821: so I guess each "unpinned" repository in the xml manifest11:25
martin31821that makes sense, although is kinda hard to implement11:26
RPmartin31821: I didn't say it would be easy! :)11:27
RPI'm not sure I see another way though11:27
jorschulkoAnother issue remains when combining google repo with git submodules. Or is it possible to get the revision of submodules during a lsremote?11:27
RPjorschulko: I'm afraid I don't know11:28
jorschulkook, stike the submodule question. Changing the submodule revision would change the main repo revision as well. so no issue here :)11:29
RPjordemort: submodules have their own issues with ensuring all the submodules are in the fetcher cache11:30
RPjordemort: the fetcher does know how to handle that but that in itself isn't simple11:30
jorschulkoRP: could you kindly point us to an example for the multiple SRCREVS part?11:31
jaskij[m]Something that always bugged me: why does Google repo exist? What is wrong with making a git repo and pulling layers as submodules?11:32
tlwoernerqschulz: the strange thing is, we already were carrying a patch to add those aliases, specifically for the rk3328-based devices11:32
tlwoernerqschulz: and it was on my rk3328-based device (rock64) that i noticed the problem11:33
RPjorschulko: SRC_URI = "git://;name=machine;branch=${KBRANCH}; \11:33
RP           git://;type=kmeta;name=meta;branch=yocto-5.10;destsuffix=${KMETA}" from meta/recipes-kernel/linux/linux-yocto_5.10.bb11:33
RPjorschulko: there is a bbclass which sets SRCREV_FORMAT too11:33
RPjorschulko: the kernel did used to use one url for two different branches11:34
RPjorschulko: if you go back in history you should find that version which is still supported by the fetcher too11:34
*** meego <meego!~meego@2001:41d0:fe7e:c800:102d:4773:7c5b:de6b> has quit IRC (Remote host closed the connection)11:35
tlwoernerqschulz: the patch we have and the patch you link to are different, but simply booting up the board x times in a row would still show the devices enumerate in different orders on each boot11:35
*** meego <meego!~meego@2001:41d0:fe7e:c800:9834:b7ba:fdd9:6da0> has joined #yocto11:35
*** arlen <arlen!> has joined #yocto11:37
*** xmn <xmn!> has quit IRC (Quit: xmn)11:45
*** xmn <xmn!> has joined #yocto11:47
jorschulko@jaskij[m]: In our case we want to be able to easily combine some couple dozen repositories in various versions. Also, changes within one of the repos during development might require changes in multiple other repos. In repo this can easily be done by starting a topic, using submodules the developer (AFAIK) would have to separately clone these submodule repos in order to make changes and then update11:51
jorschulkoeach of the affected refspecs in the main repo. So it is just a matter of management overhead11:51
*** xmn <xmn!> has quit IRC (Ping timeout: 264 seconds)11:57
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto12:00
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 268 seconds)12:02
*** camus <camus!~Instantbi@> has joined #yocto12:02
*** martin31821 <martin31821!> has quit IRC (Ping timeout: 265 seconds)12:13
*** camus1 <camus1!~Instantbi@> has joined #yocto12:15
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)12:17
*** camus1 is now known as camus12:17
jorschulkoRP: thanks for your input, it helped a lot! :)12:26
qschulztlwoerner: probing order isn't deterministic so it's not a surprise that without it sometimes does not work as expected. But the fact that there are (supposedly, need to be checked at runtime) aliases defined for it and it's still non-deterministic is an issue12:30
qschulzand I'm surprised this is happening with the patch you sent12:30
jaskij[m]<jorschulko> "@jaskij[m]: In our case we..." <- That's not true. By default submodules check out as detached head, that's true, but you can then manually check out the submodule you're working on to a branch, work on it and push normally. When done you just add and commit the refspec change in parent repo.12:33
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto12:41
jaskij[m]But I didn't ask it to disagree with you. I just have this nagging feeling I'm missing something by using submodules instead of repo. Because if one solution is vastly more popular there must be reasons. But I have yet to find that reason, except submodules being widely misunderstood and misused. And having clunky UX.12:42
*** meego_ <meego_!~meego@2001:41d0:fe7e:c800:317e:1cab:f4e0:4cbd> has joined #yocto12:44
*** meego <meego!~meego@2001:41d0:fe7e:c800:9834:b7ba:fdd9:6da0> has quit IRC (Ping timeout: 246 seconds)12:48
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)12:48
*** tnovotny <tnovotny!> has joined #yocto12:48
tlwoernerqschulz: do you have rockchip boards to test?12:49
tlwoernerincidentally i'm also seeing the same issue on my dragonboard-410c, hence why i poked ndec_ about editing the kernel cmdline12:50
tlwoernerthe tricky thing is, you can boot the same image 5 times in a row and it'll work so you think the problem is solved, but then the 6th boot shows the problem12:51
ndec_which problem?12:51
tlwoernerhilariously, i was trying to bisect the kernel to figure out the bad commit and ended up landing on a patch that did nothing but fix a spelling mistake!!! hahah12:51
tlwoerneri almost lost faith in my ability to git bisect (lol)12:52
zeddiiRP: I if wanted to see if there were those pkg-config inherit issues in meta-virt.  Is building against poky master-next enough ? or did you turf some fo the proposed patches ?12:52
RPzeddii: the patch in question is still in master-next12:53
tlwoernerndec_: the 5.13 kernel doesn't probe mmc devices in a deterministic way, so if you hardcode your image to boot, say, mmcblk1 then it'll only boot successfully roughly half the time12:53
zeddiiack'd. I'll have a test spin just to see then!12:53
RPzeddii: I am unlikely to take it for 3.4 as it does cause too many complaints. I merged the other do_build dependency changes though12:53
ndec_tlwoerner: was it ever done in a deterministic way?12:53
tlwoernerndec_: in meta-rockchip i had to switch to using UUIDs (but apparently some are seeing issues with my recent patch)12:54
zeddiiRP: gotcha. I'll just see if I can get ahead of it eventually landing and already have the layer in shape, if it needs anything that is.12:54
ndec_i thought we had been using PARTLABEL for quite some time.12:54
RPzeddii: I thought we cleaned things up a while ago but looks like things regressed :/12:54
zeddiiindeed. I remember doing a bunch of changes adding inherit pkgconfig .. so I don't expect much. Just looking at the stream of changes in meta-oe, made me wonder.12:55
RPzeddii: I ran a build with the kernel uprev last night and it seemed fine. I have another running now with Kevin's change12:55
RPzeddii: if those pass, are we good?12:55
ndec_tlwoerner: hmm. no we stopped using hardcoded block device in our debian builds.. not in meta-qcom. but i think we should.12:55
RPzeddii: the changes in core surprised me too :/12:56
tlwoernerndec_: yes12:56
tlwoernerconf/machine/dragonboard-410c.conf:SD_QCOM_BOOTIMG_ROOTFS ?= "/dev/mmcblk1p7"12:56
zeddiiRP: yup. that's all we'd need. and I can follow up and purge, or you could during the merge. whatever is easiest.12:56
tlwoernerndec_: but then i got lost in recipes-kernel/linux/linux-qcom-bootimg.inc12:56
RPzeddii: I'll let you followup :)12:57
jorschulkojaskij[m] huh... cool I didn't know that you could checkout within the submodule. However, you would still have to manually step into each of the submodules, create a branch, make your changes and push them. With repo you can e.g. create / push branches on all desired repos with one command12:57
ndec_tlwoerner: change QCOM_BOOTIMG_ROOTFS12:57
tlwoernerndec_: using a UUID requires the removal of the "root=" kernel cmdline arg, hence my question earlier12:57
tlwoernerndec_: oops, not the removal of root=, but modifying it to use UUID too12:58
tlwoernerhmm, not sure that's going to work on the dragonboard-410c12:58
ndec_i don't think you can use UUID, since you don't know the value, no?12:59
*** arlen <arlen!> has quit IRC (Remote host closed the connection)12:59
ndec_i was thinking about root=PARTLABEL=rootfs12:59
tlwoernerndec_: i've switched to booting off the uSD card on my dragonboard-410c, it avoids all that messy android stuff ;-)12:59
jorschulkojaskij[m]: e.g.: repo start feature/foo $(repo list -n -r "<SOME_REGEX_TO_IDENTIFY_BRANCHES>")12:59
tlwoernerndec_: ah yes! let me try that13:00
ndec_tlwoerner: well, 'rootfs' here is the partition name. so you need to make sure you don't have the same name on emmc and sd, otherwise it won't work well :)13:01
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)13:03
tlwoernerndec_: i don't think any of the android partitions (i.e. on the emmc) have that name (fingers crossed)13:11
jaskij[m]<jorschulko> "jaskij huh... cool I didn't know..." <- Huh, okay, yes, that can be useful if you're working on multiple layers at once.13:14
qschulztlwoerner: I have some rk3399-puma-haiku available13:18
*** linkliu61 <linkliu61!~user_name@> has joined #yocto13:19
qschulztlwoerner: do you have mmc0/mmc1 entries in /sys/firmware/devicetree/base/aliases/ directory?13:19
tlwoernera bb.error() in an anonymous python doesn't seem to stop the build?13:28
tlwoernerthe message does get printed, and the build returns failure, eventually, but subsequent tasks keep running13:29
tlwoernerqschulz: (i'm investigating, i'll do a clean build for my rock64 with my patch removed and just the alias patch, the build will take a bit)13:33
qschulztlwoerner: you want bb.fatal maybe?13:39
RPtlwoerner: you want bb.fatal() to stop the build13:40
tlwoernerqschulz: RP: ahh, thanks! :-)13:40
*** frieder <frieder!> has quit IRC (Ping timeout: 252 seconds)13:45
*** frieder <frieder!> has joined #yocto13:47
*** camus1 <camus1!~Instantbi@> has joined #yocto13:58
*** meego <meego!~meego@2001:41d0:fe7e:c800:102d:4773:7c5b:de6b> has joined #yocto13:59
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 265 seconds)14:00
*** camus1 is now known as camus14:00
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto14:00
*** meego_ <meego_!~meego@2001:41d0:fe7e:c800:317e:1cab:f4e0:4cbd> has quit IRC (Ping timeout: 252 seconds)14:02
*** rob_w <rob_w!> has quit IRC (Quit: Leaving)14:04
tlwoernerqschulz: sweet! the rk3399-puma-haikou has upstream support, i'll expect a patch adding it to meta-rockchip? ;-)14:05
*** otavio_ <otavio_!> has joined #yocto14:08
*** otavio <otavio!> has quit IRC (Read error: Connection reset by peer)14:08
moto-timokanavin: I've got it building and properly setting the PIN to get past the login screen, but it immediately fails after that and I haven't gotten back to diagnosing why... looks like gsettings-daemon issue14:09
ThomasD13Hmmm.. qschulz your suggestion with MACHINEOVERRIDES worked well, apart for that: SYSFW_PREFIX_j7-evm-k3r5 = "ti-fs-firmware"14:10
*** Sion <Sion!> has quit IRC (Ping timeout: 264 seconds)14:10
kanavinmoto-timo, right, hope you find time to push it further14:10
ThomasD13j7-evm has multiconfig "k3r5"14:10
moto-timokanavin: probably tomorrow14:10
qschulzThomasD13: j7-evm-k3r5 is an OVERRIDES, so you need another one in MACHINEOVERRIDES14:11
ThomasD13My added machine-config "j7-paradise" with the MACHINEOVERRIDES = "j7-evm" seems not to pickup on that14:11
qschulzmight make sense to have it in the multiconfig file but I know very little about multiconfig unfortunately :/14:11
*** vd <vd!> has joined #yocto14:12
ThomasD13Yeah, my guess is that this multiconfig crap is kind of a "special case"14:12
qschulzThomasD13: that's TI crap :) I don't think it has anything to do with "usual"/Yocto multiconfig setup?14:12
ThomasD13yeah sorry, thats probably more true :)14:13
ThomasD13So I have a machine configuration, and can work there with MACHINEOVERRIDES14:13
*** arlen <arlen!> has joined #yocto14:13
ThomasD13that makes sense to me - and this machine configuration is used for a second "config" (k3r5)14:14
*** sakoman <sakoman!> has joined #yocto14:14
qschulzThomasD13: dig into TI configuration file and you'll see they are adding this to MACHINEOVERRIDES somehwere (probably  a ${MACHINE}-k3r5 or something similar?)14:14
*** guid <guid!> has quit IRC (Quit: Client closed)14:15
ThomasD13But why worked the MACHINEOVERRIDES not in that case?14:15
qschulzmight be using the name of the other machine in the multiconfig setup but I don't know14:15
qschulzThomasD13: because OVERRIDES works on full strings14:15
vdwhat is the best way to provide a .nspawn configuration file? its own package, systemd-conf, or systemd-container?14:15
qschulzso _j7-evm is matched by j7-evm only, _j7-evm-k3r5 won't match unless you have j7-evm-k3r5 in OVERRIDES somewhere14:15
ThomasD13ahhhhh alright. I thought yocto does know about j7-evm is machine of that string. Ok, makes sense now :)14:16
ThomasD13thank you14:16
qschulztlwoerner: that would be possible indeed. Have to figure out how the defconfigs are working on arm64 upstream. I only remember there's a default defconfig and we usually have our own next to that one for our machines14:19
ThomasD13They have a multiconfig "k3r5.conf" with this: MACHINE_append = "-k3r5". Does this make the trick?14:19
qschulzThomasD13: oof14:19
*** meego <meego!~meego@2001:41d0:fe7e:c800:102d:4773:7c5b:de6b> has quit IRC (Remote host closed the connection)14:20
tlwoernerqschulz: i'm working on a "best practices" config for rockchip, i've noticed things missing from the defconfig that hurt rockchip14:20
tlwoerneri.e. working with the linux-yocto tooling from zeddii :-)14:20
qschulztlwoerner: the concern now is where the defconfigs mentioned in the machine config file are :D14:21
*** meego <meego!~meego@2001:41d0:fe7e:c800:6990:1a84:c62:e0b3> has joined #yocto14:21
qschulzThomasD13: so, basically the issue right now is that they are renaming the machine completely14:21
qschulzso... j7-evm never exists anymore14:22
qschulzin the context of a multiconf build obviously14:22
tlwoernerbtw, Amit Kucheria is currently giving a talk discussing "yocto" @ plumbers14:22
qschulzso your MACHINEOVERRIDES is technically incorrect if we follow tht "logic"14:22
rburtontlwoerner: is that the huawai allscenario one?14:22
ThomasD13lol - okay. That sounds like a bad practise14:23
tlwoernerrburton: it's a zephyr talk14:23
tlwoerneri think should work14:23
qschulzThomasD13: if this does not break (it'll silently break/misconfigure/enable/disable stuff) your builds, then a simple MACHINEOVERRIDES .= ":j7-evm-k3r5" in your multiconf file might be enough14:24
moto-timoInteresting talk so far… the slides are sparse14:24
moto-timoSo video watching will be required14:25
ThomasD13qschulz, got it. I give it a try. thank you so much. I even have a testcase for this :)14:25
*** meego_ <meego_!~meego@2001:41d0:fe7e:c800:102d:4773:7c5b:de6b> has joined #yocto14:26
*** fbre <fbre!~fbre@> has quit IRC (Quit: Client closed)14:27
*** meego <meego!~meego@2001:41d0:fe7e:c800:6990:1a84:c62:e0b3> has quit IRC (Ping timeout: 268 seconds)14:30
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:c33d:f91c:b909:a4d5> has joined #yocto14:32
*** meego_ <meego_!~meego@2001:41d0:fe7e:c800:102d:4773:7c5b:de6b> has quit IRC (Ping timeout: 268 seconds)14:32
tlwoernerkarim expresses an odd sentiment14:35
*** meego <meego!~meego@2001:41d0:fe7e:c800:a09f:f3c8:fdbf:c730> has joined #yocto14:38
*** pidge <pidge!~pidge@> has quit IRC (Quit: Client closed)14:40
*** pidge <pidge!~pidge@> has joined #yocto14:40
*** kayterina <kayterina!> has quit IRC (Remote host closed the connection)14:41
JosefHolzmayr[m]does nodejs on master really compile for 1h+x on a mid-size box? (like, 16cores)14:50
*** jorschulko <jorschulko!> has quit IRC (Quit: leaving)14:51
*** meego_ <meego_!~meego@2001:41d0:fe7e:c800:8199:9a92:fc48:b59a> has joined #yocto14:56
*** meego <meego!~meego@2001:41d0:fe7e:c800:a09f:f3c8:fdbf:c730> has quit IRC (Ping timeout: 268 seconds)15:00
*** vd <vd!> has quit IRC (Quit: Client closed)15:03
*** vd <vd!> has joined #yocto15:04
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)15:10
*** frieder <frieder!> has quit IRC (Remote host closed the connection)15:20
Tartarusmoto-timo: Hey, smurray said perhaps I should poke you about poking some of the crops folks to update the containers, lz4c, pzstd and zstd are missing from cropy/poky:ubuntu-20.04 (and all the rest I assume) which master requires now15:21
moto_timo[m]Tartarus: right... rewitt has been maintaining things on a best-effort basis15:22
rburtonmoto_timo[m]: maybe he needs to open up the repo to a co-maintainer15:23
rburtonmaybe called Tim15:23
moto_timo[m]rburton: I have write privileges, but I have been respecting his final word15:24
rburtonyou could be a co-maintainer so you can push the aarch64 image15:24
rburtonbecause right now, i'm telling people who want arm build containers to use the kas container15:24
TartarusI mean, is crops open to pull requests?  I should update my build system to something a tiny bit less old, but I've also found just firing off crops and building in that fairly handy15:24
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)15:25
moto-timoTartarus: crops is open to pull requests. the place to put the change is in yocto-dockerfiles15:26
Tartarusmoto-timo: OK, yeah, thanks.  I'll do a PR if things don't get updated by the time I'm needing to poke this again. :)15:26
moto-timomost of my daily usage is now kas based, so I haven't been using crops as much recently15:27
*** whuang0389 <whuang0389!> has joined #yocto15:27
whuang0389Is there a way to unmask a service in a recipe??15:28
whuang0389(I want it unmasked, but not enabled)15:28
*** ThomasD13 <ThomasD13!> has quit IRC (Ping timeout: 264 seconds)15:29
*** dev1990 <dev1990!~dev@> has joined #yocto15:45
*** pidge <pidge!~pidge@> has quit IRC (Quit: Client closed)15:57
*** camus1 <camus1!~Instantbi@> has joined #yocto15:58
*** camus <camus!~Instantbi@> has quit IRC (Remote host closed the connection)15:59
*** camus1 is now known as camus15:59
*** DanielWalls[m] <DanielWalls[m]!~dwallsmat@2001:470:69fc:105::ff37> has quit IRC (Remote host closed the connection)16:02
*** hereiam[m] <hereiam[m]!~nsdrudema@2001:470:69fc:105::f855> has quit IRC (Remote host closed the connection)16:02
*** olani[m] <olani[m]!~olanimatr@2001:470:69fc:105::c93> has quit IRC (Remote host closed the connection)16:02
*** hpsy[m] <hpsy[m]!~hpsymatri@2001:470:69fc:105::f822> has quit IRC (Remote host closed the connection)16:02
*** michaelo[m] <michaelo[m]!~michael-o@2001:470:69fc:105::be7c> has quit IRC (Read error: Connection reset by peer)16:02
*** barath <barath!~barath@2001:470:69fc:105::21a> has quit IRC (Read error: Connection reset by peer)16:02
*** Alban[m] <Alban[m]!~albeugaen@2001:470:69fc:105::34b4> has quit IRC (Remote host closed the connection)16:02
*** k4wsys[m] <k4wsys[m]!~k4wsysmat@2001:470:69fc:105::e339> has quit IRC (Read error: Connection reset by peer)16:02
*** behanw[m] <behanw[m]!~behanwmat@2001:470:69fc:105::c96> has quit IRC (Remote host closed the connection)16:02
*** cryptollision[m] <cryptollision[m]!~cryptolli@2001:470:69fc:105::f778> has quit IRC (Read error: Connection reset by peer)16:02
*** Pierre-jeanTexie <Pierre-jeanTexie!~pjtexierm@2001:470:69fc:105::f2f> has quit IRC (Remote host closed the connection)16:02
*** jordemort <jordemort!~jordemort@2001:470:69fc:105::2d9> has quit IRC (Read error: Connection reset by peer)16:02
*** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has quit IRC (Read error: Connection reset by peer)16:02
*** meck[m] <meck[m]!~meckmeckd@2001:470:69fc:105::3a51> has quit IRC (Write error: Connection reset by peer)16:02
*** ezzuldin[m] <ezzuldin[m]!~ezzuldinm@2001:470:69fc:105::f386> has quit IRC (Remote host closed the connection)16:02
*** moto_timo[m] <moto_timo[m]!~mototimom@2001:470:69fc:105::c94> has quit IRC (Write error: Connection reset by peer)16:02
*** berton[m] <berton[m]!~fabiobert@2001:470:69fc:105::ce36> has quit IRC (Read error: Connection reset by peer)16:02
*** janvermaete[m] <janvermaete[m]!~vermaetem@2001:470:69fc:105::ee7> has quit IRC (Remote host closed the connection)16:02
*** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has quit IRC (Read error: Connection reset by peer)16:02
*** JosefHolzmayr[m] <JosefHolzmayr[m]!~theyoctoj@2001:470:69fc:105::e785> has quit IRC (Remote host closed the connection)16:02
*** PascalBach[m] <PascalBach[m]!~bachpmatr@2001:470:69fc:105::1d3b> has quit IRC (Remote host closed the connection)16:02
*** kranzo[m] <kranzo[m]!~kranzomat@2001:470:69fc:105::dd3e> has quit IRC (Remote host closed the connection)16:02
*** ejoerns[m] <ejoerns[m]!~ejoernsma@2001:470:69fc:105::252> has quit IRC (Remote host closed the connection)16:02
*** jaskij[m] <jaskij[m]!~jaskijmat@2001:470:69fc:105::fa76> has quit IRC (Remote host closed the connection)16:02
*** xicopitz[m] <xicopitz[m]!~xicopitzm@2001:470:69fc:105::4869> has quit IRC (Remote host closed the connection)16:02
*** kayterina[m] <kayterina[m]!~kayterina@2001:470:69fc:105::960> has quit IRC (Write error: Broken pipe)16:02
*** jwillikers[m] <jwillikers[m]!~jwilliker@2001:470:69fc:105::626a> has quit IRC (Write error: Connection reset by peer)16:02
*** Spectrejan[m] <Spectrejan[m]!~spectreja@2001:470:69fc:105::1609> has quit IRC (Remote host closed the connection)16:02
*** WadeBerrier[m] <WadeBerrier[m]!~wberrierm@2001:470:69fc:105::3f0e> has quit IRC (Remote host closed the connection)16:02
*** ramprakash[m] <ramprakash[m]!~ramprakas@2001:470:69fc:105::fbfe> has quit IRC (Remote host closed the connection)16:02
*** CarlesFernandez[ <CarlesFernandez[!~cfernande@2001:470:69fc:105::e590> has quit IRC (Remote host closed the connection)16:02
*** t_unix[m] <t_unix[m]!~tunixmatr@2001:470:69fc:105::9ea> has quit IRC (Write error: Connection reset by peer)16:02
*** scjg <scjg!~scjgmatri@2001:470:69fc:105::f5d6> has quit IRC (Write error: Connection reset by peer)16:02
*** coldspark29[m] <coldspark29[m]!~coldspar_@2001:470:69fc:105::db09> has quit IRC (Write error: Broken pipe)16:02
*** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has quit IRC (Write error: Connection reset by peer)16:02
*** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has quit IRC (Write error: Connection reset by peer)16:02
*** twinning[m] <twinning[m]!~twinningm@2001:470:69fc:105::e5db> has quit IRC (Remote host closed the connection)16:02
*** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has quit IRC (Remote host closed the connection)16:02
*** agherzan <agherzan!~agherzan@2001:470:69fc:105::e1fe> has quit IRC (Remote host closed the connection)16:02
*** fabatera[m] <fabatera[m]!~fabateram@2001:470:69fc:105::18d5> has quit IRC (Remote host closed the connection)16:02
*** mahu[m] <mahu[m]!~markus5hm@2001:470:69fc:105::ed4f> has quit IRC (Remote host closed the connection)16:02
*** SalamaSalama[m] <SalamaSalama[m]!~moustafa5@2001:470:69fc:105::e6c4> has quit IRC (Write error: Connection reset by peer)16:02
*** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has quit IRC (Write error: Connection reset by peer)16:02
*** Jari[m] <Jari[m]!~jarihmatr@2001:470:69fc:105::6a7> has quit IRC (Remote host closed the connection)16:02
*** khem <khem!~khemmatri@2001:470:69fc:105::b81> has quit IRC (Read error: Connection reset by peer)16:02
kanavinalimon, are you aware of ptest-runner patches floating about?16:02
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:c33d:f91c:b909:a4d5> has quit IRC (Ping timeout: 260 seconds)16:02
*** zpfvo <zpfvo!~fvo@> has quit IRC (Read error: Connection reset by peer)16:02
*** jordemort <jordemort!~jordemort@2001:470:69fc:105::2d9> has joined #yocto16:03
*** WadeBerrier[m] <WadeBerrier[m]!~wberrierm@2001:470:69fc:105::3f0e> has joined #yocto16:03
alimonkanavin: not yet, i will review it, thanks for notice me,  these days i'm returning from OOO16:05
*** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has joined #yocto16:05
*** scjg <scjg!~scjgmatri@2001:470:69fc:105::f5d6> has joined #yocto16:05
*** Alban[m] <Alban[m]!~albeugaen@2001:470:69fc:105::34b4> has joined #yocto16:05
*** Spectrejan[m] <Spectrejan[m]!~spectreja@2001:470:69fc:105::1609> has joined #yocto16:05
*** kayterina[m] <kayterina[m]!~kayterina@2001:470:69fc:105::960> has joined #yocto16:05
*** meck[m] <meck[m]!~meckmeckd@2001:470:69fc:105::3a51> has joined #yocto16:05
*** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has joined #yocto16:05
*** khem <khem!~khemmatri@2001:470:69fc:105::b81> has joined #yocto16:05
*** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #yocto16:05
kanavinalimon, thanks. Hope you're ok.16:06
*** Pierre-jeanTexie <Pierre-jeanTexie!~pjtexierm@2001:470:69fc:105::f2f> has joined #yocto16:06
*** ejoerns[m] <ejoerns[m]!~ejoernsma@2001:470:69fc:105::252> has joined #yocto16:06
*** moto_timo[m] <moto_timo[m]!~mototimom@2001:470:69fc:105::c94> has joined #yocto16:06
*** t_unix[m] <t_unix[m]!~tunixmatr@2001:470:69fc:105::9ea> has joined #yocto16:06
*** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has joined #yocto16:06
*** PascalBach[m] <PascalBach[m]!~bachpmatr@2001:470:69fc:105::1d3b> has joined #yocto16:06
*** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has joined #yocto16:07
alimonkanavin: i'm fine thanks, regarding the patch that counts the errors so we should return 0 when success and 1 when fails without count. the proposed patch didn't return 0 when succeed.16:07
*** CarlesFernandez[ <CarlesFernandez[!~cfernande@2001:470:69fc:105::e590> has joined #yocto16:07
*** k4wsys[m] <k4wsys[m]!~k4wsysmat@2001:470:69fc:105::e339> has joined #yocto16:07
*** coldspark29[m] <coldspark29[m]!~coldspar_@2001:470:69fc:105::db09> has joined #yocto16:07
*** barath <barath!~barath@2001:470:69fc:105::21a> has joined #yocto16:07
*** jwillikers[m] <jwillikers[m]!~jwilliker@2001:470:69fc:105::626a> has joined #yocto16:07
*** behanw[m] <behanw[m]!~behanwmat@2001:470:69fc:105::c96> has joined #yocto16:07
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:559b:2a4f:33fa:f8c9> has joined #yocto16:08
*** Nate[m]1 <Nate[m]1!~nsdrudema@2001:470:69fc:105::f855> has joined #yocto16:08
*** twinning[m] <twinning[m]!~twinningm@2001:470:69fc:105::e5db> has joined #yocto16:08
*** DanielWalls[m] <DanielWalls[m]!~dwallsmat@2001:470:69fc:105::ff37> has joined #yocto16:08
*** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has joined #yocto16:08
*** Jari[m] <Jari[m]!~jarihmatr@2001:470:69fc:105::6a7> has joined #yocto16:08
*** kranzo[m] <kranzo[m]!~kranzomat@2001:470:69fc:105::dd3e> has joined #yocto16:08
*** fabatera[m] <fabatera[m]!~fabateram@2001:470:69fc:105::18d5> has joined #yocto16:08
*** agherzan <agherzan!~agherzan@2001:470:69fc:105::e1fe> has joined #yocto16:09
*** ezzuldin[m] <ezzuldin[m]!~ezzuldinm@2001:470:69fc:105::f386> has joined #yocto16:09
*** JosefHolzmayrThe <JosefHolzmayrThe!~theyoctoj@2001:470:69fc:105::e785> has joined #yocto16:09
alimonkanavin: i see there is a new patch16:09
*** xicopitz[m] <xicopitz[m]!~xicopitzm@2001:470:69fc:105::4869> has joined #yocto16:09
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)16:09
*** ramprakash[m] <ramprakash[m]!~ramprakas@2001:470:69fc:105::fbfe> has joined #yocto16:09
*** janvermaete[m] <janvermaete[m]!~vermaetem@2001:470:69fc:105::ee7> has joined #yocto16:10
*** Markus[m]1 <Markus[m]1!~markus5hm@2001:470:69fc:105::ed4f> has joined #yocto16:10
*** cryptollision[m] <cryptollision[m]!~cryptolli@2001:470:69fc:105::f778> has joined #yocto16:10
*** olani[m] <olani[m]!~olanimatr@2001:470:69fc:105::c93> has joined #yocto16:10
*** SalamaSalama[m] <SalamaSalama[m]!~moustafa5@2001:470:69fc:105::e6c4> has joined #yocto16:10
*** camus <camus!~Instantbi@> has joined #yocto16:10
*** michaelo[m] <michaelo[m]!~michael-o@2001:470:69fc:105::be7c> has joined #yocto16:11
*** berton[m] <berton[m]!~fabiobert@2001:470:69fc:105::ce36> has joined #yocto16:11
*** whuang0389 <whuang0389!> has quit IRC (Quit: Client closed)16:11
*** jaskij[m] <jaskij[m]!~jaskijmat@2001:470:69fc:105::fa76> has joined #yocto16:11
*** hpsy[m] <hpsy[m]!~hpsymatri@2001:470:69fc:105::f822> has joined #yocto16:11
kanavinalimon, yes, and some patches from me16:12
*** argonautx <argonautx!> has quit IRC (Ping timeout: 252 seconds)16:16
alimonkanavin: yes i find this one, [ptest-runner][PATCH 3/3] utils.c: add system data collection when a test gets stuck16:21
alimonkanavin: do you have a repo/branch for this patches, for some reason git am is failing to apply16:21
tlwoernerqschulz: so a completely fresh/clean build of 5.13.y doesn't find the sdcard even with the patch i pointed you to earlier that explicitly sets mmcblk1 to the sdmmc (in the DT)16:23
tlwoernerand i can't verify what's in /sys/firmware/… because it doesn't get to a prompt ;-)16:23
alimonkanavin: is unable to build an ancestor, i'm using git version 2.33.016:24
qschulztlwoerner: or use dtc -I dtb -O dts on the output dtb16:27
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)16:32
alimonkanavin: thx16:34
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto16:35
alimonkanavin: did you see that issue before with git am?, i wonder if is because of the version, i'm running debian sid16:35
alimongit version*16:35
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:559b:2a4f:33fa:f8c9> has quit IRC (Ping timeout: 250 seconds)16:35
kanavinalimon, I really don't know, I used standard git send-email with debian testing16:35
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:39
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)16:39
moto-timokanavin: JPEW: actually phoc might be unhappy because the virtual keyboard (squeakboard) isn't present... that's the "Fatal server error:" "(EE) Failed to activate virtual core keyboard"16:45
moto-timokanavin: JPEW: squeakboard requires Rust... hacking at the recipe now16:46
*** prabhakarlad <prabhakarlad!> has joined #yocto16:52
kanavinmoto-timo, I tried to play with phosh on latest fedora and it didn't go far, crashes on startup16:56
moto-timokanavin: :(16:57
kanavinand squeakboard is fairly obtrusive, it pops up on screen every time an input widget gets focus - even when there is no touchscreen, and there is a physical keyboard16:57
kanavinbut fedora carries fairly outdated versions16:57
moto-timokanavin: ah, good to know. phosh is certainly targeting a phone/handset user experience. so it might need hacking to be a generic tablet/kiosk interface16:58
kanavinmoto-timo, we certainly don't want squeakboard to take half the window in qemu16:59
moto-timokanavin: absolutely not!16:59
* moto-timo stops working on squeekboard recipe16:59
moto-timoIt would be ok if it had a "keyboard" icon on screen that you could hit to bring up the virtual keyboard, but if it automatically shows up just because there is a user input... nope17:00
*** argonautx <argonautx!> has joined #yocto17:00
kanavinmoto-timo, again, this is what is in fedora, it may work better with latest code17:01
moto-timoI'm starting to wonder if rburton's idea to port matchbox might be better ... sigh17:01
moto-timokanavin: ok. I'll keep poking at it17:01
kanavinmoto-timo, yes please17:02
moto-timokanavin: also, we haven't tried interacting with upstream yet, so who knows what is possible17:02
*** vd <vd!> has quit IRC (Quit: Client closed)17:10
*** argonautx <argonautx!> has quit IRC (Ping timeout: 252 seconds)17:11
ad__on gatesgarth, seems there is not way i can generate a zImage (tried KERNEL_IMAGETYPE = "zImage")17:14
ad__i always find a Image as output17:14
*** vd <vd!> has joined #yocto17:18
ad__oooh, ok, cannot have zImage for imx8mp17:18
*** whuang0389 <whuang0389!> has joined #yocto17:25
*** sethfoster <sethfoster!~sethfoste@> has joined #yocto17:26
sethfosterHey folks. I have a kconfig fragment that I've added to a .bbappend for my (bsp's) kernel recipe via SRC_URI that appears to get loaded - it's in the work dir for the kernel - but not actually applied to .config. Does anybody know why that might happen?17:28
sethfosterDo kconfig fragments _have_ to be in a directory named ${PN}? i have mine in one just called "defconfigs" (to differentiate from another with dtree fragments)17:29
TartarusIs there a packagegroup for "I want to build the kernel, on device" today?17:31
*** FredO2 <FredO2!> has joined #yocto17:34
*** FredO <FredO!> has quit IRC (Ping timeout: 252 seconds)17:35
vdWhen is planned Honister?17:42
tlwoernerTartarus: adding "tools-sdk" to EXTRA_IMAGE_FEATURES will add gcc, make, pkgconfig etc to your image17:50
Tartarustlwoerner: Yes, that's missing several packages for 5.14.x and arm64 defconfig17:50
TartarusI knew to add bison/flex before firing this off, and bc was easy enough to manually whack in.  Rebuilding for perl stuff17:50
*** meego_ <meego_!~meego@2001:41d0:fe7e:c800:8199:9a92:fc48:b59a> has quit IRC (Ping timeout: 246 seconds)17:51
*** florian <florian!> has joined #yocto17:53
*** whuang0389 <whuang0389!> has quit IRC (Quit: Ping timeout (120 seconds))17:59
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:94d3:f4ee:3a34:4211> has joined #yocto18:03
*** vd <vd!> has quit IRC (Quit: Client closed)18:09
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)18:09
alimonkanavin: just pushed your changes, i think is ready to bump to v2.4.218:17
kanavinalimon, thanks! we've been seeing lttng-ptest lockups and this would help figure out where and what18:18
*** vd <vd!> has joined #yocto18:23
vdRP: do depends and mcdepends really need to be separated? supporting both forces us to duplicate lot of code to determine if the dependency is from a multiconfig or from BB_CURRENT_MC18:25
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)18:59
*** camus <camus!~Instantbi@> has joined #yocto18:59
*** argonautx <argonautx!> has joined #yocto19:02
*** prabhakarlad <prabhakarlad!> has joined #yocto19:14
abellonikanavin: should I try your librsvg update ? ;)19:20
*** roussinm <roussinm!> has joined #yocto19:29
*** florian <florian!> has quit IRC (Ping timeout: 252 seconds)19:31
*** sethfoster <sethfoster!~sethfoste@> has quit IRC (Ping timeout: 265 seconds)19:33
*** vd <vd!> has quit IRC (Quit: Client closed)19:34
*** vd <vd!> has joined #yocto19:34
vdDo we agree that do_thistask[depends] += "foobar:thattask" is equivalent to do_thistask[mcdepends] += "mc:${BB_CURRENT_MC}:${BB_CURRENT_MC}:foobar:thattask" ? Cc: abelloni RP19:39
*** sethfoster <sethfoster!~sethfoste@> has joined #yocto19:40
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)19:50
*** prabhakarlad <prabhakarlad!> has joined #yocto19:52
sethfosterDoes anybody know why a kconfig snippet file might not apply properly? it seems to be detected but not applied19:54
vdsethfoster: what kernel recipe are you using?19:55
sethfostervendor downstream19:55
sethfosterthey're using KBUILD_DEFCONFIGs it would appear19:56
sethfosteri made a .bbappend for that kernel recipe, which adds a touchscreen-goodix.cfg file containing CONFIG_TOUCHSCREEN_GOODIX=m19:57
sethfosterwhen i build the linux-toradex recipe, the touchscreen-goodix.cfg shows up in WORKDIR, but does not get applied to .config19:57
sethfosteri'm on dunfell and following the guide here:
sethfosterspecifically the "config fragment" approach20:03
*** florian <florian!> has joined #yocto20:04
*** argonautx <argonautx!> has quit IRC (Ping timeout: 252 seconds)20:06
sethfostervd: oh you know what i think i did not properly read the big warning about .config not containing config fragment overrides20:29
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)20:34
*** agners <agners!~ags@2a02:169:3df5:10:5c1d:e28a:f461:57d5> has joined #yocto20:39
*** sethfoster <sethfoster!~sethfoste@> has quit IRC (Quit: leaving)20:42
RPvd: they probably don't have to be separated in hindsight. At the time they were implemented that wasn't very clear20:48
RPand yes, that looks about right to be equivalent20:48
RPmcdepends does mean bitbake can know relatively easily if it is dealing with cross multiconfigs or not20:49
RPthere are other ways to do that but it makes it harder on bitbake20:49
*** whuang0389 <whuang0389!> has joined #yocto20:54
vdRP: OK so one might simply stick with mcdepends (with a fallback to mc:::pn:task) instead of dealing with both. In which case would you use a multiconfig_from different than BB_CURRENT_MC (e.g. mc:NOTCURRENT:foo:bar:baz)?20:54
RPvd: I don't remember, I'd have to go and look at what that code is doing.20:56
whuang0389does anyone know how I can find which recipe is installing the weston.ini file?20:56
* RP doesn't have all this on instant recall :(20:56
RPwhuang0389: I think oe-pkgdata-util can tell you20:57
whuang0389RP thanks so much!20:59
RPvd: When you write an mcdepends in a recipe, you want to be able to say which mc it should apply within20:59
RPso X[mcdepends] += "mc:A:B:C:D" will only apply in the A mc space even if the mcdepends was defined in all the different mcs21:00
vdRP: so building mc:E:pn won't pull in B:C as a dependency for X?21:02
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 264 seconds)21:03
RPvd: that is what I understand21:03
vdso multiconfig_from would act as an implicit condition against BB_CURRENT_MC21:04
RPvd: I think so21:05
vdI'm trying to find a valid usecase for that21:08
RPvd: if you're trying to write flat configuration files, it was necessary iirc21:10
RPpeople expect mutliconfig to be useful and usable in different ways21:10
RPOne of the reasons for putting mcdepends separately was so we could change details like this if we needed to21:11
vdRP: is there a way to know the DEPLOY_DIR_IMAGE path of an mcdepends? or one should guess it? It's tricky if the multiconfig changed TMPDIR for example.21:11
RPvd: there is not a way to know, no21:14
RPit is assumed the multiconfig knows how it sets up the individual configs21:14
RPzeddii, khem: Looks like 5.14 is passing on the autobuilder apart from the meta-oe failure. Not sure what to do now :/21:15
*** xmn <xmn!> has joined #yocto21:29
whuang0389uhm is there a way to bitbake a recipe without clearing work after it's done?21:38
RPwhuang0389: turn off rm_work?21:41
whuang0389RP thanks again haha21:42
RPSaur: I opened your email with some trepidation, glad it helped :)21:43
zeddiiRP: I was cleaning up some -dev loose ends, and was looking at the vbox build here. no fix yet. but will poke at it more later.21:44
RPzeddii: I don't know if we block on that, I do feel bad I've given meta-oe a rough week21:44
RPzeddii: I've not had a chance to look at it. Maybe tomorrow if nobody else beats me to it21:45
zeddiiI'll leave a message here in IRC with whatever I sort out, if I fix it, there will be a patch to meta-oe21:45
* zeddii sees what the kernel changed to break the build21:52
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Ping timeout: 265 seconds)22:00
vdshould I use distro feature "vulkan" or "opengl" to run chromium-ozone-wayland (from meta-browser/meta-chromium) on a beaglebone black?22:20
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)22:25
*** camus1 <camus1!~Instantbi@> has joined #yocto22:25
*** camus1 is now known as camus22:27
smurrayvd: I'd be somewhat surprised if vulkan is supported with the PowerVR stuff for BBB22:32
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:94d3:f4ee:3a34:4211> has quit IRC (Ping timeout: 260 seconds)22:33
*** florian <florian!> has quit IRC (Ping timeout: 260 seconds)22:42
vdsmurray: should I remove vulkan from the distro features then? I'm not sure to understand what the recipe chooses to build with the two specified22:55
smurrayvd: I probably would22:56
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)22:59
*** xmn <xmn!> has quit IRC (Read error: Connection reset by peer)23:17
*** xmn <xmn!> has joined #yocto23:17
vdsmurray: I kept only opengl as a distro feature and restarted the build from scratch. I'm using meta-ti's linux-ti-staging kernel, I hope it'll be enough for a functional chromium.23:27
vdtoo bad there's no reliable web browser for embedded devices, ideally using the framebuffer directly... some exist and work well but are really rudimentary, most websites won't work.23:28
*** ant__ <ant__!> has quit IRC (Ping timeout: 265 seconds)23:36
*** whuang0389 <whuang0389!> has quit IRC (Quit: Client closed)23:39
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)23:47

Generated by 2.17.2 by Marius Gedminas - find it at!