Friday, 2021-12-10

*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 240 seconds)00:02
*** pbergin <pbergin!> has quit IRC (Remote host closed the connection)00:03
*** manuel_ <manuel_!~manuel198@> has joined #yocto00:04
*** pbergin <pbergin!> has joined #yocto00:04
*** florian <florian!> has joined #yocto00:05
*** pbergin <pbergin!> has quit IRC (Remote host closed the connection)00:06
*** pbergin <pbergin!> has joined #yocto00:06
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 250 seconds)00:06
*** pbergin <pbergin!> has quit IRC (Remote host closed the connection)00:07
*** pbergin <pbergin!> has joined #yocto00:07
*** bps <bps!> has joined #yocto00:09
*** pbergin <pbergin!> has quit IRC (Remote host closed the connection)00:11
*** pbergin <pbergin!> has joined #yocto00:11
*** pbergin <pbergin!> has quit IRC (Remote host closed the connection)00:14
*** pbergin <pbergin!> has joined #yocto00:15
*** pbergin <pbergin!> has quit IRC (Remote host closed the connection)00:16
*** pbergin <pbergin!> has joined #yocto00:16
*** Wulf <Wulf!~Wulf@user/wulf> has quit IRC (Ping timeout: 252 seconds)00:19
*** pbergin <pbergin!> has quit IRC (Remote host closed the connection)00:20
*** pbergin <pbergin!> has joined #yocto00:20
*** Wulf <Wulf!~Wulf@user/wulf> has joined #yocto00:21
*** florian <florian!> has quit IRC (Ping timeout: 260 seconds)00:23
*** pbergin <pbergin!> has quit IRC (Ping timeout: 252 seconds)00:27
*** jwillikers[m] <jwillikers[m]!~jwilliker@2001:470:69fc:105::626a> has quit IRC (Quit: Client limit exceeded: 20000)00:40
*** dev1990 <dev1990!> has quit IRC (Quit: Konversation terminated!)00:50
wesmI patched out the opengl dep check to see if I could get it to build. It wants GL/gl.h which I got from mesa but now I have a bunch of "undefined reference to glFoo etc" errors so something is still missing00:51
*** jordemort <jordemort!~jordemort@2001:470:69fc:105::2d9> has joined #yocto00:51
*** Spectrejan[m] <Spectrejan[m]!~spectreja@2001:470:69fc:105::1609> has joined #yocto00:51
*** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has joined #yocto00:51
*** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has joined #yocto00:51
*** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #yocto00:51
*** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has joined #yocto00:51
*** t_unix[m] <t_unix[m]!~tunixmatr@2001:470:69fc:105::9ea> has joined #yocto00:51
*** jonesv[m] <jonesv[m]!~jonesv@2001:470:69fc:105::4616> has joined #yocto00:51
*** zagor <zagor!~zagor@user/zagor> has joined #yocto00:52
*** barath <barath!~barath@2001:470:69fc:105::21a> has joined #yocto00:52
*** jwillikers[m] <jwillikers[m]!~jwilliker@2001:470:69fc:105::626a> has joined #yocto00:52
*** Barry[m] <Barry[m]!~barryriot@2001:470:69fc:105::900> has joined #yocto00:52
*** Dhruvagole[m] <Dhruvagole[m]!~dhruvag2k@2001:470:69fc:105::1:784> has joined #yocto00:52
*** JosefHolzmayrThe <JosefHolzmayrThe!~theyoctoj@2001:470:69fc:105::e785> has joined #yocto00:52
*** suy|m <suy|m!~suymatrix@2001:470:69fc:105::1:359d> has joined #yocto00:52
*** ericson2314 <ericson2314!~ericson23@2001:470:69fc:105::70c> has joined #yocto00:52
*** cperon <cperon!~cperonmat@2001:470:69fc:105::2d1a> has joined #yocto00:53
*** Epictek[m] <Epictek[m]!~epictekma@2001:470:69fc:105::d7cd> has joined #yocto00:53
*** nrossi[m] <nrossi[m]!~nrossimat@2001:470:69fc:105::1:4527> has joined #yocto00:53
*** vd <vd!> has quit IRC (Quit: Client closed)00:53
*** vd <vd!> has joined #yocto00:54
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Read error: Connection reset by peer)01:06
*** prabhakarlad <prabhakarlad!> has joined #yocto01:07
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto01:11
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)01:16
*** camus1 <camus1!~Instantbi@> has joined #yocto01:30
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 250 seconds)01:32
*** camus1 is now known as camus01:32
*** prabhakarlad <prabhakarlad!> has quit IRC (Ping timeout: 256 seconds)01:45
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)01:46
*** camus <camus!~Instantbi@> has joined #yocto01:46
*** davidinux <davidinux!> has quit IRC (Ping timeout: 256 seconds)02:13
*** sakoman <sakoman!> has joined #yocto02:37
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)02:40
*** camus <camus!~Instantbi@> has joined #yocto02:40
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 268 seconds)02:51
*** xmn <xmn!> has quit IRC (Read error: Connection reset by peer)02:56
*** davidinux <davidinux!> has joined #yocto03:26
*** geoffhp60 <geoffhp60!> has joined #yocto03:34
*** bluelightning <bluelightning!~paul@2406:e003:151f:d701:98be:7f77:74ff:efb1> has quit IRC (Quit: Konversation terminated!!!111)04:13
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)04:16
*** camus <camus!~Instantbi@> has joined #yocto04:16
vdcore-image-minimal-initramfs has COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)' and my HOST_SYS is arm-oe-linux-gnueabi and yet initramfs-module-install was skipped: incompatible with host. Why am I missing?04:39
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:42
*** berton[m] <berton[m]!~berton@2001:470:69fc:105::ce36> has quit IRC (Quit: Client limit exceeded: 20000)04:43
*** troth <troth!> has quit IRC (Ping timeout: 265 seconds)04:56
*** troth <troth!> has joined #yocto05:10
*** tlwoerner_ <tlwoerner_!> has quit IRC (Quit: Leaving)05:41
*** tlwoerner_ <tlwoerner_!> has joined #yocto05:41
*** tlwoerner_ <tlwoerner_!> has quit IRC (Remote host closed the connection)05:42
*** tlwoerner <tlwoerner!> has joined #yocto05:43
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 276 seconds)06:04
*** kiran_ <kiran_!~kiran@2607:fea8:5a80:ea0:1b75:bf06:137c:45f1> has quit IRC (Ping timeout: 265 seconds)06:15
*** camus1 <camus1!~Instantbi@> has joined #yocto06:39
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)06:41
*** camus1 is now known as camus06:41
*** vd62 <vd62!> has joined #yocto06:48
*** vd <vd!> has quit IRC (Ping timeout: 256 seconds)06:51
*** rob_w <rob_w!> has joined #yocto06:53
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto06:57
*** troth <troth!> has quit IRC (Ping timeout: 260 seconds)07:25
*** F_Adrian <F_Adrian!~F_Adrian@> has joined #yocto07:28
*** kayterina <kayterina!~kayterina@> has joined #yocto07:29
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)07:32
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto07:32
*** troth <troth!> has joined #yocto07:39
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:41
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)07:42
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)07:46
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto07:46
*** Borimo <Borimo!~user@> has joined #yocto07:48
*** _whitelogger <_whitelogger!> has quit IRC (Remote host closed the connection)07:51
*** _whitelogger <_whitelogger!> has joined #yocto07:52
*** vd62 <vd62!> has quit IRC (Ping timeout: 256 seconds)07:54
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:57
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:01
*** rfuentess <rfuentess!> has joined #yocto08:05
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)08:08
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:09
*** goliath <goliath!~goliath@user/goliath> has joined #yocto08:13
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)08:14
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:15
wyrewhat's the proper way to generate the patch for arch/arm/boot/dts/Makefile ?08:20
*** berton[m] <berton[m]!~berton@2001:470:69fc:105::ce36> has joined #yocto08:20
wyrecould I just use diff?08:20
wyreI'm asking this because when I run diff I can see a relative path in the output
wyreand I'm not sure how this will affect08:21
wyrehow this will affect the do_patch task, I mean08:22
deuteronwyre: I'd normally do like `cp Makefile Makefile.orig`08:36
deuteronThen from the source directory run `diff -u arch/arm/boot/dts/Makefile{,.orig}`08:37
deuteronThat'll get you closer, but you'll probably have to put a/ and b/ prefixes on the paths.08:37
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)08:38
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:39
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)08:43
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:44
*** davidinux <davidinux!> has quit IRC (Ping timeout: 256 seconds)08:44
*** davidinux <davidinux!~davidinux@> has joined #yocto08:45
*** mariusz <mariusz!~mariusz@> has joined #yocto08:56
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)08:58
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:58
wyredeuteron, I just cloned the kernel repo and made the modification in there and used git diff 😉09:02
wyrebut thank you anyway 😊09:02
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)09:03
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:03
qschulzwyre: devtool modify <kernel> and do the change in the workspace09:07
qschulzwhich ultimately is the same thing that you did,. except that devtool update-recipe creates the patches for you once you've committed in the kernel workspace git repo09:07
*** destmaster <destmaster!> has joined #yocto09:09
*** destmaster <destmaster!> has quit IRC (Client Quit)09:09
wyrewhy do you think python3-cheroot is failing?
wyreapparently it's available for pyro ... 🤔09:30
*** prabhakarlad <prabhakarlad!> has joined #yocto09:35
*** michalkotyla <michalkotyla!> has joined #yocto09:35
wyreapparently it needs setuptools_scm>=1.15.0 but it's in meta-openembedded/meta-python/recipes-devtools/python/python3-setuptools-scm_1.15.0.bb09:37
wyreso I don't get why it's failing...09:37
JosefHolzmayrTheyo dudX09:38
qschulzwyre: do you have meta-openembedded/meta-python in your bblayers.conf? but also.. pyro? really?09:41
wyreqschulz, I need to build pyro because my SoMs only have 128MB of DRAM09:41
wyreand apparently newer kernels wont be able to allocate enough DRAM09:42
wyreto bootr09:42
* JosefHolzmayrThe will happily place a bet on booting latest master wth 64MByte or less.09:42
wyreJosefHolzmayrThe, can you give me a clue about how to do it? 🤔09:43
JosefHolzmayrThesure thing. 1) compile 2) boot.09:43
qschulzwyre: the kernel has nothing to do with the Yocto version you can use09:44
*** kayterina <kayterina!~kayterina@> has quit IRC (Read error: Connection reset by peer)09:44
qschulzYocto is a build system, just write a kernel recipe that fetches the kernel version you think you need to use09:45
wyreqschulz, I see09:45
JosefHolzmayrTheqschulz: lets say "under some preconditions"09:45
*** pbergin <pbergin!> has joined #yocto09:46
qschulzJosefHolzmayrThe: ? care to elaborate?09:46
JosefHolzmayrTheqschulz: sure ;-) the most prominent one is if you're stuck on a rather old vendor kernel, it is often very problematic to use a newer toolchain09:47
wyreI'm not sure also what kernel version would be more appropriate to boot in less than 128MB09:48
*** MauroAnjo <MauroAnjo!~MauroAnjo@> has joined #yocto09:48
qschulzwyre: well, aren't you using a specific kernel in your pyro build? start by using this one?09:48
wyreI don't know even if would be possible to build newer versions to make them bootable with this low DRAM availability09:49
qschulzJosefHolzmayrThe: indeed, just disable all the warnings turned into errors and it's fine :D09:49
* JosefHolzmayrThe has just kicked off poky master and will likely boot it on low memory in a few minutes.09:49
qschulzJosefHolzmayrThe: if it does not work, you probably want to lower the amount of memory allocated to CMA09:49
wyreDo you think could I do what I've suggested?09:50
JosefHolzmayrTheqschulz: nope. there was a time when the kernel actually did magic depending on the reported version string by gcc and would fall over09:50
qschulzthere's a config for it or I think passing cma=16MB or similar should help09:50
wyreqschulz, just to do what I've said?09:51
qschulzJosefHolzmayrThe: yeah, there's a reason I hate working with vendor kernels :)09:51
qschulzwyre: my last remark was for JosefHolzmayrThe09:51
JosefHolzmayrTheqschulz: thats what i meant with "preconditions"09:51
qschulzyeah good point09:51
qschulzI mean... at one point it might even make more sense to build the kernel by yourself outside of Yocto then :p09:52
JosefHolzmayrTheqschulz: heh yeah09:53
*** mariusz <mariusz!~mariusz@> has quit IRC (Ping timeout: 256 seconds)09:54
wyreqschulz, this is the kernel recipe I'm using to build dunfell on my MACHINE
wyredo you think I just could create another recipe for a different branch with a lower kernel version and create a custom MACHINE config file?09:56
qschulzwyre: see points raised by JosefHolzmayrThe09:57
wyreupss ... no, they just have branches for 5.4 and 5.1009:58
qschulzbut who does not try does not know09:58
wyreI probably will have to use the pyro kernel 😥09:58
ykronsHello, I see the following in a recipe, but could not find the meaning of the (= ${variable}) syntax (e.g.: RDEPENDS_${PN}-dev = "avahi-daemon (= ${EXTENDPKGV}) libavahi-core (= ${EXTENDPKGV})"). Could someone explain it to me please?09:59
qschulzwyre: there's no pyro kernel!09:59
wyreqschulz, sure, I know09:59
wyrein fact is an Engicam's kernel10:00
wyreI meant the kernel version Engicam's using in their BSP to build pyro10:00
qschulzthe point being, you might be stuck with an old kernel (though "stuck" is relative) but that is usually not a reason for having a really old version of Yocto used to build it10:00
wyreI guess that's what you meant when you talked about vendor kernels10:00
qschulzI build a 4.4 kernel on Dunfell for example10:00
JosefHolzmayrThewyre: when can we actually invoice you or engicam?10:00
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 260 seconds)10:11
*** davidinux <davidinux!> has joined #yocto10:13
*** sstiller <sstiller!> has joined #yocto10:16
RP"tar (child): zstd: Cannot exec: No such file or directory" - why would a previously fine autobuilder worker do that :/10:17
rburtonrfs613: the pydevshell (or devpyshell, can't remember) gives you a python interactive shell, where you can do d.expand("${bindir}") iirc10:18
*** florian <florian!> has joined #yocto10:21
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)10:25
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:25
qschulzRP: I don't know, same question as to why I have pseudo aborts when I don't pass --tmpfs /tmp to containers10:27
RPqschulz: what does pseudo.log say?10:28
qschulztlwoerner: hi /me waves do you want me to ping on the mail for the meta-rockchip patches so you get them at the top of your mailbox :) or is this message enough :) ?10:28
qschulzRP: path mismatch10:28
JosefHolzmayrThewyre: qschulz for the record, latest poky master qemuarm boots flawlessly with 64M. no magic needed, just kicked off 'runqemu nographic slirp qemuparams="-m 64"'10:29
hmw[m]Hi, i have added layer meta-qt5-extra  but now it is complainging that it needs multimedia-layer ( i have oe-core/meta/recipes-multimedia)10:31
qschulzhmw[m]: meta/recipes-multimedia is not a layer10:31
RPqschulz: right, but which path. Can you share the exact log message please?10:31
JosefHolzmayrThehmw: 1) meta-multimedia is a part of meta-openembedded 2) make sure all layers are on the same release.10:32
wyreJosefHolzmayrThe, I'm assuming you aren't using a specific vendor kernel, right?10:32
RPqschulz: Was that with containers?10:32
qschulzRP: /tmp paths I don't think I have the logs anymore but it shouldn't take too long10:32
qschulzRP: yes10:32
JosefHolzmayrThewyre: standard poky10:32
*** mvlad <mvlad!~mvlad@2a02:2f08:4d01:ef00:24d7:51ff:fed6:906d> has joined #yocto10:33
RPqschulz: I have a feeling inodes are being deleted outside the container and confusing things10:33
qschulzRP: but /tmp isn't mounted without --tmpfs /tmp so I'm quite confused what could be happening10:34
wyreJosefHolzmayrThe, so this problem with memory allocation must be in this 5.4.70 version of the kernel from Engicam
JosefHolzmayrThewyre: like i said, when can we invoice you or engicam?10:35
qschulzwyre: vendors usually allocate WAY too much memory for graphic stuff, just to make sure they never have customers hitting weird issues10:35
wyreI didn't know you were here to make money, JosefHolzmayrThe 😆10:35
JosefHolzmayrThewyre: they sell hardware, they get the money. and you're probably not doing this for fun too.10:35
qschulzso I wouldn't be surprised it's just a configuration thing10:35
wyreqschulz, but could I change this memory allocation by modifying build params for the kernel? 🤔10:35
wyreJosefHolzmayrThe, well, I so keen on Yocto actually, I like so much the project 😊10:36
JosefHolzmayrThewyre: i'm not here *for* the money, but I stand for the common sense of liability that those who get the money also should provide the support.10:36
qschulzwyre: the point JosefHolzmayrThe is trying to make is that doing free support for vendors isn't really something to be expected from communities :)10:36
wyresure qschulz I know that and I'm so grateful to you because all of your help10:37
wyreyou are helping me a lot to understand how this environment works10:37
qschulzwyre: if it's only CMA pool being too big, there should be a kconfig option yes, or passing cma=<somnething> to the kernel command line via bootargs in U-Boot or whatever bootloader you're using10:37
JosefHolzmayrThewyre: so if you're running into things that are of relevance to more people, then I'm happy to try and explain. yet if we're all wasting our time on a BSP that ships old layers and you can't get working because whatever, then, well... I just think its unfair behaviour on mostly engicams, but also your side.10:38
qschulzbut that's too deep into your vendor BSP and I *personally* will not help with this more as the community does not really benefit from this (and also, kernel question on yocto chan :) )10:38
qschulzJosefHolzmayrThe: stop saying the same things ugh :p10:38
JosefHolzmayrTheqschulz: no probem. I'll stop saying and resort to typing, mkay?10:39
wyrewell, anyway thank you very much, because you give me a few researching lines 😊10:39
qschulzwyre: our pleasure, good luck :)10:40
*** davidinux <davidinux!> has quit IRC (Ping timeout: 250 seconds)10:40
RPqschulz: what is /tmp in that case instead? part of the container rootfs?10:41
*** davidinux <davidinux!~davidinux@> has joined #yocto10:42
hmw[m]Josef Holzmayr (TheYoctoJester): qschulz : tnx i was missing it in the bblayer file10:44
qschulzhmw[m]: :+1:10:45
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 260 seconds)10:59
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)11:00
qschulzRP: if that matters in any way, I'm using rootless podman for the machine that failed with pseudo aborts11:02
qschulzwhich AFAICT is using fuse-overlayfs? (podman 3.0.1 + 5.10.x kernel on a debian bullseye)11:04
*** creich <creich!> has quit IRC (Remote host closed the connection)11:07
ykronsAnyone could help about the  (= ${variable}) syntax ? I can't find explaination in bitbake and yocto documentation11:08
rburtonykrons: got an example?11:13
rburtondo you mean in RDEPENDS?11:13
rburtonif so then
RPqschulz: I suspect something odd with the filesystem stuff, overlayfs is a nightmare with pseudo :(11:14
ykronsrburton: Yes it is RDEPENDS related:  RDEPENDS_${PN}-dev = "avahi-daemon (= ${EXTENDPKGV}) libavahi-core (= ${EXTENDPKGV})"11:16
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)11:17
ykronsrburton: thanks for the link, I have a look11:17
*** MauroAnjo <MauroAnjo!~MauroAnjo@> has quit IRC (Quit: Client closed)11:18
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:18
*** otavio_ <otavio_!> has quit IRC (Remote host closed the connection)11:20
*** otavio <otavio!> has joined #yocto11:22
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)11:22
*** pbergin <pbergin!> has quit IRC (Ping timeout: 260 seconds)11:23
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:23
rburtonthat's just saying that avahi-dev depends on avah-daemon of the exact version, so they get upgraded in unison11:29
*** bps <bps!> has joined #yocto11:50
RPykrons: the version constraints effectively get passed to the package managers like opkg/dpkg/rpm11:50
*** tre <tre!> has joined #yocto11:55
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 260 seconds)11:55
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)11:58
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:59
*** pbergin <pbergin!> has joined #yocto12:04
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)12:04
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:04
*** pbergin_ <pbergin_!~pbergin@> has joined #yocto12:09
*** pbergin <pbergin!> has quit IRC (Ping timeout: 260 seconds)12:12
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)12:14
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:14
*** tnovotny <tnovotny!> has joined #yocto12:27
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)12:29
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:29
qschulzRP: yeah that would be my guess too. Don't have any more ideas though :/12:30
tlwoernerqschulz: i'll look at them today, thanks!12:35
*** adrian_ <adrian_!~F_Adrian@> has joined #yocto12:36
qschulztlwoerner: not urgent but I saw that you were reviewing/merging patches from Khem so I didn't want the patches to be forgotten :)12:37
*** F_Adrian <F_Adrian!~F_Adrian@> has quit IRC (Ping timeout: 250 seconds)12:38
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto12:41
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)12:46
perdmann_Hi, i have a weird behaviour. A custom software is running if i start it in the console. If i start it via a systemd service it is starting but something is missing. So how can i compare these startup behaviours?12:47
rburtonwhen run as a service you'll have less environment variables set (as its not an interactive login), and no TTYs connected12:48
rburtonso most likely one of those, and really most likely the environment12:48
perdmann_rburton: yes i already checked this and tried to create that environment in the start script i created...12:48
perdmann_Is it possible to run a service in a specific user environment (with kind of login?)?12:49
rburtonyou can set the user to run as, and set any environment12:49
rburtondont' think you can fake a login though12:49
ykronsI've got a SDK problem that seems to be linked to the watchdog recipe. I have included watchdog-keepalive package in my image, and now SDK reports a solver warning due to a conflict with watchdog package ("RCONFLICTS_${PN}-keepalive += "${PN}") and a lot of other packages data are missing from the SDK.12:52
ykronsIs it because yocto try to include watchdog-keepalive-dev in the SDK and fallbacks on watchdog-dev because there is no watchdog-keepalive-dev package defined?12:53
perdmann_rburton: i have to try, thank you12:53
perdmann_rburton: it is an Qualcomm delivery. Its awful12:53
ykronsAnd shouldn't the SDK build fail in that case rather than reporting only a warning and produces a broken SDK?12:54
coldspark29[m]JPEW: So I just tried to setup pyrex with the Yocto quick build from the docs and I could successfully start the container, although I don't see them listed under `docker container ls -a`. When I try typing `bitbake core-image-sato`, it tells me... (full message at
*** geoffhp60 <geoffhp60!> has quit IRC (Quit: Client closed)12:59
qschulzcoldspark29[m]: the container is spawned only when bitbake is running13:01
coldspark29[m]Okay cool13:01
coldspark29[m]But why can't I run bitbake?13:01
qschulzbut you can?13:02
qschulzbecause otherwise you wouldn't have this error13:02
coldspark29[m]Well yes13:02
qschulzjust a "bitbake not found" from your distro13:02
coldspark29[m]But it should find the meta directories right?13:02
coldspark29[m]Or did I run pyrex in the wrong directory? Cloned it into the poky directory13:02
qschulzthe directory where the layers are should be mounted in your container13:03
coldspark29[m]I thought everything would be set up automatically using the quick start guide13:05
qschulzPYREX_BIND should be set, I don't know if it defaults to $(pwd) or not13:05
JPEWcoldspark29[m]: if you don't have the exact layout as the quick start, you have to tweak it a little13:06
coldspark29[m]That one?13:06
JPEWIt's really hard to guess all the little variations people might have13:06
JPEWAlso, the container only runs while bitbake is running13:08
qschulzJPEW: yeah which makes it hard to inspect if it's correctly set up. Is there some command/trick to have it running so one can docker/dpoman exec -it in it?13:09
coldspark29[m]bitbake  contrib        LICENSE               LICENSE.MIT     Makefile  meta       meta-pyrex     meta-skeleton   oe-init-build-env     pyrex.ini   scripts13:09
coldspark29[m]build    documentation  LICENSE.GPL-2.0-only  MEMORIAM  meta-poky  meta-selftest  meta-yocto-bsp  pyrex-init-build-env  README.qemu.md13:09
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)13:09
coldspark29[m]It is the standard poky honister from the Yocto qucik build guide13:09
*** mvlad <mvlad!~mvlad@2a02:2f08:4d01:ef00:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)13:10
JPEWYour bblayers.conf file is referencing the wrong paths13:10
JPEWYou want /home/claussenj instead of /home/yocto13:11
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto13:11
*** mvlad <mvlad!~mvlad@2a02:2f08:4d01:ef00:24d7:51ff:fed6:906d> has joined #yocto13:11
*** goliath <goliath!~goliath@user/goliath> has joined #yocto13:12
coldspark29[m]Ah yeah, I downloaded poky with another container. That's why13:13
coldspark29[m]Yeah it runs :)13:14
coldspark29[m]Settings this up for our already worked on project will be a bit painful I guess13:15
JPEWDepends. If you don't already use a container, it shouldn't be too bad13:17
coldspark29[m]Do I have to add the pyrex folders to my repo? Not sure if my colleagues will want to use it as well.13:20
coldspark29[m]Upload them to Github I mean13:20
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)13:21
*** camus <camus!~Instantbi@> has joined #yocto13:21
coldspark29[m]Because we work with repo and would lose all those folder when syncing I guess13:22
JPEWcoldspark29[m]: do you mean meta-pyrex?13:24
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 250 seconds)13:25
JPEWYou usually want to make pyrex.ini available for your coworkers if they are going to use pyrex so that they can get the same container version etc13:26
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)13:26
*** pbergin__ <pbergin__!> has joined #yocto13:26
*** davidinux <davidinux!> has joined #yocto13:27
*** pbergin_ <pbergin_!~pbergin@> has quit IRC (Ping timeout: 260 seconds)13:27
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)13:34
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:35
*** tre <tre!> has quit IRC (Remote host closed the connection)13:39
hmw[m]hi, my weston keeps crashing a few minits after boot ( if i restart it manualy it keeps running) it crashes with caught signal 1513:47
rburton       SIGTERM         15          15      15      1513:48
rburtonit gets killed13:48
rburtonslap a gdb on it13:49
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 268 seconds)13:50
*** sakoman <sakoman!> has joined #yocto13:56
*** dacav <dacav!> has joined #yocto14:00
coldspark29[m]<JPEW> "You usually want to make pyrex...." <- Yes, so I guess we would have to merge it into our repo as well. I will have to see about that. One new colleague wants to use an Eclipse plugin and the other uses geany for editing. So the demand might not be so high. I really like it though.14:18
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)14:18
JPEWcoldspark29[m]: Ya, the idea is since only bitbake runs in a container, they can still use their editor of choice in the host14:18
*** zpfvo <zpfvo!~fvo@> has joined #yocto14:19
coldspark29[m]And if Garmin uses it, it can't be so bad. The later watch models are also better in the softwaree department. Hoping that this trend will continue. I just sold my Apple watch, because it was too annoying and the Garmin watches are still not Smart enough for me ;)14:19
coldspark29[m]JPEW: It's a neat feature actually14:21
dacavHi.  I'm trying to understand how the devicetrees are handled for the SoC I'm working on.  As far as I know, the device trees for many platforms are often found in the kernel sources.  In this case some dts files are provided within a yocto layer, there are also some dtsi files... but I can't make sense of them14:21
coldspark29[m]dacav: .dtsi files are included files. They are like .h files in C14:22
coldspark29[m]In the end the .dts and .dtsi files are all compiled into a single .dtb file14:22
dacavI'm wondering, to begin with, how it works with the dt hierarchy: I know that it is a tree and there should be at most one root, but can / be declared by multiple dts/dtsi?  If so, are they merged?14:22
dacavI could not find this info in the specification14:23
qschulzdacav: yes14:23
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)14:23
qschulzeverything redeclared is merged14:24
coldspark29[m]I am not sure about that. Also pretty new here.14:24
qschulzand it's merged in the order in which it is included14:25
qschulzso if you have a property that is redeclared multiple times (e.g. "status")14:25
qschulzthe last included dtsi or the final dts has the last word14:26
qschulzotherwise, just do you tests yourself and then use `dtc -I dtb -O dts my.dtb`14:26
qschulzphandles won't be in the human form but most of it should be readable14:27
qschulzhuman readable form obviously :)14:27
*** codavi <codavi!~akiCA@user/akica> has joined #yocto14:28
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto14:30
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 268 seconds)14:33
*** manuel_ <manuel_!~manuel198@> has quit IRC (Ping timeout: 250 seconds)14:33
*** kayterina <kayterina!~kayterina@> has joined #yocto14:37
*** zpfvo <zpfvo!~fvo@> has joined #yocto14:38
qschulzmmmm damn opengl :/14:39
qschulzso there's a header file for opengl es 3 which is supposed to be called gl2ext.h according to Khronos doc, but mesa provides a gl3ext.h only14:39
qschulzkmscube (a mesa project) includes gl3ext.h and therefore breaks projects where only gl2ext.h is provided, e.g. rockchip's libmali14:40
qschulzso I don't know what to do :)14:40
qschulzoh, and most important piece of information. The gl{2,3}ext.h file is empty.14:41
dacavAnother question (Q2): is the SRC_URL per-recipe, or per-layer?14:42
qschulzdacav: not sure to see what the use case would be for a per-layer SRC_URI14:43
qschulzit's per-recipe14:43
qschulzactually, it's gl3ext.h from mesa that is empty, gl2ext.h is not14:44
qschulzok nevermind, I was looking for gl2ext.h in include/GLES314:45
*** maoti__ <maoti__!> has joined #yocto14:46
*** jpuhlman_ <jpuhlman_!> has quit IRC (Ping timeout: 265 seconds)14:50
qschulzmmmm, are circular RDEPENDS possible?14:55
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)15:09
*** davidinux <davidinux!> has quit IRC (Quit: WeeChat 2.8)15:09
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:10
rburtonif you install them both at the same time, sure15:10
rburtonterrible idea though15:10
qschulzit's related to my monologue above15:11
qschulzbasically, I think libgles3-dev should RDEPENDS on libgles2-dev to have include/GLES2/gl2ext.h available15:11
qschulzhowever, mesa already has an RDEPENDS:mesa-ligles2-dev = "mesa-ligles3-dev" though I couldn't really make sense of the reason for this15:12
*** OnkelUlla <OnkelUlla!> has quit IRC (Remote host closed the connection)15:13
*** davidinux <davidinux!~davidinux@> has joined #yocto15:15
kanavinqschulz, pressure your vendor to ditch the blob :)15:16
kanavinthere are mali drivers in mesa15:16
*** marc1 <marc1!> has joined #yocto15:18
qschulzkanavin: the issue here being that mesa itself does not follow the specs15:22
qschulzbut my vendor does :)15:22
qschulzwell, not mesa, kmscube15:24
qschulzand mesa provides a file that shouldn't be here15:24
qschulzwhich kmscube includes but shouldn't15:24
JPEWqschulz: We ditched the vendor mali driver and hired collabra to add mesa for support our specific GPU (since it didn't already). Best money we've ever spent15:24
qschulz(see patches on the ML)15:24
qschulzJPEW: I've to check if Panfrost supports the Rockchip PX30 in some way15:25
qschulzbut that does not solve an actual issue in Yocto/kmscube/mesa15:25
JPEWqschulz: Sure. I don't know if panfrost supports the G series of GPUs; ours was an older one (who's name escapes me ATM)15:27
qschulzseems like it has a Mali G3115:27
qschulzand says it's a go15:27
qschulzbut.. don't know if it's well supported in 5.4 :/15:27
JPEWqschulz: Ah, we had a T-72015:27
qschulzthough they say it's non-conformant..15:28
dacavself-answers so far: SRC_URL is per-recipe.  While this was intuitively obvious, I was puzzled by the SRC_URL in question (apparently) lacking of some sources... it turned out that a .bbappend was hidden somewhere and adding stuff without me knowing it.  `bitbake ... -e` solved the mistery.15:30
qschulzJPEW: I'm always wary recommending FOSS GPU/VPU/IPU implementations to clients. You never know if it has implemented this fancy feature. Though admittedly, I've very little experience in dealing with that kind of stuff :)15:30
qschulzdacav: I answered you an hour ago15:30
qschulz(also, it's SRC_URI and not SRC_URL :) )15:31
qschulzdacav: but good use of bitbake -e :)15:31
JPEWqschulz: It does depend on the GPU, but in my expirence Panfrost is miles ahead of the vendor blobs when it comes to featyres15:31
JPEWqschulz: It basically gets all the mesa features, and has the same (or maybe even better) performance15:32
JPEWWe _had_ to switch because we needed some Wayland support the vendor blob just couldn't do15:32
qschulzJPEW: yeah, will think about it, quite difficult to make a client do such a big change during the life cycle of a product I think15:33
JPEWqschulz: Sure, that makes sense. I would keep it in mind though in case you come across some missing feature your SoC vendor is unwilling to implement15:34
qschulzJPEW: yeah if the vendor does not support something, first thing to try is if upstream supports it :) I don't like "supporting" vendor stuff but as said, don't feel couraadventurousnough to change that months/years after a product has started selling :|15:37
qschulzs/couraadventurousnough/adventurous enough/15:37
qschulzwill think of it when (if) we do a big jump between 5.4 and the next (next?) LTS15:38
qschulzJPEW: thanks for the feedback :)15:39
*** vd <vd!> has joined #yocto15:52
kayterinahello. I have a yocto repository that includes poky and the folder is added to .gitignore. When I checkout an older version of the repository, can I know if any changes in poky might make the build fail? Should git keep some info about the versions of all layers it uses?16:02
*** sstiller <sstiller!> has quit IRC (Quit: Leaving)16:08
qschulzkayterina: your layers should be kept in sync. We recommend using the same branch for each layer, they usually are named after the Yocto release they support16:10
qschulzfor how to keep them in sync, there's nothing implemented in Yocto, you'll have to use a 3rd party tool16:10
qschulzsome people use repo, git submodules too I assume, and some others use kas (
qschulzalso, the commit hash of each layer is printed when bitbake starts so you can always check that manually to see if something's off16:11
kayterinaa,yes I found .gitmodules. So this line "branch = zeus-patched" keeps poky at the same version?16:12
qschulzI don't use gitsubmodules so can't say :}16:12
qschulz:| *16:12
*** kiran_ <kiran_!~kiran@2607:fea8:5a80:ea0:a195:cd2f:5924:a3> has joined #yocto16:12
kayterinaok thanks16:13
JPEWkayterina: The `branch` line just tells git what the remote tracking branch should be for the repository. The actual commit SHA is stored in the git data16:23
JPEWIf the submodule isn't at the correct SHA-1, `git status` will show it as modified16:25
kayterinathere is a /.git/modules/sources/poky/HEAD, is that the SHA?16:27
JPEWkayterina: I beleive that is the current SHA-1 that is checked out, same as you would get from `git rev-parse HEAD` in the submodule16:29
JPEWkayterina: But... you really shouldn't poke around in the .git directory for anything; there are commands to tell you what you want to know16:29
JPEWkayterina: may be helpful16:30
t_unix[m]is there a CLI formatting tool for bitbake recipes?16:30
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Read error: Connection reset by peer)16:33
*** kayterina <kayterina!~kayterina@> has quit IRC (Read error: Connection reset by peer)16:38
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto16:39
RPJPEW: did you have a patch in mind to simplify the bitbake parser feeder process usage?16:47
JPEWRP: I don't think so, but if I did it would have been a while ago and I don't remember; can you remind me what it was about?16:49
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)16:49
RPJPEW: we have a feeder thread in the parsing code in It was there, I think added by kergoth to work around python bugs/issues in multiprocessing. I remember you disliked it quite a bit and wanted to remove it. I think we were close to release and I said to defer to afterwards and we never got back to it16:51
RPI've just been pondering whether asyncio would help cooker and the bitbake server code. Jury is still out on that :/16:52
JPEWAh, that sounds familiar. Let me look....16:52
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)16:54
*** zpfvo <zpfvo!~fvo@> has joined #yocto16:55
JPEWRP: poky-contrib cgit seems to not be updated, but is 153ebe3ade191b6cb99f7aae07e2766c317b03b4 in poky-contrib what you were thinking of?17:02
RPJPEW: yes, that looks like it!17:03
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)17:04
JPEWRP: FYI I *just* rebased it, so I don't know if it works just yet17:04
RPJPEW: I was looking at the exception handling and wondering if that was right :)17:04
*** zpfvo <zpfvo!~fvo@> has joined #yocto17:05
RPwould certainly be nice to clean that up if we can17:05
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)17:10
JPEWWhich exception handling?17:11
rburtonRP: would it be sensible to make bitbake spawn its workers use sys.exe or whatever so that it uses the exact same py interpretter instead of searching $path for python3?17:11
RPJPEW: Looking more closely I think it is fine17:12
RPrburton: probably17:12
rburton<cough> for no reason17:12
RPrburton: I have a good imagination :/17:12
rburtonawwww pypy's os module isn't identical to standard py17:13
*** dev1990 <dev1990!> has joined #yocto17:13
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)17:13
JPEWRP: Ah, the old ParserFailure wrapping? Ya that's unnecessary now. multiprocessing does a better job passing the execeptions back to the parent17:14
RPJPEW: right, it makes sense when you step back17:14
*** zpfvo <zpfvo!~fvo@> has joined #yocto17:14
*** geoffhp <geoffhp!> has quit IRC (Remote host closed the connection)17:20
*** florian <florian!> has quit IRC (Quit: Ex-Chat)17:24
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Read error: Connection reset by peer)17:24
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)17:28
*** zpfvo <zpfvo!~fvo@> has joined #yocto17:29
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto17:30
*** camus <camus!~Instantbi@2409:8a1e:911a:6f50:7def:ceaf:df3d:f0f0> has joined #yocto17:31
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)17:34
*** dev1990 <dev1990!> has quit IRC (Quit: Konversation terminated!)17:37
*** geoffhp <geoffhp!> has joined #yocto17:48
*** camus <camus!~Instantbi@2409:8a1e:911a:6f50:7def:ceaf:df3d:f0f0> has quit IRC (Ping timeout: 240 seconds)17:54
*** camus <camus!~Instantbi@2409:8a1e:911a:6f50:116b:1b17:21b5:68c5> has joined #yocto17:58
kergotht_unix[m]: unfortunately not. It's not entirely trivial to reformat bitbake recipes, particularly if you want to reorder or sort lines, as bitbake's file format is order dependent, and lines may well depend on one another, or require that they are set before or after inherit, etc18:02
kergothA simple one that just corrects indentation and whatnot would be easy enough, and oe-stylize does exist but has flaws18:03
kergothIdeally I think we could implement reordering using our knowledge of variable dependencies, at least within sections delinated by inherits.. hmm18:03
kergothNow to test lima+nerdctl for yocto builds on my macbook18:04
kergothRP, JPEW: Oh I'd love to see the parsing process crap streamlined. it's amazing looking back at how many issues we've hit with multiprocessing over the years..18:05
kergothOT, but anyone know offhand if we require a python version that supports f-strings yet?18:05
*** florian <florian!> has joined #yocto18:10
rfs613when adding a new (3rd party) layer to an existing project, is there a way to check whether existing recipes are affected (eg. some bbappend from the new layer etc)?18:13
t_unix[m]kergoth: yeah, I know it's non-trivial. Indentation would be sufficient for me atm though.18:18
kergothFair enough, your best bet about that sort of thing is to check oe-core's scripts dir, particularly scripts/contrib18:19
*** mariusz <mariusz!~mariusz@> has joined #yocto18:28
*** florian <florian!> has quit IRC (Ping timeout: 268 seconds)18:28
JPEWkergoth: python is new enough, but I think we are holding off on using fstrings just yet so that backports are still possible18:29
*** mariusz <mariusz!~mariusz@> has quit IRC (Ping timeout: 260 seconds)18:33
kergothAh, makes sense.18:38
kergothThey sure are nice, I'm looking forward to it :)18:38
* RP suspects we won't be able to hold off for much longer, right rburton? :)18:44
*** kroon <kroon!> has joined #yocto18:47
kroonqschulz, ping18:47
frayI didn't mind '%' format.. but I always hated str.format(...)19:03
fraythe new f-string format (hadn't seen it before) seems reasonable though19:03
JPEWRP: asyncio is helpful if you have a lot of I/O bound things to do at once; I don't think it would necessarily help with parsing per-se, but probably with task execution (where the bitbake main process has to wait for a bunch of subprocesses to do things19:17
JPEWIt lets you write code a lot more naturally at least since you don't need to have callbacks and state being passed all over the place19:19
*** kroon <kroon!> has quit IRC (Quit: Leaving)19:24
*** xantoz <xantoz!> has quit IRC (Ping timeout: 265 seconds)19:30
*** aduskett <aduskett!~aduskett@> has joined #yocto20:19
aduskettHello, does anybody have any experience with selinux perchance? I have a read only file system and / is set to unlabeled_t on bootup. I can remount / as rw and run restorecon which sets it to root_t (as it should be) but this isn't ideal.20:21
*** adrian__ <adrian__!~F_Adrian@> has joined #yocto20:30
RPJPEW: I wasn't thinking about parsing, more about the server and command processing and handling the different data read/writes20:30
RPJPEW: looking at the code I was reminded about the parsing change20:30
*** adrian_ <adrian_!~F_Adrian@> has quit IRC (Ping timeout: 250 seconds)20:32
*** adrian__ <adrian__!~F_Adrian@> has quit IRC (Ping timeout: 268 seconds)20:38
*** mvlad <mvlad!~mvlad@2a02:2f08:4d01:ef00:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)20:51
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)20:54
rburtonkergoth: have you tried using lima on macos to do a yocto build?21:00
kergothI have, actually. It's workable if you don't mind shoving your tmpdir into a volume, you can't use bind mounts with -v for that on mac right now, lima uses sshfs for it, and it mucks up permissions21:01
rburtoni was guessing that would be the problem21:02
rburtoni've done a build in a vm on my m1 mbp and was quite impressed21:02
kergothI usually like to use bind mounts to make the docker usage transparent, but not workable on the mac21:02
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)21:03
kergothI'm hopeful that lima moves in the qemu+9p direction or so21:03
rburtonyeah, they said that in the readme21:03
kergothlima is really nice in general. easy use of nerdctl or podman is convenient21:03
rburtonlima looks a lot more like my style than parallels21:03
kergothyeah, it's like wsl basically..21:03
kergothUgh, can't leave the layers in an rw bind mount either, it needs to write and bitbake.lock in builddir. will have to just drop into the container and do everything in the volume. workable, just irritating, and it means i can't use vscode for the layer content..21:08
kergothdocker for desktop might have license issues, but it certainly avoided these issues21:08
kergothI'd like to see pyrex get support for nerdctl in general as well as support for nerdctl or podman via lima as alternatives to native podman, which doesn't support host volumes at all21:09
JPEWRP: Can you really get a data stream to bitbake-worker that looks like "<foo>A</foo>B</foo>"?21:11
JPEWIt's certianlly written to handle that :/21:11
RPJPEW: that certainly shouldn't happen. We did add some code to make it error and give decent debug info for malformed streams though?21:19
JPEWYa, but the deserializing code will keep looping looking for "</foo>" and handling it... looks like some strange leftover21:20
RPJPEW: I don't remember. It could well be some kind of leftover21:26
rfs613rburton: thanks for the tip about 'devpyshell', very handy.21:27
kergothrburton: seems like lima is viable if you stick to the linux homedir and do all development inside, it's only if you try to use host paths whether via containers or not that you run into headaches.21:58
*** kiran_ <kiran_!~kiran@2607:fea8:5a80:ea0:a195:cd2f:5924:a3> has quit IRC (Ping timeout: 250 seconds)22:07
*** vd <vd!> has quit IRC (Quit: Client closed)22:17
*** vd <vd!> has joined #yocto22:18
*** florian <florian!> has joined #yocto22:18
*** troth <troth!> has quit IRC (Quit: Leaving.)22:21
*** pbergin__ <pbergin__!> has quit IRC (Ping timeout: 250 seconds)22:27
kergothHmm, wonder if there's a way to share data between lima instances without going through the host22:32
*** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 250 seconds)22:49
kergothWorks pretty well without containers in the mix. Here's hoping that sshfs issue gets fixed eventually for that piece22:53
*** mischief2 is now known as mischief23:09
*** mischief <mischief!> has quit IRC (Quit: WeeChat 3.3)23:14
*** mischief <mischief!> has joined #yocto23:14
*** florian <florian!> has quit IRC (Ping timeout: 252 seconds)23:31

Generated by 2.17.2 by Marius Gedminas - find it at!