| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 240 seconds) | 00:02 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has quit IRC (Remote host closed the connection) | 00:03 | |
| *** manuel_ <manuel_!~manuel198@185.68.248.44> has joined #yocto | 00:04 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has joined #yocto | 00:04 | |
| *** florian <florian!~florian@dynamic-093-132-158-056.93.132.pool.telefonica.de> has joined #yocto | 00:05 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has quit IRC (Remote host closed the connection) | 00:06 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has joined #yocto | 00:06 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 250 seconds) | 00:06 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has quit IRC (Remote host closed the connection) | 00:07 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has joined #yocto | 00:07 | |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 00:09 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has quit IRC (Remote host closed the connection) | 00:11 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has joined #yocto | 00:11 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has quit IRC (Remote host closed the connection) | 00:14 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has joined #yocto | 00:15 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has quit IRC (Remote host closed the connection) | 00:16 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has joined #yocto | 00:16 | |
| *** Wulf <Wulf!~Wulf@user/wulf> has quit IRC (Ping timeout: 252 seconds) | 00:19 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has quit IRC (Remote host closed the connection) | 00:20 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has joined #yocto | 00:20 | |
| *** Wulf <Wulf!~Wulf@user/wulf> has joined #yocto | 00:21 | |
| *** florian <florian!~florian@dynamic-093-132-158-056.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 00:23 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> 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!~dev@dynamic-78-8-166-98.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!) | 00:50 | |
| wesm | I 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 missing | 00:51 |
|---|---|---|
| *** jordemort <jordemort!~jordemort@2001:470:69fc:105::2d9> has joined #yocto | 00:51 | |
| *** Spectrejan[m] <Spectrejan[m]!~spectreja@2001:470:69fc:105::1609> has joined #yocto | 00:51 | |
| *** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has joined #yocto | 00:51 | |
| *** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has joined #yocto | 00:51 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #yocto | 00:51 | |
| *** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has joined #yocto | 00:51 | |
| *** t_unix[m] <t_unix[m]!~tunixmatr@2001:470:69fc:105::9ea> has joined #yocto | 00:51 | |
| *** jonesv[m] <jonesv[m]!~jonesv@2001:470:69fc:105::4616> has joined #yocto | 00:51 | |
| *** zagor <zagor!~zagor@user/zagor> has joined #yocto | 00:52 | |
| *** barath <barath!~barath@2001:470:69fc:105::21a> has joined #yocto | 00:52 | |
| *** jwillikers[m] <jwillikers[m]!~jwilliker@2001:470:69fc:105::626a> has joined #yocto | 00:52 | |
| *** Barry[m] <Barry[m]!~barryriot@2001:470:69fc:105::900> has joined #yocto | 00:52 | |
| *** Dhruvagole[m] <Dhruvagole[m]!~dhruvag2k@2001:470:69fc:105::1:784> has joined #yocto | 00:52 | |
| *** JosefHolzmayrThe <JosefHolzmayrThe!~theyoctoj@2001:470:69fc:105::e785> has joined #yocto | 00:52 | |
| *** suy|m <suy|m!~suymatrix@2001:470:69fc:105::1:359d> has joined #yocto | 00:52 | |
| *** ericson2314 <ericson2314!~ericson23@2001:470:69fc:105::70c> has joined #yocto | 00:52 | |
| *** cperon <cperon!~cperonmat@2001:470:69fc:105::2d1a> has joined #yocto | 00:53 | |
| *** Epictek[m] <Epictek[m]!~epictekma@2001:470:69fc:105::d7cd> has joined #yocto | 00:53 | |
| *** nrossi[m] <nrossi[m]!~nrossimat@2001:470:69fc:105::1:4527> has joined #yocto | 00:53 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has quit IRC (Quit: Client closed) | 00:53 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has joined #yocto | 00:54 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.191.89> has quit IRC (Read error: Connection reset by peer) | 01:06 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 01:07 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.191.126> has joined #yocto | 01:11 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 01:16 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 01:30 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 250 seconds) | 01:32 | |
| *** camus1 is now known as camus | 01:32 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 256 seconds) | 01:45 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds) | 01:46 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 01:46 | |
| *** davidinux <davidinux!~davidinux@net-109-116-25-240.cust.vodafonedsl.it> has quit IRC (Ping timeout: 256 seconds) | 02:13 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 02:37 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 02:40 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 02:40 | |
| *** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 268 seconds) | 02:51 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Read error: Connection reset by peer) | 02:56 | |
| *** davidinux <davidinux!~davidinux@net-109-116-25-69.cust.vodafonedsl.it> has joined #yocto | 03:26 | |
| *** geoffhp60 <geoffhp60!~geoffhp@cpe-107-185-48-203.socal.res.rr.com> has joined #yocto | 03:34 | |
| *** bluelightning <bluelightning!~paul@2406:e003:151f:d701:98be:7f77:74ff:efb1> has quit IRC (Quit: Konversation terminated!!!111) | 04:13 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 04:16 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 04:16 | |
| vd | core-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!~steve@rrcs-66-91-142-162.west.biz.rr.com> 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!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 265 seconds) | 04:56 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto | 05:10 | |
| *** tlwoerner_ <tlwoerner_!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has quit IRC (Quit: Leaving) | 05:41 | |
| *** tlwoerner_ <tlwoerner_!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has joined #yocto | 05:41 | |
| *** tlwoerner_ <tlwoerner_!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has quit IRC (Remote host closed the connection) | 05:42 | |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has joined #yocto | 05: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@58.246.136.202> has joined #yocto | 06:39 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds) | 06:41 | |
| *** camus1 is now known as camus | 06:41 | |
| *** vd62 <vd62!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has joined #yocto | 06:48 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 06:51 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:53 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 06:57 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 260 seconds) | 07:25 | |
| *** F_Adrian <F_Adrian!~F_Adrian@62.32.0.69> has joined #yocto | 07:28 | |
| *** kayterina <kayterina!~kayterina@62.38.55.161> has joined #yocto | 07: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 #yocto | 07:32 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto | 07:39 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 07:41 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> 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 #yocto | 07:46 | |
| *** Borimo <Borimo!~user@107.150.23.149> has joined #yocto | 07:48 | |
| *** _whitelogger <_whitelogger!~whitelogg@uruz.whitequark.org> has quit IRC (Remote host closed the connection) | 07:51 | |
| *** _whitelogger <_whitelogger!~whitelogg@uruz.whitequark.org> has joined #yocto | 07:52 | |
| *** vd62 <vd62!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 07:54 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:57 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 08:01 | |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 08:05 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 250 seconds) | 08:08 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 08:09 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 08:13 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 250 seconds) | 08:14 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 08:15 | |
| wyre | what'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 #yocto | 08:20 | |
| wyre | could I just use diff? | 08:20 |
| wyre | I'm asking this because when I run diff I can see a relative path in the output https://bpa.st/LKMA | 08:21 |
| wyre | and I'm not sure how this will affect | 08:21 |
| wyre | how this will affect the do_patch task, I mean | 08:22 |
| deuteron | wyre: I'd normally do like `cp Makefile Makefile.orig` | 08:36 |
| deuteron | Then from the source directory run `diff -u arch/arm/boot/dts/Makefile{,.orig}` | 08:37 |
| deuteron | That'll get you closer, but you'll probably have to put a/ and b/ prefixes on the paths. | 08:37 |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 260 seconds) | 08:38 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 08:39 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 250 seconds) | 08:43 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 08:44 | |
| *** davidinux <davidinux!~davidinux@net-109-116-25-69.cust.vodafonedsl.it> has quit IRC (Ping timeout: 256 seconds) | 08:44 | |
| *** davidinux <davidinux!~davidinux@84.17.59.176> has joined #yocto | 08:45 | |
| *** mariusz <mariusz!~mariusz@185.241.198.130> has joined #yocto | 08:56 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 250 seconds) | 08:58 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 08:58 | |
| wyre | deuteron, I just cloned the kernel repo and made the modification in there and used git diff 😉 | 09:02 |
| wyre | but thank you anyway 😊 | 09:02 |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 250 seconds) | 09:03 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 09:03 | |
| qschulz | wyre: devtool modify <kernel> and do the change in the workspace | 09:07 |
| qschulz | which 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 repo | 09:07 |
| *** destmaster <destmaster!~giuseppec@mail.abe.it> has joined #yocto | 09:09 | |
| *** destmaster <destmaster!~giuseppec@mail.abe.it> has quit IRC (Client Quit) | 09:09 | |
| wyre | why do you think python3-cheroot is failing? https://bpa.st/RREQ | 09:30 |
| wyre | apparently it's available for pyro ... 🤔 | 09:30 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 09:35 | |
| *** michalkotyla <michalkotyla!~quassel@85-222-117-222.dynamic.chello.pl> has joined #yocto | 09:35 | |
| wyre | apparently it needs setuptools_scm>=1.15.0 but it's in meta-openembedded/meta-python/recipes-devtools/python/python3-setuptools-scm_1.15.0.bb | 09:37 |
| wyre | so I don't get why it's failing... | 09:37 |
| JosefHolzmayrThe | yo dudX | 09:38 |
| qschulz | wyre: do you have meta-openembedded/meta-python in your bblayers.conf? but also.. pyro? really? | 09:41 |
| wyre | qschulz, I need to build pyro because my SoMs only have 128MB of DRAM | 09:41 |
| wyre | and apparently newer kernels wont be able to allocate enough DRAM | 09:42 |
| wyre | to bootr | 09:42 |
| * JosefHolzmayrThe will happily place a bet on booting latest master wth 64MByte or less. | 09:42 | |
| wyre | JosefHolzmayrThe, can you give me a clue about how to do it? 🤔 | 09:43 |
| JosefHolzmayrThe | sure thing. 1) compile 2) boot. | 09:43 |
| qschulz | wyre: the kernel has nothing to do with the Yocto version you can use | 09:44 |
| *** kayterina <kayterina!~kayterina@62.38.55.161> has quit IRC (Read error: Connection reset by peer) | 09:44 | |
| qschulz | Yocto is a build system, just write a kernel recipe that fetches the kernel version you think you need to use | 09:45 |
| wyre | qschulz, I see | 09:45 |
| JosefHolzmayrThe | qschulz: lets say "under some preconditions" | 09:45 |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has joined #yocto | 09:46 | |
| qschulz | JosefHolzmayrThe: ? care to elaborate? | 09:46 |
| JosefHolzmayrThe | qschulz: 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 toolchain | 09:47 |
| wyre | I'm not sure also what kernel version would be more appropriate to boot in less than 128MB | 09:48 |
| *** MauroAnjo <MauroAnjo!~MauroAnjo@191.13.251.42> has joined #yocto | 09:48 | |
| qschulz | wyre: well, aren't you using a specific kernel in your pyro build? start by using this one? | 09:48 |
| wyre | I don't know even if would be possible to build newer versions to make them bootable with this low DRAM availability | 09:49 |
| qschulz | JosefHolzmayrThe: indeed, just disable all the warnings turned into errors and it's fine :D | 09:49 |
| * JosefHolzmayrThe has just kicked off poky master and will likely boot it on low memory in a few minutes. | 09:49 | |
| qschulz | JosefHolzmayrThe: if it does not work, you probably want to lower the amount of memory allocated to CMA | 09:49 |
| wyre | Do you think could I do what I've suggested? | 09:50 |
| JosefHolzmayrThe | qschulz: nope. there was a time when the kernel actually did magic depending on the reported version string by gcc and would fall over | 09:50 |
| qschulz | there's a config for it or I think passing cma=16MB or similar should help | 09:50 |
| wyre | qschulz, just to do what I've said? | 09:51 |
| qschulz | JosefHolzmayrThe: yeah, there's a reason I hate working with vendor kernels :) | 09:51 |
| qschulz | wyre: my last remark was for JosefHolzmayrThe | 09:51 |
| JosefHolzmayrThe | qschulz: thats what i meant with "preconditions" | 09:51 |
| qschulz | yeah good point | 09:51 |
| qschulz | I mean... at one point it might even make more sense to build the kernel by yourself outside of Yocto then :p | 09:52 |
| JosefHolzmayrThe | qschulz: heh yeah | 09:53 |
| *** mariusz <mariusz!~mariusz@185.241.198.130> has quit IRC (Ping timeout: 256 seconds) | 09:54 | |
| wyre | qschulz, this is the kernel recipe I'm using to build dunfell on my MACHINE https://bpa.st/PIOQ | 09:56 |
| wyre | do 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 |
| qschulz | wyre: see points raised by JosefHolzmayrThe | 09:57 |
| wyre | upss ... no, they just have branches for 5.4 and 5.10 | 09:58 |
| qschulz | but who does not try does not know | 09:58 |
| wyre | I probably will have to use the pyro kernel 😥 | 09:58 |
| ykrons | Hello, 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 |
| qschulz | wyre: there's no pyro kernel! | 09:59 |
| wyre | qschulz, sure, I know | 09:59 |
| wyre | in fact is an Engicam's kernel | 10:00 |
| wyre | I meant the kernel version Engicam's using in their BSP to build pyro | 10:00 |
| qschulz | the 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 it | 10:00 |
| wyre | I guess that's what you meant when you talked about vendor kernels | 10:00 |
| qschulz | I build a 4.4 kernel on Dunfell for example | 10:00 |
| JosefHolzmayrThe | wyre: when can we actually invoice you or engicam? | 10:00 |
| *** davidinux <davidinux!~davidinux@84.17.59.176> has quit IRC (Ping timeout: 260 seconds) | 10:11 | |
| *** davidinux <davidinux!~davidinux@net-109-116-25-69.cust.vodafonedsl.it> has joined #yocto | 10:13 | |
| *** sstiller <sstiller!~sstiller@p200300f07f14db00a560f18507e43f8b.dip0.t-ipconnect.de> has joined #yocto | 10:16 | |
| RP | "tar (child): zstd: Cannot exec: No such file or directory" - why would a previously fine autobuilder worker do that :/ | 10:17 |
| rburton | rfs613: the pydevshell (or devpyshell, can't remember) gives you a python interactive shell, where you can do d.expand("${bindir}") iirc | 10:18 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:21 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 268 seconds) | 10:25 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 10:25 | |
| qschulz | RP: I don't know, same question as to why I have pseudo aborts when I don't pass --tmpfs /tmp to containers | 10:27 |
| RP | qschulz: what does pseudo.log say? | 10:28 |
| qschulz | tlwoerner: 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 |
| qschulz | RP: path mismatch | 10:28 |
| JosefHolzmayrThe | wyre: 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 |
| qschulz | hmw[m]: meta/recipes-multimedia is not a layer | 10:31 |
| RP | qschulz: right, but which path. Can you share the exact log message please? | 10:31 |
| JosefHolzmayrThe | hmw: 1) meta-multimedia is a part of meta-openembedded 2) make sure all layers are on the same release. | 10:32 |
| wyre | JosefHolzmayrThe, I'm assuming you aren't using a specific vendor kernel, right? | 10:32 |
| RP | qschulz: Was that with containers? | 10:32 |
| qschulz | RP: /tmp paths I don't think I have the logs anymore but it shouldn't take too long | 10:32 |
| qschulz | RP: yes | 10:32 |
| JosefHolzmayrThe | wyre: standard poky | 10:32 |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4d01:ef00:24d7:51ff:fed6:906d> has joined #yocto | 10:33 | |
| qschulz | hmw[m]: https://layers.openembedded.org/layerindex/branch/master/layer/meta-multimedia/ | 10:33 |
| RP | qschulz: I have a feeling inodes are being deleted outside the container and confusing things | 10:33 |
| qschulz | RP: but /tmp isn't mounted without --tmpfs /tmp so I'm quite confused what could be happening | 10:34 |
| wyre | JosefHolzmayrThe, so this problem with memory allocation must be in this 5.4.70 version of the kernel from Engicam https://github.com/engicam-stable/linux-engicam-nxp | 10:34 |
| wyre | right? | 10:34 |
| JosefHolzmayrThe | wyre: like i said, when can we invoice you or engicam? | 10:35 |
| qschulz | wyre: vendors usually allocate WAY too much memory for graphic stuff, just to make sure they never have customers hitting weird issues | 10:35 |
| wyre | I didn't know you were here to make money, JosefHolzmayrThe 😆 | 10:35 |
| JosefHolzmayrThe | wyre: they sell hardware, they get the money. and you're probably not doing this for fun too. | 10:35 |
| qschulz | so I wouldn't be surprised it's just a configuration thing | 10:35 |
| wyre | qschulz, but could I change this memory allocation by modifying build params for the kernel? 🤔 | 10:35 |
| wyre | JosefHolzmayrThe, well, I so keen on Yocto actually, I like so much the project 😊 | 10:36 |
| JosefHolzmayrThe | wyre: 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 |
| qschulz | wyre: 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 |
| wyre | sure qschulz I know that and I'm so grateful to you because all of your help | 10:37 |
| wyre | you are helping me a lot to understand how this environment works | 10:37 |
| qschulz | wyre: 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 using | 10:37 |
| JosefHolzmayrThe | wyre: 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 |
| qschulz | but 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 |
| qschulz | JosefHolzmayrThe: stop saying the same things ugh :p | 10:38 |
| JosefHolzmayrThe | qschulz: no probem. I'll stop saying and resort to typing, mkay? | 10:39 |
| wyre | well, anyway thank you very much, because you give me a few researching lines 😊 | 10:39 |
| qschulz | wyre: our pleasure, good luck :) | 10:40 |
| *** davidinux <davidinux!~davidinux@net-109-116-25-69.cust.vodafonedsl.it> has quit IRC (Ping timeout: 250 seconds) | 10:40 | |
| RP | qschulz: what is /tmp in that case instead? part of the container rootfs? | 10:41 |
| qschulz | yes | 10:42 |
| *** davidinux <davidinux!~davidinux@217.138.197.53> has joined #yocto | 10:42 | |
| hmw[m] | Josef Holzmayr (TheYoctoJester): qschulz : tnx i was missing it in the bblayer file | 10:44 |
| qschulz | hmw[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 | |
| qschulz | RP: if that matters in any way, I'm using rootless podman for the machine that failed with pseudo aborts | 11:02 |
| qschulz | which AFAICT is using fuse-overlayfs? (podman 3.0.1 + 5.10.x kernel on a debian bullseye) | 11:04 |
| *** creich <creich!~creich@p200300f6af26f81023f87188c6a7c918.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection) | 11:07 | |
| ykrons | Anyone could help about the (= ${variable}) syntax ? I can't find explaination in bitbake and yocto documentation | 11:08 |
| rburton | ykrons: got an example? | 11:13 |
| rburton | do you mean in RDEPENDS? | 11:13 |
| rburton | if so then https://docs.yoctoproject.org/ref-manual/variables.html#term-RDEPENDS | 11:14 |
| RP | qschulz: I suspect something odd with the filesystem stuff, overlayfs is a nightmare with pseudo :( | 11:14 |
| ykrons | rburton: Yes it is RDEPENDS related: RDEPENDS_${PN}-dev = "avahi-daemon (= ${EXTENDPKGV}) libavahi-core (= ${EXTENDPKGV})" | 11:16 |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 250 seconds) | 11:17 | |
| ykrons | rburton: thanks for the link, I have a look | 11:17 |
| *** MauroAnjo <MauroAnjo!~MauroAnjo@191.13.251.42> has quit IRC (Quit: Client closed) | 11:18 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 11:18 | |
| *** otavio_ <otavio_!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Remote host closed the connection) | 11:20 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 11:22 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 250 seconds) | 11:22 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has quit IRC (Ping timeout: 260 seconds) | 11:23 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 11:23 | |
| rburton | that's just saying that avahi-dev depends on avah-daemon of the exact version, so they get upgraded in unison | 11:29 |
| *** bps <bps!~bps@27-reverse.bang-olufsen.dk> has joined #yocto | 11:50 | |
| RP | ykrons: the version constraints effectively get passed to the package managers like opkg/dpkg/rpm | 11:50 |
| *** tre <tre!~tre@ip5f588487.dynamic.kabel-deutschland.de> has joined #yocto | 11:55 | |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 260 seconds) | 11:55 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 250 seconds) | 11:58 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 11:59 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has joined #yocto | 12:04 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 260 seconds) | 12:04 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 12:04 | |
| *** pbergin_ <pbergin_!~pbergin@80.252.208.151> has joined #yocto | 12:09 | |
| *** pbergin <pbergin!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has quit IRC (Ping timeout: 260 seconds) | 12:12 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 260 seconds) | 12:14 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 12:14 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 12:27 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 250 seconds) | 12:29 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 12:29 | |
| qschulz | RP: yeah that would be my guess too. Don't have any more ideas though :/ | 12:30 |
| tlwoerner | qschulz: i'll look at them today, thanks! | 12:35 |
| *** adrian_ <adrian_!~F_Adrian@165.225.27.24> has joined #yocto | 12:36 | |
| qschulz | tlwoerner: 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@62.32.0.69> has quit IRC (Ping timeout: 250 seconds) | 12:38 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 12:41 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> 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 |
| rburton | when run as a service you'll have less environment variables set (as its not an interactive login), and no TTYs connected | 12:48 |
| rburton | so most likely one of those, and really most likely the environment | 12: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 |
| rburton | you can set the user to run as, and set any environment | 12:49 |
| rburton | dont' think you can fake a login though | 12:49 |
| ykrons | I'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 |
| ykrons | Is 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 you | 12:53 |
| perdmann_ | rburton: it is an Qualcomm delivery. Its awful | 12:53 |
| ykrons | And 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 https://libera.ems.host/_matrix/media/r0/download/libera.chat/ebdc8ffe0420901916653d9889ec436a7fc8b1c7) | 12:59 |
| *** geoffhp60 <geoffhp60!~geoffhp@cpe-107-185-48-203.socal.res.rr.com> has quit IRC (Quit: Client closed) | 12:59 | |
| qschulz | coldspark29[m]: the container is spawned only when bitbake is running | 13:01 |
| coldspark29[m] | Okay cool | 13:01 |
| coldspark29[m] | But why can't I run bitbake? | 13:01 |
| qschulz | but you can? | 13:02 |
| qschulz | because otherwise you wouldn't have this error | 13:02 |
| coldspark29[m] | Well yes | 13:02 |
| qschulz | just a "bitbake not found" from your distro | 13: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 directory | 13:02 |
| qschulz | the directory where the layers are should be mounted in your container | 13:03 |
| coldspark29[m] | I thought everything would be set up automatically using the quick start guide | 13:05 |
| qschulz | PYREX_BIND should be set, I don't know if it defaults to $(pwd) or not | 13:05 |
| JPEW | coldspark29[m]: if you don't have the exact layout as the quick start, you have to tweak it a little | 13:06 |
| coldspark29[m] | PYREX_CONFIG_BIND=/home/user/Workspace/Yocto-Workspace/Test-Workspace/poky | 13:06 |
| coldspark29[m] | That one? | 13:06 |
| JPEW | It's really hard to guess all the little variations people might have | 13:06 |
| JPEW | Also, the container only runs while bitbake is running | 13:08 |
| qschulz | JPEW: 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 README.md README.poky.md scripts | 13:09 |
| coldspark29[m] | build documentation LICENSE.GPL-2.0-only MAINTAINERS.md MEMORIAM meta-poky meta-selftest meta-yocto-bsp pyrex-init-build-env README.hardware.md README.OE-Core.md README.qemu.md | 13: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 guide | 13:09 |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4d01:ef00:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection) | 13:10 | |
| JPEW | Your bblayers.conf file is referencing the wrong paths | 13:10 |
| JPEW | You want /home/claussenj instead of /home/yocto | 13:11 |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 13:11 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4d01:ef00:24d7:51ff:fed6:906d> has joined #yocto | 13:11 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 13:12 | |
| coldspark29[m] | Ah yeah, I downloaded poky with another container. That's why | 13: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 guess | 13:15 |
| JPEW | Depends. If you don't already use a container, it shouldn't be too bad | 13: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 mean | 13:20 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds) | 13:21 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 13:21 | |
| coldspark29[m] | Because we work with repo and would lose all those folder when syncing I guess | 13:22 |
| JPEW | coldspark29[m]: do you mean meta-pyrex? | 13:24 |
| *** davidinux <davidinux!~davidinux@217.138.197.53> has quit IRC (Ping timeout: 250 seconds) | 13:25 | |
| JPEW | You 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 etc | 13:26 |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 13:26 | |
| *** pbergin__ <pbergin__!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has joined #yocto | 13:26 | |
| *** davidinux <davidinux!~davidinux@net-109-116-25-69.cust.vodafonedsl.it> has joined #yocto | 13:27 | |
| *** pbergin_ <pbergin_!~pbergin@80.252.208.151> has quit IRC (Ping timeout: 260 seconds) | 13:27 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 268 seconds) | 13:34 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 13:35 | |
| *** tre <tre!~tre@ip5f588487.dynamic.kabel-deutschland.de> 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 15 | 13:47 |
| rburton | SIGTERM 15 15 15 15 | 13:48 |
| rburton | it gets killed | 13:48 |
| rburton | slap a gdb on it | 13:49 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 268 seconds) | 13:50 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:56 | |
| *** dacav <dacav!~dacav@h94-245-9-196.cust.a3fiber.se> has joined #yocto | 14: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@89.244.121.8> has quit IRC (Ping timeout: 260 seconds) | 14:18 | |
| JPEW | coldspark29[m]: Ya, the idea is since only bitbake runs in a container, they can still use their editor of choice in the host | 14:18 |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 14: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 actually | 14:21 |
| dacav | Hi. 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 them | 14:21 |
| coldspark29[m] | dacav: .dtsi files are included files. They are like .h files in C | 14:22 |
| coldspark29[m] | In the end the .dts and .dtsi files are all compiled into a single .dtb file | 14:22 |
| dacav | I'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 |
| dacav | I could not find this info in the specification | 14:23 |
| qschulz | dacav: yes | 14:23 |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 268 seconds) | 14:23 | |
| qschulz | everything redeclared is merged | 14:24 |
| coldspark29[m] | I am not sure about that. Also pretty new here. | 14:24 |
| qschulz | and it's merged in the order in which it is included | 14:25 |
| qschulz | so if you have a property that is redeclared multiple times (e.g. "status") | 14:25 |
| qschulz | the last included dtsi or the final dts has the last word | 14:26 |
| qschulz | otherwise, just do you tests yourself and then use `dtc -I dtb -O dts my.dtb` | 14:26 |
| qschulz | phandles won't be in the human form but most of it should be readable | 14:27 |
| qschulz | human readable form obviously :) | 14:27 |
| *** codavi <codavi!~akiCA@user/akica> has joined #yocto | 14:28 | |
| *** ar__ <ar__!~akiCA@user/akica> has joined #yocto | 14:30 | |
| *** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 268 seconds) | 14:33 | |
| *** manuel_ <manuel_!~manuel198@185.68.248.44> has quit IRC (Ping timeout: 250 seconds) | 14:33 | |
| *** kayterina <kayterina!~kayterina@62.38.55.161> has joined #yocto | 14:37 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 14:38 | |
| qschulz | mmmm damn opengl :/ | 14:39 |
| qschulz | so 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 only | 14:39 |
| qschulz | kmscube (a mesa project) includes gl3ext.h and therefore breaks projects where only gl2ext.h is provided, e.g. rockchip's libmali | 14:40 |
| qschulz | so I don't know what to do :) | 14:40 |
| qschulz | oh, and most important piece of information. The gl{2,3}ext.h file is empty. | 14:41 |
| dacav | Another question (Q2): is the SRC_URL per-recipe, or per-layer? | 14:42 |
| qschulz | dacav: not sure to see what the use case would be for a per-layer SRC_URI | 14:43 |
| qschulz | it's per-recipe | 14:43 |
| qschulz | actually, it's gl3ext.h from mesa that is empty, gl2ext.h is not | 14:44 |
| qschulz | ok nevermind, I was looking for gl2ext.h in include/GLES3 | 14:45 |
| qschulz | tgif | 14:45 |
| *** maoti__ <maoti__!~maoti@99-14-97-149.lightspeed.frokca.sbcglobal.net> has joined #yocto | 14:46 | |
| *** jpuhlman_ <jpuhlman_!~maoti@99-14-97-149.lightspeed.frokca.sbcglobal.net> has quit IRC (Ping timeout: 265 seconds) | 14:50 | |
| qschulz | mmmm, are circular RDEPENDS possible? | 14:55 |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 260 seconds) | 15:09 | |
| *** davidinux <davidinux!~davidinux@net-109-116-25-69.cust.vodafonedsl.it> has quit IRC (Quit: WeeChat 2.8) | 15:09 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 15:10 | |
| rburton | if you install them both at the same time, sure | 15:10 |
| rburton | terrible idea though | 15:10 |
| qschulz | it's related to my monologue above | 15:11 |
| qschulz | basically, I think libgles3-dev should RDEPENDS on libgles2-dev to have include/GLES2/gl2ext.h available | 15:11 |
| qschulz | however, mesa already has an RDEPENDS:mesa-ligles2-dev = "mesa-ligles3-dev" though I couldn't really make sense of the reason for this | 15:12 |
| *** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has quit IRC (Remote host closed the connection) | 15:13 | |
| *** davidinux <davidinux!~davidinux@84.17.59.156> has joined #yocto | 15:15 | |
| kanavin | qschulz, pressure your vendor to ditch the blob :) | 15:16 |
| kanavin | there are mali drivers in mesa | 15:16 |
| *** marc1 <marc1!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has joined #yocto | 15:18 | |
| qschulz | kanavin: the issue here being that mesa itself does not follow the specs | 15:22 |
| qschulz | but my vendor does :) | 15:22 |
| qschulz | well, not mesa, kmscube | 15:24 |
| qschulz | and mesa provides a file that shouldn't be here | 15:24 |
| qschulz | which kmscube includes but shouldn't | 15:24 |
| JPEW | qschulz: 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 spent | 15:24 |
| qschulz | (see patches on the ML) | 15:24 |
| qschulz | JPEW: I've to check if Panfrost supports the Rockchip PX30 in some way | 15:25 |
| qschulz | but that does not solve an actual issue in Yocto/kmscube/mesa | 15:25 |
| JPEW | qschulz: 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 |
| qschulz | seems like it has a Mali G31 | 15:27 |
| qschulz | and https://docs.mesa3d.org/drivers/panfrost.html says it's a go | 15:27 |
| qschulz | but.. don't know if it's well supported in 5.4 :/ | 15:27 |
| JPEW | qschulz: Ah, we had a T-720 | 15:27 |
| qschulz | though they say it's non-conformant.. | 15:28 |
| dacav | self-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 |
| qschulz | JPEW: 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 |
| qschulz | dacav: I answered you an hour ago | 15:30 |
| qschulz | (also, it's SRC_URI and not SRC_URL :) ) | 15:31 |
| qschulz | dacav: but good use of bitbake -e :) | 15:31 |
| JPEW | qschulz: It does depend on the GPU, but in my expirence Panfrost is miles ahead of the vendor blobs when it comes to featyres | 15:31 |
| JPEW | qschulz: It basically gets all the mesa features, and has the same (or maybe even better) performance | 15:32 |
| JPEW | We _had_ to switch because we needed some Wayland support the vendor blob just couldn't do | 15:32 |
| qschulz | JPEW: yeah, will think about it, quite difficult to make a client do such a big change during the life cycle of a product I think | 15:33 |
| JPEW | qschulz: 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 implement | 15:34 |
| qschulz | JPEW: 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 |
| qschulz | s/couraadventurousnough/adventurous enough/ | 15:37 |
| qschulz | will think of it when (if) we do a big jump between 5.4 and the next (next?) LTS | 15:38 |
| qschulz | JPEW: thanks for the feedback :) | 15:39 |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has joined #yocto | 15:52 | |
| kayterina | hello. 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!~sstiller@p200300f07f14db00a560f18507e43f8b.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving) | 16:08 | |
| qschulz | kayterina: 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 support | 16:10 |
| qschulz | for how to keep them in sync, there's nothing implemented in Yocto, you'll have to use a 3rd party tool | 16:10 |
| qschulz | some people use repo, git submodules too I assume, and some others use kas (github.com/siemens/kas) | 16:11 |
| qschulz | also, the commit hash of each layer is printed when bitbake starts so you can always check that manually to see if something's off | 16:11 |
| kayterina | a,yes I found .gitmodules. So this line "branch = zeus-patched" keeps poky at the same version? | 16:12 |
| qschulz | I 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 #yocto | 16:12 | |
| kayterina | ok thanks | 16:13 |
| JPEW | kayterina: 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 data | 16:23 |
| JPEW | If the submodule isn't at the correct SHA-1, `git status` will show it as modified | 16:25 |
| kayterina | there is a /.git/modules/sources/poky/HEAD, is that the SHA? | 16:27 |
| JPEW | kayterina: I beleive that is the current SHA-1 that is checked out, same as you would get from `git rev-parse HEAD` in the submodule | 16:29 |
| JPEW | kayterina: But... you really shouldn't poke around in the .git directory for anything; there are commands to tell you what you want to know | 16:29 |
| JPEW | kayterina: https://git-scm.com/book/en/v2/Git-Tools-Submodules may be helpful | 16:30 |
| t_unix[m] | is there a CLI formatting tool for bitbake recipes? | 16:30 |
| *** Tokamak <Tokamak!~Tokamak@172.58.191.126> has quit IRC (Read error: Connection reset by peer) | 16:33 | |
| *** kayterina <kayterina!~kayterina@62.38.55.161> has quit IRC (Read error: Connection reset by peer) | 16:38 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.191.126> has joined #yocto | 16:39 | |
| RP | JPEW: did you have a patch in mind to simplify the bitbake parser feeder process usage? | 16:47 |
| JPEW | RP: 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!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 16:49 | |
| RP | JPEW: we have a feeder thread in the parsing code in cooker.py. 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 it | 16:51 |
| RP | I've just been pondering whether asyncio would help cooker and the bitbake server code. Jury is still out on that :/ | 16:52 |
| JPEW | Ah, that sounds familiar. Let me look.... | 16:52 |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 268 seconds) | 16:54 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 16:55 | |
| JPEW | RP: poky-contrib cgit seems to not be updated, but is 153ebe3ade191b6cb99f7aae07e2766c317b03b4 in poky-contrib what you were thinking of? | 17:02 |
| RP | JPEW: yes, that looks like it! | 17:03 |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 268 seconds) | 17:04 | |
| JPEW | RP: FYI I *just* rebased it, so I don't know if it works just yet | 17:04 |
| RP | JPEW: I was looking at the exception handling and wondering if that was right :) | 17:04 |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 17:05 | |
| RP | would certainly be nice to clean that up if we can | 17:05 |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Remote host closed the connection) | 17:10 | |
| JPEW | Which exception handling? | 17:11 |
| rburton | RP: 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 |
| RP | JPEW: Looking more closely I think it is fine | 17:12 |
| RP | rburton: probably | 17:12 |
| rburton | <cough> for no reason | 17:12 |
| RP | rburton: I have a good imagination :/ | 17:12 |
| rburton | awwww pypy's os module isn't identical to standard py | 17:13 |
| *** dev1990 <dev1990!~dev@dynamic-78-8-166-98.ssp.dialog.net.pl> has joined #yocto | 17:13 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 250 seconds) | 17:13 | |
| JPEW | RP: Ah, the old ParserFailure wrapping? Ya that's unnecessary now. multiprocessing does a better job passing the execeptions back to the parent | 17:14 |
| RP | JPEW: right, it makes sense when you step back | 17:14 |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 17:14 | |
| *** geoffhp <geoffhp!~Geoff@cpe-107-185-48-203.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 17:20 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 17:24 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.191.126> has quit IRC (Read error: Connection reset by peer) | 17:24 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 250 seconds) | 17:28 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has joined #yocto | 17:29 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.191.126> has joined #yocto | 17:30 | |
| *** camus <camus!~Instantbi@2409:8a1e:911a:6f50:7def:ceaf:df3d:f0f0> has joined #yocto | 17:31 | |
| *** zpfvo <zpfvo!~fvo@89.244.121.8> has quit IRC (Ping timeout: 240 seconds) | 17:34 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-166-98.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!) | 17:37 | |
| *** geoffhp <geoffhp!~geoff@cpe-107-185-48-203.socal.res.rr.com> has joined #yocto | 17: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 #yocto | 17:58 | |
| kergoth | t_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, etc | 18:02 |
| kergoth | A simple one that just corrects indentation and whatnot would be easy enough, and oe-stylize does exist but has flaws | 18:03 |
| kergoth | Ideally I think we could implement reordering using our knowledge of variable dependencies, at least within sections delinated by inherits.. hmm | 18:03 |
| kergoth | Now to test lima+nerdctl for yocto builds on my macbook | 18:04 |
| kergoth | (unrelated) | 18:04 |
| kergoth | RP, 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 |
| kergoth | OT, but anyone know offhand if we require a python version that supports f-strings yet? | 18:05 |
| *** florian <florian!~florian@dynamic-002-244-158-155.2.244.pool.telefonica.de> has joined #yocto | 18:10 | |
| rfs613 | when 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 |
| kergoth | Fair enough, your best bet about that sort of thing is to check oe-core's scripts dir, particularly scripts/contrib | 18:19 |
| *** mariusz <mariusz!~mariusz@185.241.198.130> has joined #yocto | 18:28 | |
| *** florian <florian!~florian@dynamic-002-244-158-155.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds) | 18:28 | |
| JPEW | kergoth: python is new enough, but I think we are holding off on using fstrings just yet so that backports are still possible | 18:29 |
| *** mariusz <mariusz!~mariusz@185.241.198.130> has quit IRC (Ping timeout: 260 seconds) | 18:33 | |
| kergoth | Ah, makes sense. | 18:38 |
| kergoth | They 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!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 18:47 | |
| kroon | qschulz, ping | 18:47 |
| fray | I didn't mind '%' format.. but I always hated str.format(...) | 19:03 |
| fray | the new f-string format (hadn't seen it before) seems reasonable though | 19:03 |
| JPEW | RP: 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 things | 19:17 |
| JPEW | It 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 place | 19:19 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC (Quit: Leaving) | 19:24 | |
| *** xantoz <xantoz!~tewi_inab@c-c0bae255.013-124-73746f25.bbcust.telenor.se> has quit IRC (Ping timeout: 265 seconds) | 19:30 | |
| *** aduskett <aduskett!~aduskett@47.149.13.137> has joined #yocto | 20:19 | |
| aduskett | Hello, 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@165.225.27.14> has joined #yocto | 20:30 | |
| RP | JPEW: I wasn't thinking about parsing, more about the server and command processing and handling the different data read/writes | 20:30 |
| RP | JPEW: looking at the code I was reminded about the parsing change | 20:30 |
| *** adrian_ <adrian_!~F_Adrian@165.225.27.24> has quit IRC (Ping timeout: 250 seconds) | 20:32 | |
| *** adrian__ <adrian__!~F_Adrian@165.225.27.14> 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!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 20:54 | |
| rburton | kergoth: have you tried using lima on macos to do a yocto build? | 21:00 |
| kergoth | I 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 permissions | 21:01 |
| rburton | i was guessing that would be the problem | 21:02 |
| rburton | i've done a build in a vm on my m1 mbp and was quite impressed | 21:02 |
| kergoth | I usually like to use bind mounts to make the docker usage transparent, but not workable on the mac | 21:02 |
| kergoth | nice | 21:02 |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 21:03 | |
| kergoth | I'm hopeful that lima moves in the qemu+9p direction or so | 21:03 |
| rburton | yeah, they said that in the readme | 21:03 |
| kergoth | lima is really nice in general. easy use of nerdctl or podman is convenient | 21:03 |
| rburton | lima looks a lot more like my style than parallels | 21:03 |
| kergoth | yeah, it's like wsl basically.. | 21:03 |
| kergoth | Ugh, can't leave the layers in an rw bind mount either, it needs to write pyshtables.py 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 |
| kergoth | docker for desktop might have license issues, but it certainly avoided these issues | 21:08 |
| kergoth | I'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 all | 21:09 |
| JPEW | RP: Can you really get a data stream to bitbake-worker that looks like "<foo>A</foo>B</foo>"? | 21:11 |
| JPEW | It's certianlly written to handle that :/ | 21:11 |
| RP | JPEW: 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 |
| JPEW | Ya, but the deserializing code will keep looping looking for "</foo>" and handling it... looks like some strange leftover | 21:20 |
| RP | JPEW: I don't remember. It could well be some kind of leftover | 21:26 |
| rfs613 | rburton: thanks for the tip about 'devpyshell', very handy. | 21:27 |
| kergoth | rburton: 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!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has quit IRC (Quit: Client closed) | 22:17 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has joined #yocto | 22:18 | |
| *** florian <florian!~florian@dynamic-002-244-158-155.2.244.pool.telefonica.de> has joined #yocto | 22:18 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Quit: Leaving.) | 22:21 | |
| *** pbergin__ <pbergin__!~pbergin@ua-213-113-157-96.bbcust.telenor.se> has quit IRC (Ping timeout: 250 seconds) | 22:27 | |
| kergoth | Hmm, wonder if there's a way to share data between lima instances without going through the host | 22:32 |
| *** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 250 seconds) | 22:49 | |
| kergoth | Works pretty well without containers in the mix. Here's hoping that sshfs issue gets fixed eventually for that piece | 22:53 |
| *** mischief2 is now known as mischief | 23:09 | |
| *** mischief <mischief!~mischief@wopr.sciops.net> has quit IRC (Quit: WeeChat 3.3) | 23:14 | |
| *** mischief <mischief!~mischief@wopr.sciops.net> has joined #yocto | 23:14 | |
| *** florian <florian!~florian@dynamic-002-244-158-155.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 23:31 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!