LetoThe2nd changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Community: https://www.yoctoproject.org/community | IRC logs: http://irc.yoctoproject.org/irc/ | Having difficulty on the list, with someone on the list or on IRC, contact Yocto Project Community Manager Letothe2nd | CoC: https://www.yoctoproject.org/community/code-of-conduct
<pidge> RP: on qemumips (which is the slowest to fully render), seven seconds between dbus-wait org.matchbox_project.desktop Loaded returning and the screen being entirely rendered :(
<RP> pidge: I wonder if rburton has any thoughts on that :/
<RP> it is what it was meant for :(
<pidge> RP: I'm thinking that what I probably need to be doing is tapping into qmp signals instead of dbus. ie. I don't think it's a sato issue, it's how we're invoking display for qemu.
roussinm has quit [Quit: WeeChat 3.8]
<pidge> To further prove this theory, wiping out qb_graphics and the diff between the dbus-wait is negligable.
<RP> pidge: I don't know I'm afraid. I just knew we had that signal
* RP should sleep
goliath has quit [Quit: SIGSEGV]
rsalveti has quit [Quit: Connection closed for inactivity]
Daanct12 has joined #yocto
davidinux has quit [Ping timeout: 245 seconds]
davidinux has joined #yocto
ablu has quit [Read error: Connection reset by peer]
kystncode has joined #yocto
ablu has joined #yocto
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #yocto
lthadeus has joined #yocto
Minvera has quit [Ping timeout: 260 seconds]
jmd has joined #yocto
astlep550401 has joined #yocto
Chaser has joined #yocto
astlep550401 has quit [Quit: The Lounge - https://thelounge.chat]
Chaser has quit [Read error: Connection reset by peer]
Chaser has joined #yocto
astlep550401 has joined #yocto
kystncode has quit [Quit: Quit]
Vonter has quit [Ping timeout: 245 seconds]
Vonter has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
sng has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
sng has joined #yocto
mvlad has joined #yocto
Chaser has quit [Quit: Chaser]
jmd has quit [Remote host closed the connection]
Chaser has joined #yocto
Chaser has quit [Client Quit]
Chaser has joined #yocto
Chaser has quit [Client Quit]
Kubu_work has joined #yocto
frieder has joined #yocto
zpfvo has joined #yocto
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
wak has quit [Quit: ZNC - https://znc.in]
wak has joined #yocto
Saur has quit [Ping timeout: 264 seconds]
leon-anavi has joined #yocto
Chaser has joined #yocto
vladest has quit [Ping timeout: 245 seconds]
Saur has joined #yocto
lthadeus has quit [Ping timeout: 260 seconds]
<dvergatal> RP: OK I have tested it and patchest applied are not solving the issue regarding proper order of postinst calls
lthadeus has joined #yocto
<RP> dvergatal: "it" being the master patches or the proposed one on the list?
<RP> the ones in master were never claimed to fix the postinst order
vladest has joined #yocto
bradfa has quit [Ping timeout: 255 seconds]
bradfa has joined #yocto
alessioigor has joined #yocto
mdp has quit [Ping timeout: 256 seconds]
mdp has joined #yocto
<dvergatal> > 18:32 < dvergatal> RP: but it is written in here https://git.yoctoproject.org/poky/commit/?id=ecef665062be55fcfa0915216335d08883aa86f7 for that Bug 13904 and Bug 15084 it fixes the effects
<dvergatal> RP: I need to check something else because I have some suspicions
khem has quit [Ping timeout: 255 seconds]
<RP> pidge: I said this would cause problems :(
<RP> dvergatal: it only fixes 13904. It may help 15084 but does not fix it
<RP> 15084 remains open and actually has other patches on the list
<RP> that commit message should really say "fixes issues potentially related to:"
lthadeus has quit [Ping timeout: 246 seconds]
<dvergatal> RP: 13904 is the order of postinst-*
<dvergatal> RP: OK
<rburton> pidge: what did you change to stop the delta between the signal and the desktop actually finished being so long?
<rburton> i can't remember where that signal is fired but it shouldn't be doing much after. but maybe it needs to be shifted slightly.
<rburton> an alternative would be to take shots every few seconds until it stops changing
khem has joined #yocto
<rburton> as you'll need something like that for "clicked on <app>" where you don't get a magic dbus signal
prabhakarlad has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
olani has quit [Remote host closed the connection]
olani has joined #yocto
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
jonesv has quit [Remote host closed the connection]
raghavgururajan has quit [Remote host closed the connection]
tleb has quit [Remote host closed the connection]
raghavgururajan has joined #yocto
jonesv has joined #yocto
tleb has joined #yocto
neofutur_ has quit [Ping timeout: 256 seconds]
<dvergatal> RP: If I run `bitbake package -e variables.txt` i should be able to see USERADD_DEPENDS for that specific package?
<RP> dvergatal: sorry, you're right, yes. It doesn't fix that. I meant the other 13XXX bug :/
<dvergatal> RP: ahhhh:P so the commit message is wrong
vladest has quit [Remote host closed the connection]
<RP> dvergatal: as I said, " that commit message should really say "fixes issues potentially related to:""
vladest has joined #yocto
neofutur_ has joined #yocto
<dvergatal> RP: sure, n/p but I was thinking it fixes but it's not
<dvergatal> maybe not entirely
<RP> dvergatal: it is related but not entirely fixes all the issues
<dvergatal> RP: yeah
camus has quit [Ping timeout: 276 seconds]
camus1 has joined #yocto
<RP> and yes, bitbake -e <recipe> should show USERADD_DEPENDS if you set that in the recipe
<dvergatal> RP: so the funny thing is that i have it set in recipe and
<dvergatal> 11:56 < dvergatal> maybe not entirely
<dvergatal> sorry stupid 3rd mice button
<dvergatal> RP: bitbake -e <recipe> returns me USERADD_DEPENDS = "" but it is set in that recipe
camus1 is now known as camus
<RP> dvergatal: before or after the inherits?
<dvergatal> one sec
<dvergatal> after
<dvergatal> ahhhh that is why ok
<dvergatal> RP: yay, you were right stupid me
<dvergatal> RP: nevertheless what in case if one package listed in USERADD_DEPENDS has in its body also its own USERADD_DEPENDS?
<RP> dvergatal: that should work?
<dvergatal> RP: how should I know?
dmoseley has quit [Quit: ZNC 1.8.2 - https://znc.in]
dmoseley has joined #yocto
wak has quit [Quit: ZNC - https://znc.in]
sakman has quit [Read error: Connection reset by peer]
wak has joined #yocto
khem has quit [Ping timeout: 245 seconds]
jonesv has quit [Write error: Connection reset by peer]
tleb has quit [Read error: Connection reset by peer]
raghavgururajan has quit [Write error: Connection reset by peer]
khazakar has quit [Read error: Connection reset by peer]
raghavgururajan_ has joined #yocto
tleb has joined #yocto
jonesv_ has joined #yocto
camus1 has joined #yocto
sakman has joined #yocto
khem has joined #yocto
khazakar has joined #yocto
jonesv_ is now known as jonesv
sng has quit [Quit: No Ping reply in 180 seconds.]
sng has joined #yocto
davidinux has quit [Ping timeout: 245 seconds]
davidinux has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus1 is now known as camus
<dvergatal> RP: I think that because of the order it was also not working for me on kirkstone:P
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
arkanoid has joined #yocto
<arkanoid> hello!
<arkanoid> I'm new to yocto. What's the go-to layer to handle network-related stuff when LTE/modem comes into play?
<arkanoid> nor qmi, or other modem drivers
alessioigor has quit [Quit: alessioigor]
<ablu> arkanoid: You might want to try the recipe search: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=modemmanager
alessioigor has joined #yocto
<dvergatal> arkanoid: meta-openembedded
<dvergatal> arkanoid: recipes-connecitvity
alessioigor has quit [Quit: alessioigor]
rty has joined #yocto
<rty> hi, people. I was wondering, is it possible to dynamically add a layer (akin to what you would do manually in conf/bblayers.conf) directly from the command line, without editing files?
<rty> with temporary effect only for that command's execution
IB1387 has joined #yocto
IB1387 has quit [Client Quit]
IB1387 has joined #yocto
<RP> rty: there are the -r and -R options to bitbake which specific conf files to read before and after bitbake.conf but nothing for bblayers.conf that I know of
<RP> s/specific/specify/
speeli has joined #yocto
prabhakarlad has quit [Quit: Client closed]
goliath has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
xmn has joined #yocto
alperak has joined #yocto
<dvergatal> RP: btw. how can I override `inherit useradd` in case of bbappend? meaning that I have some recipe from some layer which already has this inherit and I want to also set USERADD_DEPENDS in this bbappend?
<rty> RP: thanks! I'll try
<IB1387> Hi, I hope it's fine for me to ask a quick question here! I'm trying to patch a file in u-boot. I've created the bbappend and patch files using devtool. When building, bitbake throws an error that the patch file couldn't be applied. I think it's applying mulitple patches to the same file in the wrong order. My patch should be the last one to be
<IB1387> applied, but from the log it seems that it get's applied before a patch in meta-mender-raspberrypi.
ablu-lin- has joined #yocto
vvmeson has joined #yocto
vmeson has quit [Ping timeout: 252 seconds]
ablu-linaro has quit [Ping timeout: 252 seconds]
<dvergatal> RP: can I `inherit useradd` twice ?
<LetoThe2nd> IB1387: so you want to have mender + raspberrypi + additional patches?
lthadeus has joined #yocto
<RP> dvergatal: you can but it won't help :/
<IB1387> LetoThe2nd I need to patch configs/rpi_arm64_defconfig in u-boot. There is a patch in meta-mender-raspberrypi/recipes-bsp/u-boot/ that alters the same file. The problem seems to be, that my patch get's applied before the patch from meta-mender-raspberrypi is applied. When I created my patch using devtool, the patch from meta-mender-raspberrypi is
<IB1387> already applied in the workspace.
<IB1387> So I guess yes, I want all patches to be applied in series in the correct order.
<pidge> rburton: on qemumips I blanked out qb_graphics from vga std. The problem isn't a sato issue I don't think, it's a qemu issue in that the screen rendering is just taking too long.
<rburton> i wonder if mips can be told to do virtio vga
<LetoThe2nd> IB1387: I see. hm. We've had a situation like that when layer priorities were interfering. Is your layer bumped up there?
alessioigor has joined #yocto
<IB1387> LetoThe2nd I'm already searching for some time for a solution and tried to play with layer prios, setting my layer priority (`BBFILE_PRIORITY_mylayer` in layer.conf) to the highest or lowest number of all present layers didn't seem to change anything concerning the patch order. The priority was correctly updated in `bitbake-layers show-layers`
<IB1387> though.
vvn has quit [Ping timeout: 252 seconds]
sgw has quit [Ping timeout: 252 seconds]
<LetoThe2nd> IB1387: so its not just the patch order, its actually the append ordering?
jmiehe has joined #yocto
sgw has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.1.2]
vvn has joined #yocto
<dvergatal> RP: hmmm so it is not possible to modify recipe with bbappend and I must do that within original recipe?
<IB1387> LetoThe2nd I'm not sure how bitbake does the applying of the patches. I want to only apply a single patch myself. Does it collect all patches of all bbappends
<IB1387> LetoThe2nd Does it collect all patches of all bbappends and applies them in order after? Or does it process one bbappend file, apply it's patches and then continues with the next one?
<arkanoid> ablu: thanks
<RP> dvergatal: USERADD_DEPENDS is set with ??= so any other setting of the variable should override it
<IB1387> LetoThe2nd when I set the priority to 1, my bbappend file is listed first in `bitbake-layers show-appends`, when I set the prio to 20, it's listed last in the same command. So the priority change at least does something.
<LetoThe2nd> IB1387: my understanding is that patches are applied in the order in which they appear in at SRC_URI
<LetoThe2nd> IB1387: set it to the same prio as meta-mender and meta-mender-raspberrypi :)
<LetoThe2nd> IB1387: I agree that we should improve the documentation there.
<IB1387> LetoThe2nd alright, I'll try that this afternoon. I have an appointment now but will go back to debugging later. Thanks so far, I'll report the results :-)
<LetoThe2nd> IB1387: thanks. You can of course ping me here, but if nobody is responsive please drop it on hub.mender.io. three days to xmas is probably not a great time to get people taking a look but I can always try.
<dvergatal> RP: yeah I'm just thinking out loud
IB9 has joined #yocto
IB9 has quit [Client Quit]
IB1387 has quit [Ping timeout: 250 seconds]
rty has quit [Ping timeout: 250 seconds]
rty has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
ptsneves has joined #yocto
davidinux has quit [Ping timeout: 256 seconds]
rty has quit [Quit: Client closed]
vvmeson is now known as vmeson
Minvera has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
lthadeus has quit [Ping timeout: 245 seconds]
rm5248 has joined #yocto
ptsneves has quit [Ping timeout: 256 seconds]
manuel_ has quit [Remote host closed the connection]
manuel_ has joined #yocto
zpfvo has joined #yocto
IB1387 has joined #yocto
<IB1387> LetoThe2nd hi again, I changed the priority of my layer to 10 (the same that meta-mender-raspberrypi has, which contains the patch file that needs to be used before my own). Sadly, same error.
<LetoThe2nd> IB1387: so if you do bitbake-getvar -r u-boot SRC_URI, then the order is garbled?
<abelloni> khem: I'm dropping the patches that were on your branch, there is no particular issue with them but you will need to send them on the ML
<IB1387> Yes, the order of patch files in SRC_URI is not the order that I want them to be applied in.
<LetoThe2nd> IB1387: ok, and bitbake-layers show-appends should correlate to that, hence by priority you should get your patch into the correct place. but this doesn't work?
<IB1387> LetoThe2nd and the layer priority does not seem to make a difference for the content of the SRC_URI variable. SRC_URI stays the same when setting the layer prio to 1 (lower than everything else), 10 (equal to meta-mender-raspberrypi) or 20 (higher than everything else)
<IB1387> The layer prio DOES make a difference to bitbake-layers show-appends! When setting the prio of my layer to 20, my bbappend file is listed last, when I set the prio to 10 my bbappend file is put above the meta-mender-raspberrypi one.
<LetoThe2nd> IB1387: i'm out of ideas slowly, sorry. last thing that comes to my mind, are you using a different operation to add to SRC_URI than meta-mender-raspberrypi does? e.g. += vs. :append
<IB1387> LetoThe2nd That's exactly what I was thinking now too. And that has to be it:
<IB1387> I'm using the default devtool way of doing the bbappend using SRC_URI += ...
<IB1387> meta-mender-raspberrypi/recipes-bsp/u-boot/u-boot-raspberrypi.inc sets SRC_URI a litte bit more convoluted:
<IB1387> ```
<IB1387> SRC_URI:append:rpi:mender-uboot = "${@bb.utils.contains('MENDER_UBOOT_AUTO_CONFIGURE', \
<IB1387>                                                         '1', \
<IB1387>                                                         '', \
<IB1387>                                                         ' file://0001-configs-rpi-enable-mender-requirements.patch \
<IB1387>                                                         ', \
<IB1387>                                                         d)}"
<IB1387> ```
<IB1387> LetoThe2nd sorry, I hoped that this would be able to show markdown :-D
<LetoThe2nd> IB1387: irccloud made it pretty enough :-)
Guest49 has joined #yocto
Guest49 has left #yocto [#yocto]
<LetoThe2nd> IB1387: I don't usually work with devtool, so I can just guess here. The meta-mender-raspberrypi one looks convoluted, but actually is relatively simple at its heart. for your case, can you just change your recipe to a classic SRC_URI:append = "xxxx-your_thing.patch"?
vladest has quit [Quit: vladest]
<IB1387> LetoThe2nd Yes, I'm trying that right now. Seems to work at least inside the `kas shell` environment I'm currently using. I'll include the changes properly in my layer repos and will report back :-)
<LetoThe2nd> IB1387: cool!
<LetoThe2nd> IB1387: for the reasons behind it: += operations take place in an earlier processing stage than :append ones.
<IB1387> yes, I've seen the video you recommended when we did our call. Now that I know what's the issue, it seems obvious. We are still trying to learn the ropes here when it comes to bitbakes inner workings. :-)
zpfvo has quit [Ping timeout: 264 seconds]
<LetoThe2nd> :-)
zpfvo has joined #yocto
<LetoThe2nd> glad to see you're progressing!
<RP> abelloni, khem: the issue is the Upstream-Status Pending ;-)
jmiehe has quit [Remote host closed the connection]
vladest has joined #yocto
xmn has quit [Quit: ZZZzzz…]
frieder has quit [Remote host closed the connection]
xmn has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
samkent has joined #yocto
rsalveti has joined #yocto
<IB1387> LetoThe2nd Everything seems to work corretly now. Thanks a lot for the help!
<LetoThe2nd> IB1387: YAY! thanks for reporting back, have fun then!
vladest has quit [Remote host closed the connection]
<IB1387> Thank you and marry christmas of course!
speeli has quit [Quit: Client closed]
vladest has joined #yocto
xmn has quit [Ping timeout: 240 seconds]
IB1387 has quit [Quit: Client closed]
lthadeus has joined #yocto
davidinux has joined #yocto
goliath has quit [Quit: SIGSEGV]
lthadeus has quit [Quit: Leaving]
lthadeus has joined #yocto
* LetoThe2nd actually married somebody else. And this would make for a really bad old white male James Bond reference.
prabhakarlad has joined #yocto
amitk has joined #yocto
<dvergatal> RP: yeah it is working now on kirkstone as well but the order of postinst-* calls is not fixed with it
florian has quit [Quit: Ex-Chat]
zeddii has quit [Ping timeout: 268 seconds]
jmd has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
zeddii has joined #yocto
lthadeus has quit [Quit: Leaving]
zpfvo has quit [Quit: Leaving.]
<jdiez> do all files installed in the root filesystem come from a package? i.e. in theory I could update a device with runtime PM by diffing package manifests between versions?
samkent has quit [Ping timeout: 256 seconds]
ptsneves has joined #yocto
ptsneves has quit [Read error: Connection reset by peer]
ptsneves1 has joined #yocto
ptsneves1 is now known as ptsneves
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<dvergatal> RP:
<dvergatal> 18:50 -!- alessioigor [~alessioig@185.178.95.240] has joined #yocto
leon-anavi has quit [Quit: Leaving]
<dvergatal> 18:50 -!- alessioigor [~alessioig@185.178.95.240] has joined #yocto
<dvergatal> RP: I think that despite your corrections, Jan's patch is necessary to fix #13904
<dvergatal> stupid mice...
<dvergatal> mice/mouse/whatever :P
<rburton> jdiez: _most_. some files in the rootfs may be touched by the rootfs post-install scripts. depends on your image.
<jdiez> I see, thanks!
<rburton> jdiez: if you want to do on-device updates in production then i'd recommend something more resilient than the package manager. swupdate/mendor/raux and more are all better.
<RP> dvergatal: the postinst ordering isn't fixed yet
<jdiez> rburton: yeah, I'm evaluating these too, but in my application (linux on satellites) sending a whole new rootfs image is slow
<rburton> jdiez: sure, they can send incremental changes
<rburton> on satellites i wouldn't want to rely on something as fragile as a bare package manager
<jdiez> my thinking so far is to have a base image flashed to the device, and then install any application software as packages. then we only need to send changed packages for updates
alperak has quit [Ping timeout: 250 seconds]
<rburton> sounds like a proper A/B updater would be good, so you always have a good image and can roll back if needed
<jdiez> yeah, would also use a/b system partitions
<yudjinn> moto-timo: you around? had a question about the layer index
<jdiez> the problem with swupdate's differential update thing is that the device requests chunks from the server, not the other way around, and that's also less practical in my case
<yudjinn> I am running the layer index container locally, and after adding a layer it says it needs to index, but it's been almost 20 hours and no recipes yet
ptsneves has quit [Read error: Connection reset by peer]
<jdiez> mender does support diffing two rootfs and only sending that, but that is also somewhat clunky
<dvergatal> RP: yeah that's how I finally figured it out
<dvergatal> :P
<jdiez> ideally a (third party?) software developer can make a package for my target using the extended sdk and it should be easy to send that up to the sat
ptsneves has joined #yocto
<jdiez> oh, mender's diff thing is also closed source
Chaser has quit [Quit: Chaser]
rsalveti has quit [Quit: Connection closed for inactivity]
frosteyes has quit [Ping timeout: 268 seconds]
frosteyes has joined #yocto
amitk has quit [Remote host closed the connection]
<dvergatal> RP: OK it has finally built in addition whit this https://bugzilla.yoctoproject.org/attachment.cgi?id=4972&action=diff patch
<dvergatal> RP: because generally this patch works, but sometimes build crashes when do_populate_sysroot_setscene is called...
<moto-timo> yudjinn: update.py —help will give you the options
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
Nonkel has joined #yocto
<Nonkel> Hello
<Nonkel> I try to addapd the kernel with the follow in cmd: bitbake -c menuconfig virtual/kernel but no GUI popups, what do I wrong?
Kubu_work has quit [Quit: Leaving.]
jmd has quit [Remote host closed the connection]
GNUmoon has joined #yocto
alperak has joined #yocto
<khem> RP: yeah I am aware of it, working though it one by one
<khem> RP: some of the problems are long standing which this change is bringing to front see the elfutils discussion, so its taking time
Nonkel has quit [Ping timeout: 250 seconds]
<khem> if you are fine to apply it or wait its ok, I will regardless working them into respective upstreams
<khem> alpine has the same issues
<LetoThe2nd> jdiez: yeah delta updates is a paid feature for Mender. Happy to help if you’ve got any questions or such around the system (I work for Mender)
alperak has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
alperak has joined #yocto
<vmeson> Does anyone (rburton) know if this is still broken: Cannot build x86-64 Go SDK on aarch64 -- https://bugzilla.yoctoproject.org/show_bug.cgi?id=14860
<rburton> zeddii khem: master poky+master clang means perf breaks: 2023-12-21 17:05:27 - INFO - | aarch64-poky-linux-clang: error: no such file or directory: 'aarch64-poky-linux'
<rburton> vmeson: i'll fire a build now and find out
<vmeson> rburton: thanks
GNUmoon has quit [Ping timeout: 240 seconds]
<zeddii> you lost me at clang ;)
alperak has quit [Quit: Client closed]
GNUmoon has joined #yocto
<rburton> zeddii: it also explodes in an unrolled loop with pages of warning
<rburton> 2023-12-21 17:05:27 - INFO - | unroll_loop_thread.c:35:25: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
<rburton> 2023-12-21 17:05:27 - INFO - | 35 | : /* in */ [in] "r" (in)
<rburton> 2023-12-21 17:05:27 - INFO - | | ^
<zeddii> you lost me at unroll
<zeddii> ;) :)
ptsneves has quit [Ping timeout: 264 seconds]
mvlad has quit [Remote host closed the connection]
sakman has quit [Ping timeout: 260 seconds]
<dvergatal> RP: btw. what in case of using user from different recipe just to call `chown uid:gid path` ? Because right now I will not use if I want to add package to USERADD_DEPENDS it demands `inherit useradd` which in turn demands USERADD_PACKAGES...
sakman has joined #yocto
goliath has joined #yocto
Notgnoshi has quit []
Notgnoshi has joined #yocto
<vmeson> rburton: [Bug 14860] Cannot build x86-64 Go SDK on aarch64 -> RESOLVED - yay and thanks again.
Minvera has quit [Ping timeout: 245 seconds]
xmn has joined #yocto
tlwoerner_ has joined #yocto
dmoseley_ has joined #yocto
xmn_ has joined #yocto
dmoseley has quit [Read error: Connection reset by peer]
xmn has quit [Ping timeout: 260 seconds]
rm5248 has quit [Quit: Leaving.]
tlwoerner has quit [Ping timeout: 260 seconds]
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto