| *** florian <florian!~florian@dynamic-093-135-029-167.93.135.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds) | 00:00 | |
| *** malsyned <malsyned!~IceChat95@c-66-31-16-167.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 256 seconds) | 00:08 | |
| *** yocti <yocti!~limnoria@mail.yoctoproject.org> has joined #yocto | 01:09 | |
| *** ChanServ sets mode: +o yocti | 01:09 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 01:16 | |
| *** money_ <money_!~money@user/polo> has quit IRC (Quit: money_) | 01:32 | |
| khem | Canonical has written a whitepaper comparing ubuntu-core and yocto addressing CTOs - https://canonical.foleon.com/whitepapers/yocto-vs-ubuntu-core/?utm_source=takeover&utm_medium=takeover&utm_campaign=7014K000000QEbvQAG | 01:37 |
|---|---|---|
| khem | we must be doing something right 🙂 | 01:37 |
| *** starblue <starblue!~juergen@dslb-094-220-119-150.094.220.pools.vodafone-ip.de> has quit IRC (Ping timeout: 256 seconds) | 02:13 | |
| *** starblue <starblue!~juergen@dslb-088-078-102-232.088.078.pools.vodafone-ip.de> has joined #yocto | 02:15 | |
| *** rber|res <rber|res!~rber|res@62-46-92-242.adsl.highway.telekom.at> has joined #yocto | 02:32 | |
| *** RobertBerger <RobertBerger!~rber|res@62-46-92-242.adsl.highway.telekom.at> has quit IRC (Ping timeout: 252 seconds) | 02:34 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 02:40 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:651b:dd00:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 260 seconds) | 03:20 | |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection) | 03:21 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:650f:ef00:2ce:39ff:fecf:efcd> has joined #yocto | 03:21 | |
| *** camus <camus!~Instantbi@183.192.143.194> has joined #yocto | 03:22 | |
| *** yocti` <yocti`!~limnoria@mail.yoctoproject.org> has joined #yocto | 03:29 | |
| *** yocti <yocti!~limnoria@mail.yoctoproject.org> has quit IRC (Killed (NickServ (GHOST command used by yocti`))) | 03:29 | |
| *** bantu_ <bantu_!~bantu@edna.bantux.com> has joined #yocto | 03:30 | |
| *** yocti` is now known as yocti | 03:30 | |
| *** ChanServ sets mode: +o yocti | 03:30 | |
| *** starblue1 <starblue1!~juergen@dslb-088-078-102-232.088.078.pools.vodafone-ip.de> has joined #yocto | 03:31 | |
| *** Net147_ <Net147_!~Net147@167-179-157-192.a7b39d.syd.nbn.aussiebb.net> has joined #yocto | 03:32 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 03:32 | |
| *** Tokamak__ <Tokamak__!~Tokamak@172.58.242.20> has joined #yocto | 03:34 | |
| *** georgem <georgem!sid210681@id-210681.tinside.irccloud.com> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** camus <camus!~Instantbi@183.192.143.194> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** Net147 <Net147!~Net147@user/net147> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** pabigot <pabigot!~pab@67-1-115-166.tcso.qwest.net> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** georgem_ is now known as georgem | 03:34 | |
| *** starblue <starblue!~juergen@dslb-088-078-102-232.088.078.pools.vodafone-ip.de> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** Wouter01006 <Wouter01006!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** invalidopcode <invalidopcode!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** Tokamak_ <Tokamak_!~Tokamak@172.58.242.20> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** gsalazar <gsalazar!~gsalazar@139.0.166.178.rev.vodafone.pt> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** yann <yann!~yann@88.120.44.86> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** vmeson <vmeson!~rmacleod@23-233-86-175.cpe.pppoe.ca> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** jmk1 <jmk1!~jmk1@lcs07-lyo-176-188-208-171.sfr.lns.abo.bbox.fr> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** bantu <bantu!~bantu@edna.bantux.com> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** dkl <dkl!~dkl@prometheus.umask.eu> has quit IRC (Ping timeout: 256 seconds) | 03:34 | |
| *** invalidopcode7 is now known as invalidopcode | 03:34 | |
| *** camus1 is now known as camus | 03:34 | |
| *** Wouter010067 is now known as Wouter01006 | 03:34 | |
| *** vmeson <vmeson!~rmacleod@23-233-86-175.cpe.pppoe.ca> has joined #yocto | 03:35 | |
| *** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has joined #yocto | 03:37 | |
| *** yann <yann!~yann@88.120.44.86> has joined #yocto | 03:43 | |
| *** pabigot <pabigot!~pab@67-1-115-166.tcso.qwest.net> has joined #yocto | 03:43 | |
| *** nate02 <nate02!~nathani@d75-157-113-180.bchsia.telus.net> has joined #yocto | 03:57 | |
| *** nathani <nathani!~nathani@d23-16-151-55.bchsia.telus.net> has quit IRC (Ping timeout: 264 seconds) | 04:02 | |
| *** warthog19 <warthog19!warthog9@proxy.monkeyblade.net> has joined #yocto | 04:07 | |
| *** alicef_ <alicef_!~none@gentoo/developer/alicef> has quit IRC (Quit: install gentoo) | 04:31 | |
| *** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto | 04:34 | |
| *** sgw <sgw!~swold_loc@user/sgw> has quit IRC (Ping timeout: 268 seconds) | 04:56 | |
| *** Wouter01006 <Wouter01006!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 05:10 | |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 05:10 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has quit IRC (Ping timeout: 255 seconds) | 05:29 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 05:29 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 252 seconds) | 05:34 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has joined #yocto | 05:34 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 05:45 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Ping timeout: 256 seconds) | 06:10 | |
| *** olani <olani!~olani@83-233-29-230.cust.bredband2.com> has quit IRC (Ping timeout: 248 seconds) | 06:19 | |
| *** money_ <money_!~money@user/polo> has joined #yocto | 06:19 | |
| *** money_ <money_!~money@user/polo> has quit IRC (Ping timeout: 256 seconds) | 06:26 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Read error: Connection reset by peer) | 06:36 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 246 seconds) | 06:59 | |
| *** manuel <manuel!~manuel198@2a02:1748:dd5c:f290:c553:9012:6082:a89a> has quit IRC (Ping timeout: 265 seconds) | 07:00 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 260 seconds) | 07:00 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 07:05 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 07:07 | |
| *** sgw <sgw!~swold_loc@user/sgw> has joined #yocto | 07:09 | |
| *** rob_w <rob_w!~rob@2001:a61:61c1:9001:85d4:9b1b:a383:66fa> has joined #yocto | 07:11 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Remote host closed the connection) | 07:17 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 07:17 | |
| *** sgw <sgw!~swold_loc@user/sgw> has quit IRC (Quit: Leaving.) | 07:22 | |
| *** sgw <sgw!~swold_loc@user/sgw> has joined #yocto | 07:23 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Remote host closed the connection) | 07:24 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 07:24 | |
| LetoThe2nd | yo dudX | 07:29 |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Remote host closed the connection) | 07:32 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 07:32 | |
| *** sgw <sgw!~swold_loc@user/sgw> has quit IRC (Quit: Leaving.) | 07:37 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Remote host closed the connection) | 07:40 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 07:40 | |
| *** rob_w <rob_w!~rob@2001:a61:61c1:9001:85d4:9b1b:a383:66fa> has quit IRC (Read error: Connection reset by peer) | 07:44 | |
| *** thomas_ <thomas_!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 07:45 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Ping timeout: 248 seconds) | 07:46 | |
| *** thomas_ <thomas_!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Read error: Connection reset by peer) | 07:49 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 07:49 | |
| *** nate02 <nate02!~nathani@d75-157-113-180.bchsia.telus.net> has quit IRC (Ping timeout: 256 seconds) | 07:50 | |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 07:50 | |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 07:50 | |
| *** nate02 <nate02!~nathani@d75-157-113-180.bchsia.telus.net> has joined #yocto | 08:02 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Remote host closed the connection) | 08:09 | |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 08:09 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 08:09 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Remote host closed the connection) | 08:11 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 08:11 | |
| mcfrisk | sigh, Linux Foundation sending too much spam about risc-v conference, stopped all email notifications from them. I guess I had the account because of yocto... | 08:12 |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Ping timeout: 265 seconds) | 08:17 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 08:35 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 08:40 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:650f:ef00:2ce:39ff:fecf:efcd> has quit IRC (Quit: WeeChat 3.7.1) | 08:40 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:650f:ef00:2ce:39ff:fecf:efcd> has joined #yocto | 08:40 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:650f:ef00:2ce:39ff:fecf:efcd> has quit IRC (Client Quit) | 08:41 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:650f:ef00:2ce:39ff:fecf:efcd> has joined #yocto | 08:41 | |
| kanavin | khem, the listed pain points are not wrong. But I'm baffled why the actual sales pitch is behind a form. | 08:52 |
| *** invalidopcode <invalidopcode!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 08:55 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 08:55 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Remote host closed the connection) | 08:59 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 08:59 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 09:01 | |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 09:01 | |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 09:02 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Remote host closed the connection) | 09:02 | |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 09:03 | |
| *** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer) | 09:07 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC (Read error: Connection reset by peer) | 09:08 | |
| neverpanic | "Some device manufacturers choose to deploy Yocto-based systems in the field." lol, some. | 09:11 |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Ping timeout: 260 seconds) | 09:11 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 09:11 | |
| kanavin | also, the whole things begs the question, why canonical won't become a yocto vendor ;) | 09:12 |
| *** amelius <amelius!~quassel@147.161.171.90> has joined #yocto | 09:17 | |
| *** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has joined #yocto | 09:17 | |
| amelius | hey, is it possible to create symlinks from dev to sys inside do_install? so something like ln -s -r ${D}/sys/class/gpio/gpio123 ${D}/dev/mygpio | 09:19 |
| ldericher | what's the cleanest way of installing a package's dependencies without installing (or even building) the package itself? | 09:22 |
| ldericher | package -> recipe | 09:22 |
| qschulz | ldericher: why would you want to do that? | 09:23 |
| *** manuel1985 <manuel1985!~manuel198@mobiledyn-62-240-134-181.mrsn.at> has joined #yocto | 09:23 | |
| qschulz | (what's the usecase) | 09:23 |
| neverpanic | kanavin: why would they? they have their own distro and want to sell you buying your upgrades from them. | 09:24 |
| ldericher | qschulz, we're developing application `foo`, which depends on `bar` and maybe rdepends on `baz`. But `foo` is in a messy state at this time, so I expect most builds of `foo` itself to fail. | 09:24 |
| neverpanic | ldericher: probably running the do_configure task, I guess? | 09:24 |
| neverpanic | s/upgrades/updates/ | 09:25 |
| ernstp | if one of my last systemd bootup services start drawing to /dev/fb0, how do I integrate that with Psplash? There seems to be a race condition in my naive setup right now... | 09:25 |
| ldericher | qschulz, Also, we might not want any `foo` to be deployed on our development-stage images. | 09:26 |
| qschulz | ldericher: I guess you could add the noexec varflag on most tasks of the foo application | 09:26 |
| *** amitk_ <amitk_!~amit@103.208.69.22> has joined #yocto | 09:26 | |
| qschulz | ldericher: development images very likely should be using a distro anyways | 09:26 |
| qschulz | but at that point, you might want to create a placeholder foo recipe which is mostly empty except the dependencies | 09:27 |
| qschulz | maybe use a virtual/package or something | 09:27 |
| qschulz | but spending time on fixing the sw/recipe might make more sense that try to have a passing build with all the dependencies except the package in question | 09:27 |
| LetoThe2nd | neverpanic: where does that "some vendors" statement come from? | 09:28 |
| ldericher | qschulz, thanks for the pointers! :) | 09:28 |
| kanavin | neverpanic, to be compatible with the industry standard, and not have to ask prospective clients to throw away their existing yocto stacks and all investment that went into them | 09:29 |
| kanavin | any resonable CTO should press them on that point :) | 09:29 |
| neverpanic | LetoThe2nd: https://canonical.foleon.com/whitepapers/yocto-vs-ubuntu-core/the-yocto-project, the rightmost box at the bottom | 09:29 |
| *** amitk <amitk!~amit@103.208.71.20> has quit IRC (Ping timeout: 260 seconds) | 09:29 | |
| LetoThe2nd | neverpanic: lol | 09:30 |
| kanavin | there's a few words about mender too :) | 09:30 |
| neverpanic | kanavin: Red Hat isn't doing that with their edge offerings either, and I guess they see that as their competition | 09:30 |
| kanavin | neverpanic, of course. Vendor lock in. | 09:30 |
| kanavin | it's perfectly doable with open source | 09:30 |
| LetoThe2nd | i lately had a good look at ubuntu core, and i'd say... it fits a couple of use cases probably but none that I have met so far ;-) | 09:30 |
| neverpanic | full disclosure: I work for Red Hat now (not on edge stuff, though) | 09:30 |
| rburton | i'm glad redhat dropped their yocto embrace-extend-kill thing | 09:32 |
| kanavin | rburton, they even deleted the repo where the whole disaster was unfolding :) | 09:32 |
| LetoThe2nd | neverpanic: i actually had an interesting call with thed edge people lately. | 09:33 |
| rburton | kanavin: https://media.giphy.com/media/13d2jHlSlxklVe/giphy.gif | 09:33 |
| neverpanic | There was an EEE thing going on? Is there a link where I can find out more about that, I honestly didn't notice. | 09:35 |
| neverpanic | Coming from automotive, I can see why somebody would choose to buy Ubuntu Core or the Red Hat Edge stuff over Yocto. I think there's a market, but it depends what your requirements are. | 09:35 |
| LetoThe2nd | kanavin: hehe, kinda feels cool to be with a small company that the big canonicals feel like required to mention and call out explicitly. | 09:36 |
| rburton | neverpanic: short lived meta-rpm layer which basically looked like oe-core but was actually rhel | 09:36 |
| neverpanic | The thing that'll kill it for the automotive market is probably pricing per unit. They really don't like that in that space. | 09:36 |
| rburton | neverpanic: the plan appeared to be 'convince automotive vendors to use AGL+meta-rpm, switch them to rhel when it breaks as it's a terrible hack' | 09:37 |
| LetoThe2nd | neverpanic: the key wisdom is: there are usecases where yocto fits, and where it does not fit. its not about bashing, its about picking the best tool for the job. see also my YPS presentation :-) | 09:37 |
| kanavin | neverpanic, first there are significant technical hurdles too. rhel needs to be reengineered from the ground up to not contain any gpl3 for starters | 09:37 |
| neverpanic | kanavin: I think the plot is to convince the automotive people that GPL-3 isn't all that bad. And if they can do that, I think that would be great. | 09:38 |
| neverpanic | But, I've been in that boat before, and it was a very leaky one and sinking quickly. | 09:38 |
| rburton | this canonical thing is literally the first time ive ever see people claim yocto is good for fast prototyping on embedded boards | 09:38 |
| kanavin | neverpanic, totally. That I fully support. | 09:38 |
| kanavin | the thing with automotive oems, the whole world is seeing their fumbles and stumbles in trying to become software companies. | 09:39 |
| kanavin | and actual software companies are smelling blood, big time. | 09:39 |
| kanavin | so they all want a piece of that massive pie. | 09:40 |
| neverpanic | I think we had discussions 7 or 8 years ago already that something similar to an Android unlocked bootloader could potentially solve the GPL-3 "problem" | 09:40 |
| rburton | very tempted to write a 'reply' to this | 09:40 |
| rburton | you can't say that yocto gives you complete control and is very complex, so that obviously means its ideal for quick hacks but nothing else | 09:40 |
| neverpanic | If you wanna see what happens when automotive companies try to become software companies, look at slide 25: https://i.blackhat.com/EU-22/Wednesday-Briefings/EU-22-Serdyuk-Back-connect-to-the-connected-car.pdf | 09:40 |
| neverpanic | rburton: Go for it, I think this could be a nice "unfakeable linux" moment | 09:42 |
| kanavin | neverpanic, I only need to see that it's about volkswagen on the first slide, no further explanatins needed :) | 09:42 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:43 | |
| *** manuel1985 <manuel1985!~manuel198@mobiledyn-62-240-134-181.mrsn.at> has quit IRC (Ping timeout: 256 seconds) | 09:44 | |
| *** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has joined #yocto | 09:46 | |
| neverpanic | Makes the whole industry look bad, unfortunately. I worked on OTA update for BMW, and I can tell you it's not as broken as this. | 09:46 |
| tomzy_0 | morning | 09:47 |
| LetoThe2nd | neverpanic: judging from the number of people "having worked on OTA for BMW", my estimate is that about every car sold has a customized mechanism..... | 09:48 |
| * LetoThe2nd ducks and runs | 09:48 | |
| neverpanic | lol | 09:49 |
| neverpanic | Dunno, core team doing the updater was a dozen people or something? Plus equally as many doing testing, plus a bunch more in Munich writing protocol specifications and doing more testing. Maybe some testers in foreign countries. | 09:50 |
| LetoThe2nd | just trolling you a bit, no worries :-) | 09:51 |
| neverpanic | Overall probably <100 people. I guess you're just exceptionally lucky to have met many of them? :D | 09:51 |
| LetoThe2nd | or lets say i just meet a lot of people as part of my job, and exceptionally many involved in OTA? | 09:51 |
| LetoThe2nd | neverpanic: full disclosure, in case you didn't know - I'm leading developer relations for Mender :-) | 09:52 |
| mcfrisk | BMW OTA isn't just a single embedded product OTA, it's an "update 10's of computers, from 10's of vendors, using 10's of different SoC's" thing. | 09:52 |
| neverpanic | I didn't know. You must be furiously scratching your head on why we didn't just use something off the shelf, heh? | 09:53 |
| LetoThe2nd | neverpanic: no. | 09:53 |
| LetoThe2nd | mcfrisk: i know, thats how modern systems are most of the time. | 09:53 |
| LetoThe2nd | neverpanic: i know about industrial, i know about cars (a bit) and i certainly know A LOT about german companies. it would have been a massive surprise if BMW would have used something that somebody else created. | 09:54 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 09:55 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 09:55 | |
| mcfrisk | the complexity of German cars... | 09:57 |
| neverpanic | There were talks about buying something initially. I think they talked to Greencurve (name slightly altered), but that all fell apart when their highly praised delta algorithm wasn't actually all that great and one of ours devs wrote something with better delta performance. | 09:58 |
| neverpanic | mcfrisk: Oh yes! :( | 09:58 |
| LetoThe2nd | hehe | 09:58 |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 10:00 | |
| mcfrisk | Canonical has the usual argument: commercial, professional vs. community and open source. Having seen many of the commercial offerings, I can only recommend sticking to open source. Also, don't use Ubuntu in the clouds due to trademark violations, use community supported Debian instead. | 10:01 |
| *** Jham <Jham!~Juba@2a01:e0a:177:a830:2544:249d:766a:4168> has joined #yocto | 10:06 | |
| phako[m] | er. Does anyone perhaps know what might have gone wrong here? ERROR: libtirpc-native-1.3.2-r0 do_populate_lic_setscene: Fetcher failure: Unable to find file | 10:06 |
| phako[m] | file://7c/1d/sstate:libtirpc-native::1.3.2:r0::10:7c1d54507dcf6a036d2137eebfdf9eb33c3d2e1734ff8ecc02edba15f963e299_populate_lic.tar.zst.siginfo;downloadfilename=7c/1d/sstate:libtirpc-native::1.3.2:r0::10:7c1d54507dcf6a036d2137eebfdf9eb33c3d2e1734ff8ecc02edba15f963e299_populate_lic.tar.zst.siginfo anywhere. The paths that were searched were: | 10:06 |
| phako[m] | paths that were searched is the correct sstate cache | 10:07 |
| rburton | phako[m]: that usually means something is cleaning the sstate at the same time. the file was there when the sstate scan was done, wasn't when it was unpacked. | 10:09 |
| phako[m] | hrm. | 10:09 |
| phako[m] | odd. this was the only job running on jenkins | 10:10 |
| *** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Quit: Leaving) | 10:10 | |
| qschulz | phako[m]: no cronjob to remove sstate-cache every now and then? | 10:11 |
| rburton | phako[m]: i blame jenkins :) | 10:11 |
| qschulz | nobody with access to this server or the SSTATE_DIR and ran bitbake -c cleansstate/cleanall of the recipe? | 10:11 |
| phako[m] | qschulz: nah I am just trying to get this build. That is the first yocto build that did not bail out directly at the first call | 10:12 |
| phako[m] | also I am the only one with access to that server who knows what "bitbake" is and how to call it | 10:13 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:14 | |
| mcfrisk | and lol, pay/register walled solutions from Canonical. White or toilet paper... | 10:15 |
| phako[m] | crontab -l | 10:15 |
| phako[m] | meh | 10:15 |
| *** nate02 <nate02!~nathani@d75-157-113-180.bchsia.telus.net> has quit IRC (Read error: Connection reset by peer) | 10:18 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 10:25 | |
| phako[m] | and now irt just succeeded | 10:26 |
| phako[m] | what. | 10:26 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 10:26 | |
| phako[m] | jenkins ... | 10:26 |
| tomzy_0 | <3 I see that love for jenkins is everywhere the same :P | 10:27 |
| *** creich_ <creich_!~creich@p4ffe1a98.dip0.t-ipconnect.de> has joined #yocto | 10:32 | |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 10:55 | |
| *** starblue1 <starblue1!~juergen@dslb-088-078-102-232.088.078.pools.vodafone-ip.de> has quit IRC (Ping timeout: 252 seconds) | 10:57 | |
| *** starblue1 <starblue1!~juergen@dslb-088-078-102-232.088.078.pools.vodafone-ip.de> has joined #yocto | 10:59 | |
| rburton | phako[m]: local or http sstate? | 11:19 |
| phako[m] | should be local | 11:19 |
| rburton | pretend it never happened | 11:20 |
| phako[m] | Thats what I usually do with jenkins | 11:35 |
| phako[m] | finally: https://imgur.com/a/RjqFtmM Time for lunch | 11:37 |
| kanavin | what is it with various Stefans today | 11:41 |
| kanavin | I'm practicing afk with both | 11:41 |
| *** zpfvo <zpfvo!~fvo@i59F5CCC2.versanet.de> has joined #yocto | 12:00 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 12:09 | |
| *** zpfvo <zpfvo!~fvo@i59F5CCC2.versanet.de> has quit IRC (Ping timeout: 265 seconds) | 12:09 | |
| ldericher | I use `bitbake -c populate_sdk` to build an SDK for my target arch. Can I also build an SDK for a host arch? | 12:16 |
| *** vladest <vladest!~Thunderbi@2a02:1210:760b:9500:ca59:dce9:4a97:7c77> has quit IRC (Ping timeout: 246 seconds) | 12:18 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 12:19 | |
| rburton | ldericher: when building a SDK, MACHINE is what the sdk targets and SDKMACHINE is what the sdk runs on | 12:19 |
| ldericher | rburton, is there a generic value for an x64 linux machine? | 12:20 |
| rburton | x86-64 | 12:20 |
| rburton | the default is "your current host" | 12:20 |
| rburton | see meta/conf/machine-sdk/ for the supported SDKMACHINE values | 12:21 |
| ldericher | so if I let MACHINE be whatever my local.conf specifies - e.g. "some-arm", and SDKMACHINE be "x86-64", the resulting .so-files in the SDK will be "some-arm" or "x86-64"? (It should be the arm, right?) | 12:23 |
| *** g-embed <g-embed!~g-embed@c83-248-73-95.bredband.tele2.se> has joined #yocto | 12:25 | |
| *** g-embed <g-embed!~g-embed@c83-248-73-95.bredband.tele2.se> has quit IRC (Remote host closed the connection) | 12:26 | |
| rburton | there are two parts to the SDK: the host side (the compiler, the tools) and the target (the sysroot) | 12:26 |
| rburton | the former is SDKMACHINE, the latter is MACHINE | 12:26 |
| *** g-embed <g-embed!~g-embed@user/g-embed> has joined #yocto | 12:27 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC (Read error: Connection reset by peer) | 12:27 | |
| hsv | Are there any resources re editing kernel device tree explained in context of yocto? I'm a noob in both and struggling to make a simple edit. | 12:32 |
| phako[m] | nice. I have just built 4 of the same generic core-image-minimal because all local.conf changes got lost. argh. | 12:33 |
| * phako[m] sets fire to jenkins and calls it a week | 12:39 | |
| *** otavio <otavio!~otavio@200-180-239-15.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 256 seconds) | 12:40 | |
| *** otavio <otavio!~otavio@200-180-239-15.user3p.brasiltelecom.net.br> has joined #yocto | 12:40 | |
| rburton | phako[m]: solid plan | 12:40 |
| *** Guest4 <Guest4!~Guest4@2001:9e8:2d1:c400:544c:d856:f172:97bc> has joined #yocto | 12:42 | |
| *** Guest4 <Guest4!~Guest4@2001:9e8:2d1:c400:544c:d856:f172:97bc> has quit IRC (Client Quit) | 12:42 | |
| LetoThe2nd | phako[m]: you forgot the beers. | 12:46 |
| phako[m] | I am past the need of beer. | 12:46 |
| *** Guest23 <Guest23!~Guest23@177.194.9.77> has joined #yocto | 12:49 | |
| LetoThe2nd | phako[m]: join the next Yocto BoF and get some Scotch free! | 12:50 |
| Guest23 | Hello. How do I define a new image type? | 12:52 |
| Guest23 | What I did so far: | 12:52 |
| Guest23 | Added my new type to IMAGE_FSTYPES variable | 12:52 |
| Guest23 | Created a image_types_mytype.bbclass class, where I define a IMAGE_CMD_mytype function | 12:52 |
| Guest23 | Added my new class to the IMAGE_CLASSES variable | 12:52 |
| Guest23 | When I try to build the image, I get an error indicating that my IMAGE_CMD_mytype function is being parsed as a Python function, but it is a Shell function | 12:52 |
| ThomasRoos[m] | Any ideas before the first beer about this: | 12:55 |
| ThomasRoos[m] | | ../xorgproto-2021.5/meson.build:22:0: ERROR: Executables created by c compiler arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a15 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/tmp/build/tmp/work/cortexa15t2hf-neon-poky-linux-gnueabi/xorgproto/2021.5-r0/recipe-sysroot are not runnable. | 12:55 |
| rburton | Guest23: have you looked at the existing image_types.bbclass for similar patterns as yours? | 12:56 |
| rburton | Guest23: hard to debug without seeing anything that you're doing | 12:56 |
| rburton | ThomasRoos[m]: xorgproto?! are you patching or upgrading it? | 12:56 |
| LetoThe2nd | rburton: deleting it. | 12:57 |
| rburton | LetoThe2nd: ? | 12:57 |
| rburton | ThomasRoos[m]: its not wrong, the binaries are not runnable. but no idea why it would want to. | 12:58 |
| LetoThe2nd | rburton: just kidding. things that you should do *after* the first beer. delete xorg. | 12:58 |
| rburton | ah | 12:58 |
| ThomasRoos[m] | Just building with CodeBuild ;) | 12:58 |
| ThomasRoos[m] | And I'm only getting the error there when building e.g. systemd for arm (qemuarm not arm64 or x86...) | 12:58 |
| rburton | our meson does actually support throwing binaries into a qemu-user to run them during the configure but that should work for qemuarm too | 12:59 |
| ThomasRoos[m] | it's working locally totally fine, even in the same docker which is used by CodeBuild, but not in that environment... | 13:00 |
| ThomasRoos[m] | First had that issue, but it's solved by: sysctl -w vm.mmap_min_addr="0" | 13:01 |
| ThomasRoos[m] | qemu-arm: Unable to reserve 0xffff0000 bytes of virtual address space at 0x1000 (Success) for use as guest address space (check yourvirtual memory ulimit setting, min_mmap_addr or reserve less using -R option) | 13:01 |
| ThomasRoos[m] | | The Meson build system | 13:01 |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.112.73> has quit IRC (Ping timeout: 246 seconds) | 13:01 | |
| rburton | ah so maybe qemu-user is exploding still | 13:01 |
| ThomasRoos[m] | ? | 13:02 |
| Guest23 | rburton Yes I did look at image_types.bbclass. There really isn't much more than what I described in the previous message. Here is some of the error messages: | 13:03 |
| Guest23 | ERROR: Unable to parse /home/user/project/sources/meta-openembedded/meta-python/recipes-core/images/meta-python-image.bb | 13:03 |
| Guest23 | meta-python-image.bb', d=<bb.data_smart.DataSmart object at 0x7f29396f8fd0>, variant=None): | 13:03 |
| Guest23 | Â Â Â Â Â Â Â Â Â Â Â Â try: | 13:03 |
| Guest23 | Â Â Â >Â Â Â Â Â Â Â Â Â Â Â taskdeps = self._build_data(fn, d) | 13:03 |
| Guest23 | Â Â Â Â Â Â Â Â Â Â Â Â except bb.parse.SkipRecipe: | 13:03 |
| Guest23 | ... | 13:03 |
| Guest23 | for task in tasklist: | 13:03 |
| Guest23 | Â Â Â >Â Â Â Â Â Â Â deps[task], values[task] = build_dependencies(task, keys, shelldeps, varflagsexcl, d) | 13:03 |
| Guest23 | Â Â Â Â Â Â Â Â Â Â Â Â newdeps = deps[task] | 13:03 |
| Guest23 | ... | 13:03 |
| Guest23 | parser = bb.codeparser.PythonParser(key, logger) | 13:03 |
| Guest23 | Â Â Â >Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â parser.parse_python(value, filename=varflags.get("filename"), lineno=varflags.get("lineno")) | 13:03 |
| Guest23 | Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â deps = deps | parser.references | 13:03 |
| rburton | Guest23: can you share what you've done? | 13:04 |
| Guest23 | I did exactly what I described earlier | 13:04 |
| rburton | i mean your new image type | 13:04 |
| Guest23 | inherit image_types | 13:05 |
| Guest23 | IMAGE_CMD_mytype () { | 13:05 |
| Guest23 | } | 13:05 |
| Guest23 | IMAGE_TYPEDEP_mytype = "tar.bz2" | 13:05 |
| Guest23 | currently this is my image_types_mytype.bbclass | 13:05 |
| rburton | with no content? | 13:05 |
| rburton | and i guess you're using a really old release | 13:06 |
| Guest23 | I forgot to mention, I'm using Yocto Dunfell | 13:06 |
| Guest23 | There is content but it doesn't really matter, I always get the same parsing error | 13:06 |
| rburton | remove the inherit, its redundant | 13:07 |
| Guest23 | Ok. It doesn't fix the issue though | 13:08 |
| rburton | does it explode when you select it, or always? | 13:08 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 255 seconds) | 13:08 | |
| Guest23 | what do you mean when I select it? | 13:09 |
| rburton | when you use IMAGE_FSTYPES to pick your image type | 13:09 |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has quit IRC (Ping timeout: 252 seconds) | 13:09 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.112.73> has joined #yocto | 13:09 | |
| Guest23 | Only when I select it | 13:09 |
| RP | Guest23: just guessing but try a single colon in the function | 13:10 |
| RP | Guest23: I suspect the code is struggling with a zero length function | 13:11 |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has joined #yocto | 13:11 | |
| rburton | there really is content but Guest23 won't share it | 13:11 |
| rburton | its probably a parse failure in the code but we cant' help there | 13:11 |
| rburton | turning the function into just a single colon will rule that out though | 13:12 |
| RP | rburton: ah, right. If there is a parse error in code we can't see that would be hard to help with | 13:12 |
| Guest23 | The parser get crazy when trying to parse the IMAGE_CMD function, despite its content: | 13:12 |
| Guest23 | parser = bb.codeparser.PythonParser(key, logger) | 13:12 |
| Guest23 | Â Â Â >Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â parser.parse_python(value, filename=varflags.get("filename"), lineno=varflags.get("lineno")) | 13:12 |
| Guest23 | Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â deps = deps | parser.references | 13:12 |
| Guest23 | codeparser.py", line 308, in PythonParser.parse_python(node='\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\ | 13:12 |
| Guest23 | n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\t | 13:12 |
| rburton | Guest23: if you could share the code someone else can help. you've probably made a typo and the entire file is parsing badly. | 13:12 |
| Guest23 | I'm sure the content of the IMAGE_CMD function is not the problem. I even tried the different syntax: | 13:14 |
| Guest23 | IMAGE_CMD_mytype = "" | 13:14 |
| Guest23 | instead of | 13:14 |
| Guest23 | IMAGE_CMD_mytype () { | 13:14 |
| Guest23 | } | 13:14 |
| rburton | right it might be something else in the file | 13:14 |
| rburton | which if you share we can look at | 13:14 |
| rburton | you're literally giving the vaguest impression of what you've got and asking us to debug it | 13:14 |
| Guest23 | There isn't much more to the file, as I showed previously | 13:14 |
| rburton | so pastebin the literal contents then? | 13:15 |
| rburton | if i can have the file and replicate the problem then we can fix the problem and see if the error reporting can be improved | 13:15 |
| Guest23 | it's literally 3 sloc and I get a parsing error | 13:15 |
| qschulz | Guest23: IMAGE_CMD_mytype () {} is not valid | 13:16 |
| qschulz | IMAGE_CMD_mytype () {:} would be though | 13:16 |
| rburton | yeah we've done that :) | 13:16 |
| qschulz | sent on the chan literally 2min ago /me shrugs | 13:17 |
| Guest23 | As I said I created this image_types_mytype.bbclass | 13:17 |
| Guest23 | https://pastebin.com/1SE5pPVM | 13:17 |
| Guest23 | Added the class to the IMAGE_CLASSES variable | 13:17 |
| Guest23 | And added the type to the IMAGE_FSTYPES variable | 13:17 |
| * g-embed is very impressed by rburton, RP and qschulz willingness to help with such a vague description. Hoping for the same for me :) | 13:18 | |
| Guest23 | Simple as that | 13:18 |
| rburton | comment out the TYPEDEP line, that's not often used and might have broken | 13:18 |
| Guest23 | Same problem | 13:18 |
| qschulz | don't know if we asked this already but is this reproducible with just poky/oe-core? (no external layer, only this added class and IMAGE_CLASSES+IMAGE_FSTYPES change)? | 13:20 |
| qschulz | I've seen crazy things in 3rd party layers my eyes would like to unsee so maybe there's some weird thing going on there, just trying to rule out the "obvious" | 13:21 |
| rburton | absolutely | 13:21 |
| rburton | so i have a image_type_foo.bbclass which just contains: | 13:21 |
| rburton | IMAGE_CMD:foo () { | 13:21 |
| rburton | bbwarn FOOBAR | 13:21 |
| rburton | } | 13:21 |
| rburton | added to IMAGE_CLASSES, set IMAGE_FSTYPES | 13:22 |
| rburton | WARNING: core-image-minimal-1.0-r0 do_image_foo: FOOBAR | 13:24 |
| rburton | all I can say is pastebin your changes to IMAGE_CLASSES and IMAGE_FSTYPES so we know what you're doing, replicate with a plain poky and no annoying vendor layers | 13:25 |
| Guest23 | IMAGE_FSTYPES += "tar.bz2 ubi wic.bz2 mytype" | 13:27 |
| Guest23 | IMAGE_CLASSES += "image_types_mytype" | 13:27 |
| Guest23 | Just added this to my meta-mylayer/conf/machine/mydistro.conf | 13:27 |
| rburton | i'd bisect. fresh poky with no layers, empty class file. add to image_class, check still works. add dummy IMAGE_CMD with just a bbwarn message, check still works. set IMAGE_FSTYPES, check still works. | 13:36 |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 13:39 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 13:39 | |
| *** Guest23 <Guest23!~Guest23@177.194.9.77> has quit IRC (Ping timeout: 260 seconds) | 13:40 | |
| tomzy_0 | how to efficiently read dependencies graf? let's say I have connman installed on the image, but not provided via IMAGE_INSTALL in my image recipe. How to find out how it goes there? | 13:41 |
| qschulz | bitbake -g <my-image> and check the dot files with your favorite text editor, that's how I would do it | 13:41 |
| qschulz | tomzy_0: ^ | 13:42 |
| tomzy_0 | I feared that this will be the answer, think that it is time to learn how to read that file :P | 13:43 |
| tomzy_0 | thanks | 13:43 |
| tomzy_0 | qschulz task on left of `->` was run because of task on right of `->`? | 13:46 |
| qschulz | I don't remember, but look at one do_compile and check where the do_configure is, do_configure is run because of do_compile | 13:47 |
| tomzy_0 | makes sense | 13:48 |
| tomzy_0 | thanks once again | 13:48 |
| g-embed | OK, so I need some help with kernel development if someone's up for it. | 13:49 |
| *** mckoan_ <mckoan_!~marco@host-95-229-48-41.business.telecomitalia.it> has joined #yocto | 13:49 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 13:49 | |
| rburton | tomzy_0: https://www.youtube.com/watch?v=V9_bIKoqr5Y&list=PLD4M5FoHz-TwT20z2FPKy4y38Tur6ArIL&index=2 about ten minutes in | 13:49 |
| rburton | tldr: oe-depends-dot | 13:50 |
| qschulz | g-embed: probably the wrong IRC chan but I have none to recommend specifically right now. You can always try your luck and ask the question here | 13:50 |
| rburton | tomzy_0: stuff like connman gets in via packagegroups | 13:50 |
| g-embed | Well it's linux-yocto related | 13:51 |
| tomzy_0 | rburton: yeap, got it, it was `packagegroup-core-tools-testapps` | 13:51 |
| tomzy_0 | but I dont think I heard about `oe-depends-dot task-depends.dot --why --key` before | 13:51 |
| tomzy_0 | need to check that | 13:51 |
| rburton | which comes in via an image feature | 13:51 |
| g-embed | In the end, I need to achieve two things: Modify config to CONFIG_X=y to get a driver built into the kernel, and would be good to also remove another driver (change to CONFIG_Y=m). | 13:52 |
| g-embed | Secondly I need to provide a device-tree for the peripheral in question. | 13:52 |
| rburton | g-embed: https://docs.yoctoproject.org/kernel-dev/common.html#configuring-the-kernel | 13:52 |
| *** mckoan|away <mckoan|away!~marco@host-95-229-48-41.business.telecomitalia.it> has quit IRC (Ping timeout: 255 seconds) | 13:52 | |
| qschulz | g-embed: I believe config fragments should answer your first question | 13:53 |
| rburton | if you're using linux-yocto then https://docs.yoctoproject.org/kernel-dev/common.html#creating-configuration-fragments is the best solution | 13:53 |
| g-embed | I think I've been there qschulz. Let me ask my question and if it's answered in docs already you can tell me to go away, ok? :) | 13:53 |
| qschulz | for the second, I don't know what's the recommended solution for out-of-tree device trees.. I would have a patch adding the dts and patching the Makefile to build it along the other dtses | 13:54 |
| g-embed | Device tree might be easiest. Currently meta-VENDOR (placeholder name to protect the not so innocent) has a MACHINE conf file, which includes MACHINE-extra.conf so I'm creating a file like that in my layer. | 13:54 |
| rburton | you set KERNEL_DEVICETREE to the devicetree filename iirc | 13:54 |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 13:54 | |
| g-embed | It includes KERNEL_DEVICETREE_append = " THING.dtb ". This adds THING.dtb to the boot directory, so it seems OK. Is there anything else required to make that device tree be actually used? | 13:54 |
| g-embed | It = my -extra file. In short, it seems to be picked up and used. But what controls if a dtb is actually read by the kernel? | 13:55 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 256 seconds) | 13:56 | |
| g-embed | I.e. is it enough that extra-thing.dtb exists in boot directory. I assume not. Or KERNEL_DEVICETREE does the necessary magic for the compilation of the kernel? | 13:57 |
| qschulz | g-embed: something in the bootloader will pick the proper device tree | 13:58 |
| qschulz | that's device specific so cannot help here | 13:58 |
| g-embed | qschulz, oh yeah, you're right. I have also patched the Makefile. Proof of that is that my .dts becomes a .dtb, I believe. | 13:58 |
| qschulz | g-embed: yes dts is only a source file, dtb is the blob, usable by the kernel | 13:59 |
| g-embed | OK, I'll look at bootloader then. I suppose the alternative is to try to patch my dts into the already used <MACHINE>.dts | 13:59 |
| qschulz | that's one way yes | 13:59 |
| qschulz | it depends in the end | 13:59 |
| qschulz | because if MACHINE is actually your HW, it makes sense | 14:00 |
| qschulz | if MACHINE is just a devkit/base whatever your vendor gave you and you have a different product | 14:00 |
| qschulz | you should create another machine.conf file for your specific machine | 14:00 |
| qschulz | and in that scenario you don't need to append the KERNEL_DEVICETREE but just set it | 14:00 |
| qschulz | and if the Yocto layers are done correctly by your vendor, it should just boot your dtb then automagically | 14:01 |
| qschulz | I believe the first entry in KERNEL_DEVICETREE is usually the default dtb | 14:01 |
| qschulz | so maybe doing a :prepend instead of an :append might do the trick | 14:01 |
| qschulz | (don't forget the trailing space for the prpend) | 14:01 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 14:02 | |
| g-embed | Yeah that all makes sense, problem is there's so much stuff in vendor layer I'm hesitant to remove/replace/copy it. | 14:04 |
| g-embed | So... first attempt is to just extend the MACHINE they have. | 14:04 |
| g-embed | OK, so config baffles me more. One of the list of patches in meta-VENDOR creates a new <MACHINE>_defconfig in arch/arm64/configs, which I would simply presume is the one intended to be used. But they ALSO add a complete file "defconfig" in SRC_URI so that gets copied into the work dir, and then they add a custom task after do_unpack, to copy the "defconfig" to ${B}/.config | 14:05 |
| brabander | does anyone know an good example project that uses multiconfig ? | 14:05 |
| g-embed | I've been trying to modify these files, even adding deliberate errors, etc. but modifications don't seem to stick, and I've still ended up confused about which _actual_ config is being used in the compilation? | 14:06 |
| g-embed | This might be an easy question to answer, what normally gets used? I've watched other yocto docs/instructions say that you SHOULD provide a "defconfig" file. But what then of <MACHINE>_defconfig and the custom copy step? | 14:06 |
| qschulz | g-embed: read the class source code carefully, the only way to know for sure for me (maybe the docs mention it? not sure). | 14:07 |
| qschulz | I've not used config fragments yet for multiple reasons (some of which are apparently not true anymore/were never true) | 14:08 |
| qschulz | so I cannot help there :/ | 14:08 |
| g-embed | Yeah, that's yet another road to take. I was hoping to first do either: Replace config completely with my modified file, or successfully patch "their" config. But so far, it's just been confusing. | 14:08 |
| g-embed | so... haven't tried with config fragments. I'm not sure this will help when the whole setup is not done cleanly according to the Yocto way. | 14:09 |
| qschulz | g-embed: if there's already a defconfig, I would just modify it without spending too much time for now on config fragments as I **think** config fragments and user-provided defconfig don't work well together (but that's just an uneducated geuss) | 14:10 |
| RP | g-embed: config fragments are the better way to do it but if it isn't using that, converting it will be a pain. You're therefore right to try and change the existing defconfig | 14:10 |
| g-embed | Thanks for that encouragement. As always "get something that works" is the first step. Still remaining is which "defconfig" is the actual one? | 14:10 |
| g-embed | Sorry, these are basic questions, but how does "defconfig" relate to .config in a kernel build? | 14:11 |
| RP | g-embed: there are two reasons we're struggling to help here. a) this is very device specific as it depends on the bootloader and kernel, both of which the vendor can and probably has changed. b) the vendor didn't use our best practises like config fragments :/ | 14:11 |
| g-embed | I mean ultimately, I just want to provide ONE actual full config file, and have that be used. | 14:11 |
| RP | g-embed: if you provide a "file://defconfig" file in SRC_URI, it is possible that it will simply be copied to the .config. It does depend what the vendor did in the kernel recipe though | 14:12 |
| g-embed | RP, They are specifying a custom task to copy it to ${B}/.config | 14:13 |
| qschulz | g-embed: you could have your own defconfig in your own layer by making sure to have a bbappend with FILESEXTRAPATHS:prepend in there | 14:13 |
| g-embed | I just thought it was something standard in the class, because others also show the principle of including a defconfig (without a custom task) | 14:13 |
| RP | g-embed: so can you change the input file to that? | 14:13 |
| qschulz | and that the layer priorities and/or order for your layer makes Bitbake take your defconfig over your vendor's | 14:14 |
| g-embed | RP, I can, it didn't seem to stick, so I started getting confused whether that was actually being used. Specially considering that they go through the trouble of patching the kernel tree in /arch/arm64/configs to add <MACHINE_defconfig> in there | 14:14 |
| qschulz | g-embed: small tip 1) you can check the config used by Bitbake by running bitbake -c menuconfig virtual/kernel | 14:15 |
| g-embed | qschulz, good, haven't tried that | 14:15 |
| qschulz | g-embed: small tip 2) check the defconfig is actually copied from the layer to workdir to ${B}/.config, I remember some bad implementation in some 3rd layer that didn't handle this well | 14:15 |
| g-embed | yeah I've been playing with the layer priorities also. If my layer runs too early, it fails because it also adds a patch on top of vendor layer. | 14:15 |
| RP | g-embed: without knowing which make targets their recipe calls, it is hard for us to know either :( | 14:15 |
| RP | JPEW: FWIW you shouldn't need https://git.yoctoproject.org/poky-contrib/commit/?h=jpew/extra-siggen&id=24eef9888094ea7644d9dae8729ff17cd4ae15a7 since it combines all the parser thread profiles into a single processed log | 14:18 |
| JPEW | RP: Ah I must have missed that | 14:19 |
| JPEW | Updated | 14:20 |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 14:20 | |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 14:20 | |
| RP | JPEW: that way you get the average over all the parsing processes which I'd figured was probably the more useful thing | 14:21 |
| JPEW | ya | 14:21 |
| RP | JPEW: do you have much experience with python memory usage? I was wondering if we can easily benchmark that | 14:24 |
| JPEW | I don't | 14:24 |
| qschulz | is there not a python memory profiler that was released a few months ago? | 14:24 |
| RP | qschulz: probably, I was just hoping someone would just know how to do it :) | 14:25 |
| * RP did this before but years ago | 14:25 | |
| RP | I think I'm going to focus on sorting the python function move, then come back to this | 14:26 |
| qschulz | RP: I believe it was this one that made thew news some months ago: https://github.com/bloomberg/memray | 14:29 |
| RP | qschulz: thanks, will have to have a look! | 14:32 |
| g-embed | RP, fully understood, you are all doing great. | 14:33 |
| g-embed | I don't seem to see any special make target stuff. meta-VENDOR appends to linux-imx: https://source.codeaurora.org/external/imx/meta-imx/tree/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb?h=rel_imx_5.4.70_2.3.0. which includes https://github.com/Freescale/meta-freescale/blob/94f4f086c6014cbcfd10bda3540d19558c8bf0b0/recipes-kernel/linux/linux-imx.inc which inherits kernel.bbclass so from there it's standard I suppose. | 14:34 |
| qschulz | g-embed: kernel-yocto is actually the fancy one with config fragment support | 14:35 |
| g-embed | Ah right. So kernel.bbclass is older? | 14:35 |
| qschulz | g-embed: linux-yocto uses this fancy class, vendor recipes usually not so much | 14:35 |
| qschulz | g-embed: they are complimentary IIRC | 14:35 |
| qschulz | all kernel recipes should inherit kernel in some ways | 14:35 |
| qschulz | kernel-yocto class adds some more nice things to it | 14:36 |
| qschulz | linux-yocto vs linux-imx! | 14:36 |
| qschulz | s/vs/!=/ | 14:36 |
| g-embed | Well, long way around back to the same place I think. It all suggests to me I just gotta get the config into ${B}/.config . | 14:36 |
| g-embed | The other stuff the vendor layer is doing, creating other named files, patching kernel tree with new configs... it just seems redundant. But that's the thing it's so hard when there are confusing details all around. | 14:37 |
| qschulz | g-embed: tbf, the kernel configuration is pretty hard | 14:38 |
| RP | g-embed: my suggestion would be to change ${B}/.config and see if that works and makes the change you need. Ignore the other bits unless that doesn't work in which case you'll have to investigate | 14:38 |
| qschulz | and that can be done via the menuconfig task. Once working, you can then run savedefconfig task and take the defconfig out of ${B}/defconfig and put it into your layer | 14:40 |
| g-embed | OK, so looking at some of my older attempts it doesn't seem like the copy works. | 14:45 |
| g-embed | so if I addtask in the same way they did in meta-VENDOR: "addtask copy_defconfig after do_unpack before do_merge_delta_config", would my copy run after or before theirs? Maybe it gets overwritten. | 14:46 |
| g-embed | My BBFILE_PRIORITY is higher, i.e. my append runs after vendor. | 14:48 |
| *** Guest1396 <Guest1396!~sotaoverr@ool-4578fe22.dyn.optonline.net> has quit IRC (Ping timeout: 264 seconds) | 14:50 | |
| LetoThe2nd | completely different thing, has anybody accidentially heard of a yocto-based build for esp32 freertos/baremetal? | 14:52 |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Ping timeout: 252 seconds) | 14:54 | |
| g-embed | I've been resisting to fork and modify meta-VENDOR but maybe it's the only way to get control of this thing :( | 14:54 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: xmn) | 14:56 | |
| *** sotaover1ide <sotaover1ide!~sotaoverr@ool-4578fe22.dyn.optonline.net> has joined #yocto | 14:57 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 15:04 | |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-26-174-95-44-180.dsl.bell.ca> has joined #yocto | 15:09 | |
| *** g-embed <g-embed!~g-embed@user/g-embed> has quit IRC (Ping timeout: 264 seconds) | 15:19 | |
| *** tor <tor!~tor@user/tor> has quit IRC (Remote host closed the connection) | 15:23 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 15:39 | |
| *** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto | 15:49 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has quit IRC (Ping timeout: 256 seconds) | 15:49 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 15:49 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 246 seconds) | 15:53 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has joined #yocto | 15:54 | |
| *** PascalBach[m] <PascalBach[m]!~bachpmatr@2001:470:69fc:105::1d3b> has quit IRC (Quit: You have been kicked for being idle) | 16:00 | |
| *** Guest23 <Guest23!~Guest23@189.101.165.177> has joined #yocto | 16:01 | |
| *** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:853d:6d6e:a5ed:c2ea> has joined #yocto | 16:01 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 16:06 | |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 16:08 | |
| *** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:853d:6d6e:a5ed:c2ea> has quit IRC (Ping timeout: 256 seconds) | 16:10 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Ping timeout: 260 seconds) | 16:20 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 16:21 | |
| *** GillesM <GillesM!~ploum@117.187.22.109.rev.sfr.net> has quit IRC (Quit: Leaving) | 16:31 | |
| *** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:853d:6d6e:a5ed:c2ea> has joined #yocto | 16:41 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 265 seconds) | 16:44 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:47 | |
| *** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:853d:6d6e:a5ed:c2ea> has quit IRC (Ping timeout: 264 seconds) | 16:48 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 16:50 | |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 16:52 | |
| *** g-embed <g-embed!~g-embed@m5-241-46-10.cust.tele2.se> has joined #yocto | 17:12 | |
| *** amelius <amelius!~quassel@147.161.171.90> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 17:19 | |
| RP | JPEW: I think multiconfig is broken with hash equivalence :( I can't see any handling of mc in the report_unihash function | 17:34 |
| RP | We've bolted too much new code around old crumbling APIs | 17:36 |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.112.73> has quit IRC (Ping timeout: 248 seconds) | 17:36 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.114.88> has joined #yocto | 17:38 | |
| *** hcg <hcg!~hcg@213.55.241.64> has joined #yocto | 17:45 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.114.88> has quit IRC (Ping timeout: 264 seconds) | 17:45 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.114.88> has joined #yocto | 17:47 | |
| hcg | I wonder if there is anyone out there using meta-ti who understands how the kernel config is constructed? | 17:48 |
| abelloni | I despise vendor that have their own do_configure | 17:51 |
| JPEW | RP: I'm not sure that was entirely omitted on accident | 17:53 |
| JPEW | RP: But it depends on which part? | 17:54 |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.114.88> has quit IRC (Ping timeout: 260 seconds) | 17:55 | |
| RP | JPEW: It looks like we encode the mutliconfig data into BB_FILENAME so we're probably safe. This is all so horrible though :( | 17:56 |
| * RP didn't think we did that | 17:56 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.112.73> has joined #yocto | 17:57 | |
| *** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5380:54c0:641a:9340:edee:12ac> has quit IRC (Ping timeout: 252 seconds) | 18:01 | |
| * RP feels a rewrite of some of this code is starting to look like it might be an idea | 18:02 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.112.73> has quit IRC (Ping timeout: 256 seconds) | 18:04 | |
| RP | All because I wanted to write out the sigs before and after my python function change so I could check what I was doing was working | 18:05 |
| * RP gives up bit and finds food | 18:06 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.122.26> has joined #yocto | 18:06 | |
| *** Jham <Jham!~Juba@2a01:e0a:177:a830:2544:249d:766a:4168> has quit IRC (Quit: Leaving) | 18:08 | |
| *** g-embed <g-embed!~g-embed@user/g-embed> has quit IRC (Ping timeout: 260 seconds) | 18:10 | |
| *** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5380:54c0:b902:2c44:8d31:4426> has joined #yocto | 18:13 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has quit IRC (Ping timeout: 246 seconds) | 18:19 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 18:19 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.122.26> has quit IRC (Ping timeout: 256 seconds) | 18:23 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 268 seconds) | 18:24 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has joined #yocto | 18:24 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.113.175> has joined #yocto | 18:25 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.113.175> has quit IRC (Ping timeout: 260 seconds) | 18:30 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.113.2> has joined #yocto | 18:31 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 18:31 | |
| *** vvn <vvn!~vivien@bras-base-mtrlpq02huw-grc-03-174-88-247-5.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.7.1) | 18:33 | |
| *** vvn <vvn!~vivien@bras-base-mtrlpq02huw-grc-03-174-88-247-5.dsl.bell.ca> has joined #yocto | 18:34 | |
| *** otavio <otavio!~otavio@200-180-239-15.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 268 seconds) | 18:36 | |
| *** otavio <otavio!~otavio@200-180-239-15.user3p.brasiltelecom.net.br> has joined #yocto | 18:37 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-049-034-152.78.49.pool.telefonica.de> has joined #yocto | 18:38 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 18:40 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-049-034-152.78.49.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 18:44 | |
| *** malsyned <malsyned!~IceChat95@174.168.24.175> has joined #yocto | 18:54 | |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 18:55 | |
| *** Wouter010067 <Wouter010067!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 18:55 | |
| *** malsyned <malsyned!~IceChat95@174.168.24.175> has quit IRC (Ping timeout: 268 seconds) | 19:06 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-049-034-152.78.49.pool.telefonica.de> has joined #yocto | 19:14 | |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has joined #yocto | 19:22 | |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has quit IRC (Read error: Connection reset by peer) | 19:24 | |
| *** arielmrmx <arielmrmx!~quassel@189.161.100.170> has quit IRC (Remote host closed the connection) | 19:36 | |
| *** grsandeep85 <grsandeep85!~grsandeep@149.199.90.130> has joined #yocto | 19:42 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 19:50 | |
| *** invalidopcode7 <invalidopcode7!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 19:50 | |
| *** grsandeep85 <grsandeep85!~grsandeep@149.199.90.130> has quit IRC (Quit: Client closed) | 19:50 | |
| *** grsandeep85 <grsandeep85!~grsandeep@149.199.90.130> has joined #yocto | 19:55 | |
| *** amitk_ <amitk_!~amit@103.208.69.22> has quit IRC (Ping timeout: 252 seconds) | 19:59 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 20:00 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-049-034-152.78.49.pool.telefonica.de> has quit IRC (Ping timeout: 246 seconds) | 20:05 | |
| *** mckoan_ <mckoan_!~marco@host-95-229-48-41.business.telecomitalia.it> has quit IRC (Read error: Connection reset by peer) | 20:12 | |
| *** mckoan|away <mckoan|away!~marco@host-95-229-48-41.business.telecomitalia.it> has joined #yocto | 20:17 | |
| *** malsyned <malsyned!~IceChat95@174.168.24.175> has joined #yocto | 20:25 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 252 seconds) | 20:33 | |
| *** malsyned <malsyned!~IceChat95@174.168.24.175> has quit IRC (Ping timeout: 256 seconds) | 20:36 | |
| *** malsyned <malsyned!~IceChat95@174.168.24.175> has joined #yocto | 20:43 | |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Ping timeout: 260 seconds) | 20:44 | |
| *** DvorkinDmitry <DvorkinDmitry!~dvorkin@5.167.98.73> has quit IRC (Remote host closed the connection) | 20:49 | |
| *** malsyned <malsyned!~IceChat95@174.168.24.175> has quit IRC (Ping timeout: 268 seconds) | 20:50 | |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 21:09 | |
| kiwi_29_[m] | reposting for some/any insight | 21:14 |
| kiwi_29_[m] | Hello... I upgraded GO compiler in my yocto dunfell from default 1.14 .....(available as part of standard poky meta/recipes-devtools/go) to 1.19 by copying go 1.19 recipes available in langdale to my customlayer . When I used to generate sdk using. bitbake -c populate_sdk DISTRO_NAME before go upgrade, it used to include go compiler version 1.14. After upgrading to go 1.19, I m not getting any go version inside sdk | 21:14 |
| kiwi_29_[m] | I do see some code related to this in meta/recipes-core/meta/meta-go-toolchain.bb , but I am not sure how to use it to include go 1.19 in the sdk | 21:14 |
| kiwi_29_[m] | I m wondering how was this recipe included previously when I compiled toolchain using bitbake -c populate_sdk DISTRO_NAME | 21:14 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 21:27 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 21:30 | |
| *** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:c580:4e9c:fb23:2c28> has joined #yocto | 21:31 | |
| *** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:c580:4e9c:fb23:2c28> has quit IRC (Ping timeout: 252 seconds) | 21:44 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto | 21:46 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has quit IRC (Ping timeout: 268 seconds) | 21:49 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 21:49 | |
| *** nemik_ <nemik_!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 260 seconds) | 21:54 | |
| *** nemik_ <nemik_!~nemik@207.237.248.190> has joined #yocto | 21:54 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-049-034-152.78.49.pool.telefonica.de> has joined #yocto | 21:59 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 255 seconds) | 22:02 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-049-034-152.78.49.pool.telefonica.de> has quit IRC (Ping timeout: 256 seconds) | 22:15 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 22:23 | |
| *** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:c580:4e9c:fb23:2c28> has joined #yocto | 22:28 | |
| *** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:c580:4e9c:fb23:2c28> has quit IRC (Ping timeout: 256 seconds) | 22:38 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection) | 22:38 | |
| *** grsandeep85 <grsandeep85!~grsandeep@149.199.90.130> has quit IRC (Quit: Client closed) | 22:43 | |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-26-174-95-44-180.dsl.bell.ca> has quit IRC (Quit: Konversation terminated!) | 22:43 | |
| *** grsandeep8574 <grsandeep8574!~grsandeep@149.199.90.130> has joined #yocto | 23:10 | |
| *** grsandeep8574 <grsandeep8574!~grsandeep@149.199.90.130> has quit IRC (Client Quit) | 23:10 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 23:14 | |
| *** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:c580:4e9c:fb23:2c28> has joined #yocto | 23:18 | |
| *** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:c580:4e9c:fb23:2c28> has quit IRC (Ping timeout: 260 seconds) | 23:22 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-049-034-152.78.49.pool.telefonica.de> has joined #yocto | 23:23 | |
| RP | kiwi_29_[m]: In master the code looks like meta/classes-recipe/populate_sdk_base.bbclass: ${@bb.utils.contains('SDK_TOOLCHAIN_LANGS', 'go', 'packagegroup-go-cross-canadian-${MACHINE}', '', d)} | 23:26 |
| RP | kiwi_29_[m]: I don't remember dunfell, it was different but hopefully that gives a hint of where/what to look for | 23:26 |
| *** money_ <money_!~money@user/polo> has joined #yocto | 23:59 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
