Friday, 2022-12-09

*** florian <florian!> has quit IRC (Ping timeout: 268 seconds)00:00
*** malsyned <malsyned!> has quit IRC (Ping timeout: 256 seconds)00:08
*** yocti <yocti!> has joined #yocto01:09
*** ChanServ sets mode: +o yocti01:09
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)01:16
*** money_ <money_!~money@user/polo> has quit IRC (Quit: money_)01:32
khemCanonical has written a whitepaper comparing ubuntu-core and yocto addressing CTOs -
khemwe must be doing something right 🙂01:37
*** starblue <starblue!> has quit IRC (Ping timeout: 256 seconds)02:13
*** starblue <starblue!> has joined #yocto02:15
*** rber|res <rber|res!~rber|> has joined #yocto02:32
*** RobertBerger <RobertBerger!~rber|> 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 #yocto03:21
*** camus <camus!~Instantbi@> has joined #yocto03:22
*** yocti` <yocti`!> has joined #yocto03:29
*** yocti <yocti!> has quit IRC (Killed (NickServ (GHOST command used by yocti`)))03:29
*** bantu_ <bantu_!> has joined #yocto03:30
*** yocti` is now known as yocti03:30
*** ChanServ sets mode: +o yocti03:30
*** starblue1 <starblue1!> has joined #yocto03:31
*** Net147_ <Net147_!> has joined #yocto03:32
*** invalidopcode7 <invalidopcode7!> has joined #yocto03:32
*** Tokamak__ <Tokamak__!~Tokamak@> has joined #yocto03:34
*** georgem <georgem!> has quit IRC (Ping timeout: 256 seconds)03:34
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 256 seconds)03:34
*** kpo <kpo!> 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!> has quit IRC (Ping timeout: 256 seconds)03:34
*** georgem_ is now known as georgem03:34
*** starblue <starblue!> has quit IRC (Ping timeout: 256 seconds)03:34
*** Wouter01006 <Wouter01006!> has quit IRC (Ping timeout: 256 seconds)03:34
*** invalidopcode <invalidopcode!> has quit IRC (Ping timeout: 256 seconds)03:34
*** Tokamak_ <Tokamak_!~Tokamak@> has quit IRC (Ping timeout: 256 seconds)03:34
*** gsalazar <gsalazar!> has quit IRC (Ping timeout: 256 seconds)03:34
*** yann <yann!~yann@> has quit IRC (Ping timeout: 256 seconds)03:34
*** vmeson <vmeson!> has quit IRC (Ping timeout: 256 seconds)03:34
*** jmk1 <jmk1!> has quit IRC (Ping timeout: 256 seconds)03:34
*** bantu <bantu!> 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!> has quit IRC (Ping timeout: 256 seconds)03:34
*** invalidopcode7 is now known as invalidopcode03:34
*** camus1 is now known as camus03:34
*** Wouter010067 is now known as Wouter0100603:34
*** vmeson <vmeson!> has joined #yocto03:35
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has joined #yocto03:37
*** yann <yann!~yann@> has joined #yocto03:43
*** pabigot <pabigot!> has joined #yocto03:43
*** nate02 <nate02!> has joined #yocto03:57
*** nathani <nathani!> has quit IRC (Ping timeout: 264 seconds)04:02
*** warthog19 <warthog19!> has joined #yocto04:07
*** alicef_ <alicef_!~none@gentoo/developer/alicef> has quit IRC (Quit: install gentoo)04:31
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto04:34
*** sgw <sgw!~swold_loc@user/sgw> has quit IRC (Ping timeout: 268 seconds)04:56
*** Wouter01006 <Wouter01006!> has quit IRC (Quit: The Lounge -
*** Wouter010067 <Wouter010067!> has joined #yocto05:10
*** nemik_ <nemik_!~nemik@> has quit IRC (Ping timeout: 255 seconds)05:29
*** nemik_ <nemik_!> has joined #yocto05:29
*** nemik_ <nemik_!> has quit IRC (Ping timeout: 252 seconds)05:34
*** nemik_ <nemik_!~nemik@> has joined #yocto05:34
*** thomasd13 <thomasd13!> has joined #yocto05:45
*** thomasd13 <thomasd13!> has quit IRC (Ping timeout: 256 seconds)06:10
*** olani <olani!> has quit IRC (Ping timeout: 248 seconds)06:19
*** money_ <money_!~money@user/polo> has joined #yocto06:19
*** money_ <money_!~money@user/polo> has quit IRC (Ping timeout: 256 seconds)06:26
*** xmn <xmn!> 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!> has quit IRC (Ping timeout: 260 seconds)07:00
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:05
*** thomasd13 <thomasd13!> has joined #yocto07:07
*** sgw <sgw!~swold_loc@user/sgw> has joined #yocto07:09
*** rob_w <rob_w!~rob@2001:a61:61c1:9001:85d4:9b1b:a383:66fa> has joined #yocto07:11
*** thomasd13 <thomasd13!> has quit IRC (Remote host closed the connection)07:17
*** thomasd13 <thomasd13!> has joined #yocto07:17
*** sgw <sgw!~swold_loc@user/sgw> has quit IRC (Quit: Leaving.)07:22
*** sgw <sgw!~swold_loc@user/sgw> has joined #yocto07:23
*** thomasd13 <thomasd13!> has quit IRC (Remote host closed the connection)07:24
*** thomasd13 <thomasd13!> has joined #yocto07:24
LetoThe2ndyo dudX07:29
*** thomasd13 <thomasd13!> has quit IRC (Remote host closed the connection)07:32
*** thomasd13 <thomasd13!> has joined #yocto07:32
*** sgw <sgw!~swold_loc@user/sgw> has quit IRC (Quit: Leaving.)07:37
*** thomasd13 <thomasd13!> has quit IRC (Remote host closed the connection)07:40
*** thomasd13 <thomasd13!> has joined #yocto07: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_!> has joined #yocto07:45
*** thomasd13 <thomasd13!> has quit IRC (Ping timeout: 248 seconds)07:46
*** thomas_ <thomas_!> has quit IRC (Read error: Connection reset by peer)07:49
*** thomasd13 <thomasd13!> has joined #yocto07:49
*** nate02 <nate02!> has quit IRC (Ping timeout: 256 seconds)07:50
*** Wouter010067 <Wouter010067!> has quit IRC (Quit: The Lounge -
*** Wouter010067 <Wouter010067!> has joined #yocto07:50
*** nate02 <nate02!> has joined #yocto08:02
*** thomasd13 <thomasd13!> has quit IRC (Remote host closed the connection)08:09
*** rfuentess <rfuentess!> has joined #yocto08:09
*** thomasd13 <thomasd13!> has joined #yocto08:09
*** thomasd13 <thomasd13!> has quit IRC (Remote host closed the connection)08:11
*** thomasd13 <thomasd13!> has joined #yocto08:11
mcfrisksigh, 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!> has quit IRC (Ping timeout: 265 seconds)08:17
*** thomasd13 <thomasd13!> has joined #yocto08:35
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08: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 #yocto08: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 #yocto08:41
kanavinkhem, the listed pain points are not wrong. But I'm baffled why the actual sales pitch is behind a form.08:52
*** invalidopcode <invalidopcode!> has quit IRC (Remote host closed the connection)08:55
*** invalidopcode7 <invalidopcode7!> has joined #yocto08:55
*** thomasd13 <thomasd13!> has quit IRC (Remote host closed the connection)08:59
*** thomasd13 <thomasd13!> has joined #yocto08:59
*** prabhakarlad <prabhakarlad!> has joined #yocto09:01
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)09:01
*** rfuentess <rfuentess!> has joined #yocto09:02
*** thomasd13 <thomasd13!> has quit IRC (Remote host closed the connection)09:02
*** thomasd13 <thomasd13!> has joined #yocto09:03
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer)09:07
*** kpo_ <kpo_!> 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!> has quit IRC (Ping timeout: 260 seconds)09:11
*** kpo_ <kpo_!> has joined #yocto09:11
kanavinalso, the whole things begs the question, why canonical won't become a yocto vendor ;)09:12
*** amelius <amelius!~quassel@> has joined #yocto09:17
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has joined #yocto09:17
ameliushey, 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/mygpio09:19
ldericherwhat's the cleanest way of installing a package's dependencies without installing (or even building) the package itself?09:22
ldericherpackage -> recipe09:22
qschulzldericher: why would you want to do that?09:23
*** manuel1985 <manuel1985!> has joined #yocto09:23
qschulz(what's the usecase)09:23
neverpanickanavin: why would they? they have their own distro and want to sell you buying your upgrades from them.09:24
ldericherqschulz, 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
neverpanicldericher: probably running the do_configure task, I guess?09:24
ernstpif 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
ldericherqschulz, Also, we might not want any `foo` to be deployed on our development-stage images.09:26
qschulzldericher: I guess you could add the noexec varflag on most tasks of the foo application09:26
*** amitk_ <amitk_!~amit@> has joined #yocto09:26
qschulzldericher: development images very likely should be using a distro anyways09:26
qschulzbut at that point, you might want to create a placeholder foo recipe which is mostly empty except the dependencies09:27
qschulzmaybe use a virtual/package or something09:27
qschulzbut 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 question09:27
LetoThe2ndneverpanic: where does that "some vendors" statement come from?09:28
ldericherqschulz, thanks for the pointers! :)09:28
kanavinneverpanic, 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 them09:29
kanavinany resonable CTO should press them on that point :)09:29
neverpanicLetoThe2nd:, the rightmost box at the bottom09:29
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 260 seconds)09:29
LetoThe2ndneverpanic: lol09:30
kanavinthere's a few words about mender too :)09:30
neverpanickanavin: Red Hat isn't doing that with their edge offerings either, and I guess they see that as their competition09:30
kanavinneverpanic, of course. Vendor lock in.09:30
kanavinit's perfectly doable with open source09:30
LetoThe2ndi 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
neverpanicfull disclosure: I work for Red Hat now (not on edge stuff, though)09:30
rburtoni'm glad redhat dropped their yocto embrace-extend-kill thing09:32
kanavinrburton, they even deleted the repo where the whole disaster was unfolding :)09:32
LetoThe2ndneverpanic: i actually had an interesting call with thed edge people lately.09:33
neverpanicThere 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
neverpanicComing 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
LetoThe2ndkanavin: 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
rburtonneverpanic: short lived meta-rpm layer which basically looked like oe-core but was actually rhel09:36
neverpanicThe 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
rburtonneverpanic: 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
LetoThe2ndneverpanic: 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
kanavinneverpanic, first there are significant technical hurdles too. rhel needs to be reengineered from the ground up to not contain any gpl3 for starters09:37
neverpanickanavin: 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
neverpanicBut, I've been in that boat before, and it was a very leaky one and sinking quickly.09:38
rburtonthis canonical thing is literally the first time ive ever see people claim yocto is good for fast prototyping on embedded boards09:38
kanavinneverpanic, totally. That I fully support.09:38
kanavinthe thing with automotive oems, the whole world is seeing their fumbles and stumbles in trying to become software companies.09:39
kanavinand actual software companies are smelling blood, big time.09:39
kanavinso they all want a piece of that massive pie.09:40
neverpanicI 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
rburtonvery tempted to write a 'reply' to this09:40
rburtonyou can't say that yocto gives you complete control and is very complex, so that obviously means its ideal for quick hacks but nothing else09:40
neverpanicIf you wanna see what happens when automotive companies try to become software companies, look at slide 25:
neverpanicrburton: Go for it, I think this could be a nice "unfakeable linux" moment09:42
kanavinneverpanic, I only need to see that it's about volkswagen on the first slide, no further explanatins needed :)09:42
*** florian <florian!> has joined #yocto09:43
*** manuel1985 <manuel1985!> has quit IRC (Ping timeout: 256 seconds)09:44
*** tomzy_0 <tomzy_0!> has joined #yocto09:46
neverpanicMakes 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
LetoThe2ndneverpanic: 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 runs09:48
neverpanicDunno, 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
LetoThe2ndjust trolling you a bit, no worries :-)09:51
neverpanicOverall probably <100 people. I guess you're just exceptionally lucky to have met many of them? :D09:51
LetoThe2ndor lets say i just meet a lot of people as part of my job, and exceptionally many involved in OTA?09:51
LetoThe2ndneverpanic: full disclosure, in case you didn't know - I'm leading developer relations for Mender :-)09:52
mcfriskBMW 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
neverpanicI didn't know. You must be furiously scratching your head on why we didn't just use something off the shelf, heh?09:53
LetoThe2ndneverpanic: no.09:53
LetoThe2ndmcfrisk: i know, thats how modern systems are most of the time.09:53
LetoThe2ndneverpanic: 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@> has quit IRC (Quit: alessioigor)09:55
*** alessioigor <alessioigor!~alessioig@> has joined #yocto09:55
mcfriskthe complexity of German cars...09:57
neverpanicThere 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
neverpanicmcfrisk: Oh yes! :(09:58
*** thomasd13 <thomasd13!> has joined #yocto10:00
mcfriskCanonical 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 #yocto10: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 file10: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 cache10:07
rburtonphako[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]odd. this was the only job running on jenkins10:10
*** thomasd13 <thomasd13!> has quit IRC (Quit: Leaving)10:10
qschulzphako[m]: no cronjob to remove sstate-cache every now and then?10:11
rburtonphako[m]: i blame jenkins :)10:11
qschulznobody 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 call10:12
phako[m]also I am the only one with access to that server who knows what "bitbake" is and how to call it10:13
*** florian_kc <florian_kc!> has joined #yocto10:14
mcfriskand lol, pay/register walled solutions from Canonical. White or toilet paper...10:15
phako[m]crontab -l10:15
*** nate02 <nate02!> has quit IRC (Read error: Connection reset by peer)10:18
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)10:25
phako[m]and now irt just succeeded10:26
*** alessioigor <alessioigor!~alessioig@> has joined #yocto10:26
phako[m]jenkins ...10:26
tomzy_0<3  I see that love for jenkins is everywhere the same :P10:27
*** creich_ <creich_!> has joined #yocto10:32
*** seninha <seninha!~seninha@user/seninha> has joined #yocto10:55
*** starblue1 <starblue1!> has quit IRC (Ping timeout: 252 seconds)10:57
*** starblue1 <starblue1!> has joined #yocto10:59
rburtonphako[m]: local or http sstate?11:19
phako[m]should be local11:19
rburtonpretend it never happened11:20
phako[m]Thats what I usually do with jenkins11:35
phako[m]finally: Time for lunch11:37
kanavinwhat is it with various Stefans today11:41
kanavinI'm practicing afk with both11:41
*** zpfvo <zpfvo!> has joined #yocto12:00
*** goliath <goliath!~goliath@user/goliath> has joined #yocto12:09
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 265 seconds)12:09
ldericherI 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 #yocto12:19
rburtonldericher: when building a SDK, MACHINE is what the sdk targets and SDKMACHINE is what the sdk runs on12:19
ldericherrburton, is there a generic value for an x64 linux machine?12:20
rburtonthe default is "your current host"12:20
rburtonsee meta/conf/machine-sdk/ for the supported SDKMACHINE values12:21
ldericherso 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!> has joined #yocto12:25
*** g-embed <g-embed!> has quit IRC (Remote host closed the connection)12:26
rburtonthere are two parts to the SDK: the host side (the compiler, the tools) and the target (the sysroot)12:26
rburtonthe former is SDKMACHINE, the latter is MACHINE12:26
*** g-embed <g-embed!~g-embed@user/g-embed> has joined #yocto12:27
*** kpo_ <kpo_!> has quit IRC (Read error: Connection reset by peer)12:27
hsvAre 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 week12:39
*** otavio <otavio!> has quit IRC (Ping timeout: 256 seconds)12:40
*** otavio <otavio!> has joined #yocto12:40
rburtonphako[m]: solid plan12:40
*** Guest4 <Guest4!~Guest4@2001:9e8:2d1:c400:544c:d856:f172:97bc> has joined #yocto12:42
*** Guest4 <Guest4!~Guest4@2001:9e8:2d1:c400:544c:d856:f172:97bc> has quit IRC (Client Quit)12:42
LetoThe2ndphako[m]: you forgot the beers.12:46
phako[m]I am past the need of beer.12:46
*** Guest23 <Guest23!~Guest23@> has joined #yocto12:49
LetoThe2ndphako[m]: join the next Yocto BoF and get some Scotch free!12:50
Guest23Hello. How do I define a new image type?12:52
Guest23What I did so far:12:52
Guest23Added my new type to IMAGE_FSTYPES variable12:52
Guest23Created a image_types_mytype.bbclass class, where I define a IMAGE_CMD_mytype function12:52
Guest23Added my new class to the IMAGE_CLASSES variable12:52
Guest23When 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 function12:52
ThomasRoos[m]Any ideas before the first beer about this:12:55
ThomasRoos[m] | ../xorgproto-2021.5/ 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
rburtonGuest23: have you looked at the existing image_types.bbclass for similar patterns as yours?12:56
rburtonGuest23: hard to debug without seeing anything that you're doing12:56
rburtonThomasRoos[m]: xorgproto?! are you patching or upgrading it?12:56
LetoThe2ndrburton: deleting it.12:57
rburtonLetoThe2nd: ?12:57
rburtonThomasRoos[m]: its not wrong, the binaries are not runnable.  but no idea why it would want to.12:58
LetoThe2ndrburton: just kidding. things that you should do *after* the first beer. delete xorg.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
rburtonour meson does actually support throwing binaries into a qemu-user to run them during the configure but that should work for qemuarm too12: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 system13:01
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 246 seconds)13:01
rburtonah so maybe qemu-user is exploding still13:01
Guest23rburton 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
Guest23ERROR: Unable to parse /home/user/project/sources/meta-openembedded/meta-python/recipes-core/images/meta-python-image.bb13:03', 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
Guest23for 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
Guest23parser = 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.references13:03
rburtonGuest23: can you share what you've done?13:04
Guest23I did exactly what I described earlier13:04
rburtoni mean your new image type13:04
Guest23inherit image_types13:05
Guest23IMAGE_CMD_mytype () {13:05
Guest23IMAGE_TYPEDEP_mytype = "tar.bz2"13:05
Guest23currently this is my image_types_mytype.bbclass13:05
rburtonwith no content?13:05
rburtonand i guess you're using a really old release13:06
Guest23I forgot to mention, I'm using Yocto Dunfell13:06
Guest23There is content but it doesn't really matter, I always get the same parsing error13:06
rburtonremove the inherit, its redundant13:07
Guest23Ok. It doesn't fix the issue though13:08
rburtondoes 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
Guest23what do you mean when I select it?13:09
rburtonwhen you use IMAGE_FSTYPES to pick your image type13:09
*** nemik_ <nemik_!~nemik@> has quit IRC (Ping timeout: 252 seconds)13:09
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto13:09
Guest23Only when I select it13:09
RPGuest23: just guessing but try a single colon in the function13:10
RPGuest23: I suspect the code is struggling with a zero length function13:11
*** nemik_ <nemik_!~nemik@> has joined #yocto13:11
rburtonthere really is content but Guest23  won't share it13:11
rburtonits probably a parse failure in the code but we cant' help there13:11
rburtonturning the function into just a single colon will rule that out though13:12
RPrburton: ah, right. If there is a parse error in code we can't see that would be hard to help with13:12
Guest23The parser get crazy when trying to parse the IMAGE_CMD function, despite its content:13:12
Guest23parser = 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.references13:12", 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
rburtonGuest23: 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
Guest23I'm sure the content of the IMAGE_CMD function is not the problem. I even tried the different syntax:13:14
Guest23IMAGE_CMD_mytype = ""13:14
Guest23instead of13:14
Guest23IMAGE_CMD_mytype () {13:14
rburtonright it might be something else in the file13:14
rburtonwhich if you share we can look at13:14
rburtonyou're literally giving the vaguest impression of what you've got and asking us to debug it13:14
Guest23There isn't much more to the file, as I showed previously13:14
rburtonso pastebin the literal contents then?13:15
rburtonif i can have the file and replicate the problem then we can fix the problem and see if the error reporting can be improved13:15
Guest23it's literally 3 sloc and I get a parsing error13:15
qschulzGuest23: IMAGE_CMD_mytype () {} is not valid13:16
qschulzIMAGE_CMD_mytype () {:} would be though13:16
rburtonyeah we've done that :)13:16
qschulzsent on the chan literally 2min ago /me shrugs13:17
Guest23As I said I created this image_types_mytype.bbclass13:17
Guest23Added the class to the IMAGE_CLASSES variable13:17
Guest23And added the type to the IMAGE_FSTYPES variable13: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
Guest23Simple as that13:18
rburtoncomment out the TYPEDEP line, that's not often used and might have broken13:18
Guest23Same problem13:18
qschulzdon'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
qschulzI'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
rburtonso i have a image_type_foo.bbclass which just contains:13:21
rburtonIMAGE_CMD:foo () {13:21
rburton    bbwarn FOOBAR13:21
rburtonadded to IMAGE_CLASSES, set IMAGE_FSTYPES13:22
rburtonWARNING: core-image-minimal-1.0-r0 do_image_foo: FOOBAR13:24
rburtonall 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 layers13:25
Guest23IMAGE_FSTYPES += "tar.bz2 ubi wic.bz2 mytype"13:27
Guest23IMAGE_CLASSES += "image_types_mytype"13:27
Guest23Just added this to my meta-mylayer/conf/machine/mydistro.conf13:27
rburtoni'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!> has quit IRC (Remote host closed the connection)13:39
*** invalidopcode7 <invalidopcode7!> has joined #yocto13:39
*** Guest23 <Guest23!~Guest23@> has quit IRC (Ping timeout: 260 seconds)13:40
tomzy_0how 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
qschulzbitbake -g <my-image> and check the dot files with your favorite text editor, that's how I would do it13:41
qschulztomzy_0: ^13:42
tomzy_0I feared that this will be the answer, think that it is time to learn how to read that file :P13:43
tomzy_0qschulz task on left of `->` was run because of task on right of `->`?13:46
qschulzI don't remember, but look at one do_compile and check where the do_configure is, do_configure is run because of do_compile13:47
tomzy_0makes sense13:48
tomzy_0thanks once again13:48
g-embedOK, so I need some help with kernel development if someone's up for it.13:49
*** mckoan_ <mckoan_!> has joined #yocto13:49
*** xmn <xmn!> has joined #yocto13:49
rburtontomzy_0: about ten minutes in13:49
rburtontldr: oe-depends-dot13:50
qschulzg-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 here13:50
rburtontomzy_0: stuff like connman gets in via packagegroups13:50
g-embedWell it's linux-yocto related13:51
tomzy_0rburton: yeap, got it, it was `packagegroup-core-tools-testapps`13:51
tomzy_0but I dont think I heard about `oe-depends-dot --why --key` before13:51
tomzy_0need to check that13:51
rburtonwhich comes in via an image feature13:51
g-embedIn 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-embedSecondly I need to provide a device-tree for the peripheral in question.13:52
*** mckoan|away <mckoan|away!> has quit IRC (Ping timeout: 255 seconds)13:52
qschulzg-embed: I believe config fragments should answer your first question13:53
rburtonif you're using linux-yocto then is the best solution13:53
g-embedI 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
qschulzfor 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 dtses13:54
g-embedDevice 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
rburtonyou set KERNEL_DEVICETREE to the devicetree filename iirc13:54
*** sakoman <sakoman!> has joined #yocto13:54
g-embedIt 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-embedIt = 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!> has quit IRC (Ping timeout: 256 seconds)13:56
g-embedI.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
qschulzg-embed: something in the bootloader will pick the proper device tree13:58
qschulzthat's device specific so cannot help here13:58
g-embedqschulz, 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
qschulzg-embed: yes dts is only a source file, dtb is the blob, usable by the kernel13:59
g-embedOK, I'll look at bootloader then.  I suppose the alternative is to try to patch my dts into the already used <MACHINE>.dts13:59
qschulzthat's one way yes13:59
qschulzit depends in the end13:59
qschulzbecause if MACHINE is actually your HW, it makes sense14:00
qschulzif MACHINE is just a devkit/base whatever your vendor gave you and you have a different product14:00
qschulzyou should create another machine.conf file for your specific machine14:00
qschulzand in that scenario you don't need to append the KERNEL_DEVICETREE but just set it14:00
qschulzand if the Yocto layers are done correctly by your vendor, it should just boot your dtb then automagically14:01
qschulzI believe the first entry in KERNEL_DEVICETREE is usually the default dtb14:01
qschulzso maybe doing a :prepend instead of an :append might do the trick14:01
qschulz(don't forget the trailing space for the prpend)14:01
*** xmn <xmn!> has joined #yocto14:02
g-embedYeah 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-embedSo... first attempt is to just extend the MACHINE they have.14:04
g-embedOK, 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}/.config14:05
brabanderdoes anyone know an good example project that uses multiconfig ?14:05
g-embedI'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-embedThis 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
qschulzg-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
qschulzI've not used config fragments yet for multiple reasons (some of which are apparently not true anymore/were never true)14:08
qschulzso I cannot help there :/14:08
g-embedYeah, 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-embedso... 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
qschulzg-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
RPg-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 defconfig14:10
g-embedThanks 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-embedSorry, these are basic questions, but how does "defconfig" relate to .config in a kernel build?14:11
RPg-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-embedI mean ultimately, I just want to provide ONE actual full config file, and have that be used.14:11
RPg-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 though14:12
g-embedRP, They are specifying a custom task to copy it to ${B}/.config14:13
qschulzg-embed: you could have your own defconfig in your own layer by making sure to have a bbappend with FILESEXTRAPATHS:prepend in there14:13
g-embedI 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
RPg-embed: so can you change the input file to that?14:13
qschulzand that the layer priorities and/or order for your layer makes Bitbake take your defconfig over your vendor's14:14
g-embedRP, 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 there14:14
qschulzg-embed: small tip 1) you can check the config used by Bitbake by running bitbake -c menuconfig virtual/kernel14:15
g-embedqschulz, good, haven't tried that14:15
qschulzg-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 well14:15
g-embedyeah 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
RPg-embed: without knowing which make targets their recipe calls, it is hard for us to know either :(14:15
RPJPEW: FWIW you shouldn't need since it combines all the parser thread profiles into a single processed log14:18
JPEWRP: Ah I must have missed that14:19
*** Wouter010067 <Wouter010067!> has quit IRC (Quit: The Lounge -
*** Wouter010067 <Wouter010067!> has joined #yocto14:20
RPJPEW: that way you get the average over all the parsing processes which I'd figured was probably the more useful thing14:21
RPJPEW: do you have much experience with python memory usage? I was wondering if we can easily benchmark that14:24
JPEWI don't14:24
qschulzis there not a python memory profiler that was released a few months ago?14:24
RPqschulz: probably, I was just hoping someone would just know how to do it :)14:25
* RP did this before but years ago14:25
RPI think I'm going to focus on sorting the python function move, then come back to this14:26
qschulzRP: I believe it was this one that made thew news some months ago:
RPqschulz: thanks, will have to have a look!14:32
g-embedRP, fully understood, you are all doing great.14:33
g-embedI don't seem to see any special make target stuff.  meta-VENDOR appends to linux-imx:   which includes which inherits kernel.bbclass so from there it's standard I suppose.14:34
qschulzg-embed: kernel-yocto is actually the fancy one with config fragment support14:35
g-embedAh right. So kernel.bbclass is older?14:35
qschulzg-embed: linux-yocto uses this fancy class, vendor recipes usually not so much14:35
qschulzg-embed: they are complimentary IIRC14:35
qschulzall kernel recipes should inherit kernel in some ways14:35
qschulzkernel-yocto class adds some more nice things to it14:36
qschulzlinux-yocto vs linux-imx!14:36
g-embedWell, 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-embedThe 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
qschulzg-embed: tbf, the kernel configuration is pretty hard14:38
RPg-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 investigate14:38
qschulzand 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 layer14:40
g-embedOK, so looking at some of my older attempts it doesn't seem like the copy works.14:45
g-embedso 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-embedMy BBFILE_PRIORITY is higher, i.e. my append runs after vendor.14:48
*** Guest1396 <Guest1396!> has quit IRC (Ping timeout: 264 seconds)14:50
LetoThe2ndcompletely 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-embedI'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!> has quit IRC (Quit: xmn)14:56
*** sotaover1ide <sotaover1ide!> has joined #yocto14:57
*** xmn <xmn!> has joined #yocto15:04
*** kscherer <kscherer!> has joined #yocto15: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!> has quit IRC (Quit: Client closed)15:39
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto15:49
*** nemik_ <nemik_!~nemik@> has quit IRC (Ping timeout: 256 seconds)15:49
*** nemik_ <nemik_!> has joined #yocto15:49
*** nemik_ <nemik_!> has quit IRC (Ping timeout: 246 seconds)15:53
*** nemik_ <nemik_!~nemik@> has joined #yocto15: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@> has joined #yocto16:01
*** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:853d:6d6e:a5ed:c2ea> has joined #yocto16:01
*** prabhakarlad <prabhakarlad!> has joined #yocto16:06
*** seninha <seninha!~seninha@user/seninha> has joined #yocto16:08
*** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:853d:6d6e:a5ed:c2ea> has quit IRC (Ping timeout: 256 seconds)16:10
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Ping timeout: 260 seconds)16:20
*** alessioigor <alessioigor!~alessioig@> has joined #yocto16:21
*** GillesM <GillesM!> has quit IRC (Quit: Leaving)16:31
*** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:853d:6d6e:a5ed:c2ea> has joined #yocto16:41
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 265 seconds)16:44
*** florian <florian!> 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@> has quit IRC (Quit: alessioigor)16:50
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)16:52
*** g-embed <g-embed!> has joined #yocto17:12
*** amelius <amelius!~quassel@> has quit IRC (Quit: - Chat comfortably. Anywhere.)17:19
RPJPEW: I think multiconfig is broken with hash equivalence :( I can't see any handling of mc in the report_unihash function17:34
RPWe've bolted too much new code around old crumbling APIs17:36
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 248 seconds)17:36
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto17:38
*** hcg <hcg!~hcg@> has joined #yocto17:45
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 264 seconds)17:45
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto17:47
hcgI wonder if there is anyone out there using meta-ti who understands how the kernel config is constructed?17:48
abelloniI despise vendor that have their own do_configure17:51
JPEWRP: I'm not sure that was entirely omitted on accident17:53
JPEWRP: But it depends on which part?17:54
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 260 seconds)17:55
RPJPEW: 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 that17:56
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto17: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 idea18:02
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 256 seconds)18:04
RPAll because I wanted to write out the sigs before and after my python function change so I could check what I was doing was working18:05
* RP gives up bit and finds food18:06
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto18: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 #yocto18:13
*** nemik_ <nemik_!~nemik@> has quit IRC (Ping timeout: 246 seconds)18:19
*** nemik_ <nemik_!> has joined #yocto18:19
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 256 seconds)18:23
*** nemik_ <nemik_!> has quit IRC (Ping timeout: 268 seconds)18:24
*** nemik_ <nemik_!~nemik@> has joined #yocto18:24
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto18:25
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 260 seconds)18:30
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto18:31
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)18:31
*** vvn <vvn!> has quit IRC (Quit: WeeChat 3.7.1)18:33
*** vvn <vvn!> has joined #yocto18:34
*** otavio <otavio!> has quit IRC (Ping timeout: 268 seconds)18:36
*** otavio <otavio!> has joined #yocto18:37
*** florian_kc <florian_kc!> has joined #yocto18:38
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto18:40
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 260 seconds)18:44
*** malsyned <malsyned!~IceChat95@> has joined #yocto18:54
*** Wouter010067 <Wouter010067!> has quit IRC (Quit: The Lounge -
*** Wouter010067 <Wouter010067!> has joined #yocto18:55
*** malsyned <malsyned!~IceChat95@> has quit IRC (Ping timeout: 268 seconds)19:06
*** florian_kc <florian_kc!> has joined #yocto19:14
*** vladest <vladest!> has joined #yocto19:22
*** vladest <vladest!> has quit IRC (Read error: Connection reset by peer)19:24
*** arielmrmx <arielmrmx!~quassel@> has quit IRC (Remote host closed the connection)19:36
*** grsandeep85 <grsandeep85!~grsandeep@> has joined #yocto19:42
*** invalidopcode7 <invalidopcode7!> has quit IRC (Remote host closed the connection)19:50
*** invalidopcode7 <invalidopcode7!> has joined #yocto19:50
*** grsandeep85 <grsandeep85!~grsandeep@> has quit IRC (Quit: Client closed)19:50
*** grsandeep85 <grsandeep85!~grsandeep@> has joined #yocto19:55
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 252 seconds)19:59
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)20:00
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 246 seconds)20:05
*** mckoan_ <mckoan_!> has quit IRC (Read error: Connection reset by peer)20:12
*** mckoan|away <mckoan|away!> has joined #yocto20:17
*** malsyned <malsyned!~IceChat95@> has joined #yocto20:25
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 252 seconds)20:33
*** malsyned <malsyned!~IceChat95@> has quit IRC (Ping timeout: 256 seconds)20:36
*** malsyned <malsyned!~IceChat95@> has joined #yocto20:43
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Ping timeout: 260 seconds)20:44
*** DvorkinDmitry <DvorkinDmitry!~dvorkin@> has quit IRC (Remote host closed the connection)20:49
*** malsyned <malsyned!~IceChat95@> has quit IRC (Ping timeout: 268 seconds)20:50
*** seninha <seninha!~seninha@user/seninha> has joined #yocto21:09
kiwi_29_[m] reposting for some/any insight21: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 sdk21:14
kiwi_29_[m]I do see some code related to this in meta/recipes-core/meta/ , but I am not sure how to use it to include go 1.19 in the sdk21:14
kiwi_29_[m]I m wondering how was this recipe included previously when I compiled toolchain using bitbake -c populate_sdk DISTRO_NAME21:14
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto21:27
*** xmn <xmn!> has joined #yocto21:30
*** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:c580:4e9c:fb23:2c28> has joined #yocto21: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 #yocto21:46
*** nemik_ <nemik_!~nemik@> has quit IRC (Ping timeout: 268 seconds)21:49
*** nemik_ <nemik_!> has joined #yocto21:49
*** nemik_ <nemik_!> has quit IRC (Ping timeout: 260 seconds)21:54
*** nemik_ <nemik_!~nemik@> has joined #yocto21:54
*** florian_kc <florian_kc!> has joined #yocto21:59
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 255 seconds)22:02
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 256 seconds)22:15
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto22:23
*** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:c580:4e9c:fb23:2c28> has joined #yocto22: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@> has quit IRC (Quit: Client closed)22:43
*** kscherer <kscherer!> has quit IRC (Quit: Konversation terminated!)22:43
*** grsandeep8574 <grsandeep8574!~grsandeep@> has joined #yocto23:10
*** grsandeep8574 <grsandeep8574!~grsandeep@> has quit IRC (Client Quit)23:10
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)23:14
*** malsyned <malsyned!~IceChat95@2601:19c:5080:af10:c580:4e9c:fb23:2c28> has joined #yocto23: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!> has joined #yocto23:23
RPkiwi_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
RPkiwi_29_[m]: I don't remember dunfell, it was different but hopefully that gives a hint of where/what to look for23:26
*** money_ <money_!~money@user/polo> has joined #yocto23:59

Generated by 2.17.2 by Marius Gedminas - find it at!