 Good afternoon, evening, morning, everyone. It is December 1st. Welcome to today's Minecraft DevSync meeting. As is tradition, Derek, go first, buddy. What's going on? All right. Well, today was a kind of a step back on my CAD stuff. I realized the way that I was attaching the grill to the main body had some physical interference with the pie, and so I had to rework that. So I spent most of the day reworking how that kind of attaches together. So yeah, just making progress, but it takes time, but hopefully be printing by the end of the week. So yeah, I didn't do anything additional to the Wi-Fi setup stuff. I added the principle. If you look in the Figma, it hasn't changed in a long time, but I did add the progress, the connected and failure states on the Figma. So when we get to that, they're there real simple. But yeah, that's about all I'm up to. All right. Mr. Hansen, how's it going? Pretty good. So today, I added to the network utilities on the feature mark two boot branch, a network manager. So this has taken what Ken had done with the debus connection and put it in. So now you can create this network manager and you can ask it, is the network connected or is the internet connected? And it'll tell you either one by pinging the debus and getting a response. I actually, it was a happenstance that it worked out today that my internet kept going out, so I got to test it quite frequently actually. However, I'm not 100% confident that it has five states, right? Zero to four. And the fourth, the number four, fifth state says full connectivity. I don't know what frequency it rechecks the internet though, because there were times where the end, I could see in my browser, I couldn't contact anything, but it's still reported full to connectivity. But if I yank the cable out, it would say I had limited because I assume it's looking at, it sees I have Docker connections and thinks there's still a network there. So it's not the perfect thing. I assume on the mark two though, it'll be okay since there's only one WLAN device that we're expecting. So it should be all or none on that, but we may need to do what Ken had done. We may need to drill down into devices if it matters connectivity versus Docker's version of a network. Well, be careful. There's code in there to specifically exclude like LX VR zero, which I believe is the internal connection to the AW Connect container. Okay. I haven't tried this yet on the actual mark two inside the container. So I'll see, I'll see tomorrow how that works out. Yeah, I thought I noticed too that there was a some method or some property about can you even connectivity check available? There's a boolean flag for that. So maybe we can check that before we even. I wonder if that's false. What is the connectivity check return then? Probably unknown I guess. Now the code I'm using to monitor the states I take it, that's not able to pick up the signal strength, correct? No, it's just a yeah, okay. Yeah, we just started, we're going to add, this is something we added these first two things to, you know, I want to add some, you know, like the access point checking to it and signal strength checking. So it's just the beginning is kind of a proof of concept of something we can, that's in core that we can use to, you know, do some of these debush checks from skills or from inclusion. The real asset test is to have it burned in the build and be logging so that when you go through a fresh bring up, you can see all the different states that the connect container is going through or more technical that's putting the network managers through over the debug. So that's where you should be able to see whether it's got the access point active or not, whether it's failed to connect to the access point or succeeded and things like that. And I don't know, you know, which code you guys are using, but the code I had, it monitored a value that, like I said, I saw three states disconnected, active, and config, and I assume config was the access point. But I'm sure you guys will be on top of it. But again, the real, the real test is to have it in the build so that the very first bring up, if you purposely like, type in a bad password and go through that process again, you should be able to figure out from that in your time kind of what was going on and what you were seeing, and then you could be able to react to that if that makes sense. Yeah, I have some logging enabled as well. So we can, you know, you can't SSH and need advice until after you have the connection, of course. So, you know, nice to have all that logged so we can see how what happened. Also, the code I gave you creates a new log in VARLOG microsoft called time status or something, or Wi-Fi status. But the point is, if you run and you boot and you can't successfully connect, you can still mount that device on your laptop and look at that log file. Yeah, so that's that's in the latest build. So you should, you know, it's logging already. I've, you know, gone in and had a look at some of them. I don't know that it's actually going to give us anything different to just manually sticking it on the devices and and booting. And I question the 15 second timer there, probably a little too tight. But I also question the one second pairing startup. Well, and that's something we need to probably talk about, or at least make some stabs at us. Have what, what did these timeouts, what should they be, you know, yeah, that's exactly right. How many retries do we do that kind of thing? Yeah, I mean, I'm concerned about the fact that we don't recover from it, but AW connect failures, bugs. So we don't have any control over that process short of a hard boot, but we need to be able to detect if you're in that condition. My machine that I got, which had a build from, I guess, Wayne that I just unpacked today, did not boot at all, did not connect at all. Well, it connected to the Wi-Fi network fine. It just won't pair. Oh, right. Did you try rebooting? Oh, I spent an hour with it. I reburned the image, actually, to the one that's in the dev team chat that Gev posted yesterday to try that one. Because yeah, we were seeing that pairing issue at the summit where it wouldn't pair until you rebooted. No, even if I reboot it won't pair. Okay. Well, that's an old build. It's from like, I don't know, a while ago. So I got a new one that was posted. Hopefully it won't have that problem. Yeah, it would have been from early November or late October. Yeah, I'm not going to spend a lot of time troubleshooting old build since we're working on the startup sequence. I'm just going to get our changes done and troubleshoot that. But you got it. You got it to go. Ken, you got it on online. It's working now. No, okay. It's got finished burning a new image, the latest image. Okay. I had to step out right before the meeting, but when I'm meeting Gover, I'll probably. All right. It's powering up and giving you audio and everything. Oh, yeah. And it recognizes me and talks to me and everything. All right. Mike, is there any else you want to add? I would just say so tomorrow the plan is to probably in the, what we're calling the HAL, the enclosure mark to put something in there that spins up a thread that does this connectivity check and emits bus events. Something that Derek could catch and then potentially do something with. Or I guess he could also call directly to the network manager. I'm not sure how we want to, how we want to do that. So we'll figure that out tomorrow. Should I remove the startup script version of it today? Not yet. We're on, not even on the mark two branch yet. Oh, you're just on. Okay. All right. I did get the, you know how we were saying, man, it'd suck if like the thing randomly went off in the middle of the night that happened to me last night. So I'm considering at least removing the reboot thing for the short term because, yeah, having my device reboot in the middle of the night and start asking to set up Wi-Fi is quite not nice. Did it actually have to set up Wi-Fi or did it automatically connect? No, it, it needed to set up Wi-Fi. Why? I don't know. I haven't, I haven't figured that out yet. After it lost its Wi-Fi, it didn't reconnect automatically. Yeah. Well, one of the things that I'm saying is that the system connection, like the network connections are getting wiped on reboot for some reason at the moment. And you get that a lot. Shouldn't we reach out to Panicor if this is happening? Yeah, I did yesterday. Yeah. I haven't, I haven't looked to see what the response is yet. Yeah. I'm not sure if it's, like it definitely didn't happen previously. So, you know, whether it's the change in the AWE Connect container or whether it's somehow the, what we're, what we're doing on the D-Bus, I don't know if we're emitting any commands to the D-Bus or we're just listening. I mean, you have to admit messages to ask for the status, but it shouldn't be modifying anything. Yeah. So, my assumption is that it's some issue in the AWE Connect container. That's my guess too, because I've been out of this problem since before, Ken's coded that in there. So. Okay. Cool. Now, I think what's most disturbing is that we've got code in there that detected the outage and rebooters. It didn't reconnect automatically. That's good. Yeah. And that's all part of the boot sequence stuff. So, yeah, we'll get it figured out. All right. Ken, since you're yapping, you want to gap some more? I wish I had something to yapp about. I got Scythe Black today on doing a document and on trying to get this new Mark II working, but I also am in the throes of trying to get the Mimic-1 to behave like a real TTS module so that it can peacefully code just with everybody else. As I mentioned, there's other issues regarding just the way the architecture works and starting and stopping the audio service and people stepping on each other. I'm not going to address that. So, when it goes haywire, all it'll do is make sure that it's not being corruptible through the TTS path that still has other issues. So, that's where I'm at. All right. What's up, guys? So, I got the device booting much nicer yesterday. The feature Mark II range is now fully up-to-date with Dev because we had included a bunch of fixes. And rather than just cherry-picking individual ones, I figured we may as well just bite the bullet and get it all working anyway. And that seemed to be the right call. Yeah. As I mentioned, I'm seeing the network connections get wiped, and I'm also seeing the identity file get wiped on boot. I think the identity file getting wiped might be because the build process is creating the identity directory in the old location. And as part of the XDG migration, it tries to migrate from the old path to the new path. And it basically wipes out the new one if the old directory exists. And so, I did a PR to change that. And OK pointed out that there was a discussion when that original XDG PR was put up that if the copy failed halfway through, sorry, if the move of the directory failed halfway through, and so therefore you only got corrupt data in the new location, then the idea was that when you do a move operation, obviously you copy it across and then remove the old one. So if the old one hadn't been removed yet, then the assumption is that the move hadn't completed successfully, and you could move the entire thing over again. I can see that logic, but it just also means that in this case the identity is getting wiped out by an empty directory. I think that's what's happening. So, yes, I've got some visitors. Anyway, so yeah, there's that. I need to think about how we tackle it. Well, I want to try and see if I can find out why that directory is getting created in the first place, because I couldn't, from a quick glance, I couldn't see it. Failing that, I might just change it on the FeatureMarch2 branch and we can move on for the moment. Because I think once everything moves to XDG proper, and we don't have this starting place of a pre-XDG world, then we don't need to worry about the migration scripts either. Anyway, the other thing I looked at yesterday was Pandora, the Pandora skills failing in the CI at the moment, and tracked it down to it's failing to install the system packages that are defined as its dependencies, and the problem that's actually been fixed already in Paco, which is our system, cross-system package manager utility. But that is in an MSM update that is still waiting to be added to Core. So, it's not in the last release of Core, so therefore it's not in the CI. So, I... Where are we on releasing another minor version of Core? Well, I feel like, I was kind of hoping that we could get the next XDG piece in, so that that way Core was completely XDG compatible before doing it. But my focus, like with the Mark II image just completely being going haywire, my focus kind of moved over there. But, yeah, so I was thinking of trying to get the final XDG pieces in and then cutting the release. Is there other things that we really need from it? It's the test... Mostly the testing stuff. Testing stuff, yeah. So that we can promote some of the stuff that's sitting on the Mark II branch of scales into the marketplace? I mean, we could always do it. Yeah, multiple point releases, can't we? Yeah, we can. Just at this point, without our release manager, it's how much work does Gezz want to do. Yeah, yeah. Well, it kind of feels safer to do it the other way around. I like to do a point release without the new XDG stuff anyway, because, you know, as much as we review code, there's, you know, as we are seeing with the previous XDG changes, there's always things that slip through the cracks once you start actually testing it in the wild. So, yeah, maybe I'll do a point release with everything current. And then we'll do the XDG stuff. The point release now includes some of the XDG stuff that still break things? That's awesome, isn't it? No, well, the XDG, the first XDG stuff is already in the previous point release. So the next XDG stuff is the only XDG things left of the skills. Okay. Yeah. Yeah, I might do that. And that way it'll just, it won't put pressure to release the skills XDG stuff in a point release before it's actually had a chance to be tested, you know, for a couple of weeks on dev. Does that stop for going in data? Yeah. It is going in the, what is it, .local share. Yes, it is the data directory, but it is. That's right. Yeah, yeah. Yeah, I don't know if you are wildly familiar with XDG, but if there's any better place that you can think of for skills to go that is XDG compatible, the XDG data home seems like the best place. That seems more reasonable than .config, since, I mean, skills could contain some data, right, that it goes with them, so it makes sense to put them in local share. Yeah. Yeah. The Minecraft configs, of course, would make more sense than .config, but... Yes, they go in config and the logs, I think, are going in cache. So... Is the TTS cache and stuff going in there, too? That is a good question. It should, if it's not already. Okay. Actually, I think that some of that cache was still in temp. I don't know, I'm not sure that got moved, but we'll have to look. I mean, if it's in temp, that's fine, but... Yeah, I think it was in temp just to keep the life cycle of the files shorter, because I don't think there's anything like... I don't think the cache directory does stuff like temp does, where after, I don't know what the gates are, but after a while it just blows away all their files. Okay. Anyway, worth a look. Yeah, so for the Pandora, in the short term, I'm just going to install the system packages on the Docker image that runs the CI, and so that that will pass and let it through. So that's only going to work. That obviously won't work for any other skill that wants to install system packages until the MSM update gets in. But we don't have that many skills that actually need to install their own system packages. Yeah, I don't expect it to bite us too heavily in the short term, and then we'll fix it. Yeah, that's me. All right, I guess that leaves me. I've spent my day in D-Bus. I can do some research maybe on how to get the access point information we need for the Wi-Fi skill to be happy. So I was looking at some of that. I was working with Michael on the code he was working on. And I added some stuff to the document I've been writing that specifically around what Michael's doing, what Mike's doing. So that's documented in this part of the spec. Yeah, so that's all I've been doing. I will probably continue to do similar things tomorrow with boot sequence. Still some stuff I need to do the document, and there's still some things I need to do in code to get the stuff that was in the skills process moved to the enclosure process. So that's probably what I'm working on tomorrow and writing any systems like that he needs. Did the doc have anything about event names for like the connected disconnected events? We're doing, do I need to add something? Yes, it does. Try to get that implemented tomorrow. Okay, awesome. Anybody have anything else? All right, December 1st, start your event calendars. I've got a wine event calendar. I'm going to go have a glass of wine. We need to. See you all tomorrow.