 Hello everybody. I am Kalev Lember. I work at the desktop team at Red Hat. So nice to see all your smiling faces. Thank you for coming to my talk. So my talk is a quick overview of what's going on in GNOME Software, what we have been up to last year. So in case someone doesn't know what GNOME Software is, GNOME Software is the software center for GNOME. It has a handless application installing removal updates. It supports various different backends. It supports installing RPMs, flatbacks, RPM OSD updates. I assume most of you know what GNOME Software is since you've come to this talk. And here's a quick screenshot for this. So 2018, GNOME Software saw quite a lot of changes there. And I was also actually surprised by some of the changes since I was gone half of the summer or actually most of the summer. And then I came back and then a lot of changes had landed. And then I had a mountain of bug fixes waiting for me to fix so that Fedora 29 could release and it's been a busy year. So there's a bunch of things we've done. And we'll go through all of them one by one. So Richard Hughes wrote a new library called LeapXMLP. It's a new parser for upstream. Upstream is the format that describes all the desktop applications. The description and so on. And the way LeapXMLP works is that it writes a build step involved there. So it reads in all the files and creates a binary cache. And then the client application, which is GNOME Software, then M maps the binary cache and reads it from there. This makes things faster because we are reading it from a binary cache which is optimized for fast lookups. And it also reduces GNOME Software memory use by, I believe, 100 megabytes, which is quite a lot because we no longer need to keep all the data in memory for quick lookups. So that's a new thing and that is landing in Fedora 20, Fedora 30 cycle. And sorry, the library is there but GNOME Software is not using it. No, it doesn't, no. And so in Fedora 30, we are switching to it. And there's quite a lot of regressions there. So if you could try out Rohe, then report those and we'll try to get all of those fixed. So the next item also starts with Leap. And this one is in Fedora 29 already. This is Leap Flatback. Flatback now has a library that supports client-side operations. And we are now doing the Flatback CLI and GNOME Software transactions through the same library, which makes it so that we share bugs and features with the CLI. We've had some long-standing bugs where runtime extensions and application extensions were dev-sold in a different way in GNOME Software and Flatback command line and this should fix most of them. This was one of the things that landed during the summer when I was gone and I've spent quite a lot of time in bug fixing this. So hopefully it should be in a good shape now. But as always, report bugs, if you see any. New thing that landed just two weeks ago. This is work by Mattias Glassen. He's to show permissions for Flatback Flatbacks. So Flatback command line has showed them for a long time, but now we are trying to catch up with it. So Flatback permissions are like, what kind of file system access it has? Does it access D-Bus? Does it access some other service? And so we have a way to show permissions for already installed apps. And then when an app gets an update and new permissions appear, then we hold back the update and ask the user if they want to update until the list of permissions and so on. So that's the same kind of concept as Google Play Store has. It shows new permissions. Here's a screenshot. This set piece is a cooking app, and it shows the permissions it has, not many. And yes, when it gets an update, it shows new permissions. There's some UI fixes that need to be done here, so it looks a bit prettier, but the groundwork is all there. And this is also landing in Fedora 30. And it's already in Growhead. Then we have automatic updates in Fedora 29. We close after updates Flatbacks in the background by default. There's a new settings dialog where you can control that. You can turn this off. And offline distro updates were prepared automatically before as well. But now it looks a bit different in the UI. When you are not using automatic updates, when you go through Grum Software manually, before there was a refresh button and then you clicked on it, and then it took two hours because it downloaded all the updates, which was not good user experience at all. So what we have now is the refresh button only refreshes the metadata, and then it shows a list of things to download. Then we have a download button, and after that comes a progress bar when things are downloaded. And finally, there's a restart and update button. And here's a screenshot. We have a preferences dialog, and behind there is the new download step that's split out. Then we have a new thing that Owen was just talking about. Since we are getting flatbacks built in Fedora, and we also have the same things available as RPMs, we need a way to choose between those. So we have a source selection dropdown, which allows selecting between flatback and RPM packages. And here's a screenshot of that. This is Inkscape. In the upper right corner, there's a dropdown that we can select between the FlatHub version and the Fedora version. I think it needs one more thing. We need to have a way to select between different flatback versions, because right now, up until now, we've only had flatbacks from one source, which is flatback pretty much. But I think we probably need to show multiple flatbacks there in the future. Anyway, that was my quick talk. Thank you for coming here, and I'm here for questions. Who goes first? You. So the question was how often is GNOME software checking for updates? GNOME software tries to refresh the metadata daily and also does the automatic updates daily. But for the steps that require the user to do something, for example, to restart, then we only offer them to the user once a week. We just prepare the updates, but we don't actually ask the user to restart. We don't want to get them to restart every day. So the question was that so far, when GNOME software has been updating flatbacks, it has not correctly updated extensions. And the question was, do we plan to add more user feedback? Because GNOME software only shows a circle, a spinning circle, and then we can add more user feedback. So, yes, that was major motivation why we did that, so that we could get both app extensions and SDK extensions, and runtime extensions correctly updated. So the question was, do we plan to add more user feedback to the spinning circle, and it's hard to know if it's doing anything. The answer is yes. We've already started doing that. The splitting up the updates into two separate steps was the first step in that direction, because we also feel that there's very little user feedback right now. So we split up updates so that the download step is completely separate with the progress bar. And I think we'll try to do the same pattern in other places as well to show the progress bar and some useful messages. One thing that we didn't manage to do in time for Fedora 29 was to show textual progress for updates. What we want to do is to show downloading one megabyte out of 10 gigabytes. So it's not just a short progress bar, but actually useful information. The comment was that the Flatpak CLI shows how much data is being downloaded, and my comment is that yes, we are going to show that in GNOME software as well. Any more questions? Do you know why this sometimes happens when OpenQA tries to actually enable the system updates? I don't know. Yeah, I don't know. We talked about this on RC, too, and I don't know. So Adam showed a policy dialogue that sometimes shows up in GNOME software, and we don't know why it's showing up in this investigation. Yeah, a filobog, exactly. I don't know. I've been buried under a mountain of bugs, and lately it's been just me fixing bugs. One person against bugs. Anyone else have a bug to report? Because people collaborate. The question was, what's the current state of GNOME software and TNF to collaborate? So there's a library called LeapTNF, which is a bit... The name there kind of implies that it's a library TNF uses, but up until very recently, it was actually GNOME software using it, but not TNF itself, and TNF is getting rewritten to use the library, and so my hope was that in a good future, GNOME software and TNF both use LeapTNF and then... There was a comment that there was a talk earlier that said that TNF is getting rewritten in C++, and that's true. But the problem is that TNF is not starting to use the same API that GNOME software uses, but TNF is getting rewritten into C++, and the C++ is getting added to LeapTNF, but added. So that GNOME software still doesn't go through the same code path, so... So yeah, it's not really sharing a lot of code with TNF, yeah? So related to this movie? The question was, what's the future for a package kit? Do we have any bigger changes coming? So package kit uses LeapTNF, and like an earlier comment said that LeapTNF is getting rewritten into C++. I guess we will have to maybe port package kit to the NeuroC++ classes at some point, but that's pretty much rewriting all of the package kits back end. And right now, my manager is saying to not spend time on package kit, so we'll see how it goes. The question was, does GNOME software use package kit or LeapTNF directly? GNOME software uses package kit, yes, and package kit uses LeapTNF. Yeah. So what I'm saying is that all of those should actually be used according to LeapTNF. So that's basically the future. Quite far from now, probably, but... Yeah, so that's... It should be much simpler in the future, like the whole layout should be much more simpler in the future, right? Yeah, that would be nice, yeah. Yeah, Jiri? The question about the download size is for platform applications because when you go through a user command, you often see there is quite a simple application like calculator, and it shows easily, like, the amount size of 1.2 gigabytes that the original user commands like, yeah, this is just very close, and it is without any context. So it doesn't say that it will slow down the amount of time the application requires. And even with this included, it's very... from my experience, this future estimation requires them to download the time, the application until it was, like, 200 megabytes instead of 1.2 because there was, like, the application in flight, et cetera. So I wonder if there is any time to give those numbers, like, markup to their mind context or maybe I don't know if we're going to complete it because it does more time than it would in my experience. So the question was that flatback download sizes are wildly overestimated and is there a plan to solve that. So I know Alex has been thinking about that, how to get size reporting from flatback more accurate. And one thing we can do in GNOME's other side, I guess, is to show two separate lines so that there's the runtime size and the app size and maybe users can make a better guess based on that. But I don't know. I'm not working on that problem. If flatback command line... If it gets solved in live flatback then we'll get the same thing in GNOME software as well. Any more questions? I can actually listen to my robot at 6 megabits per second. So I started feeling the pain when I started computer Monday morning and it started the Monday morning for the last week. And with that connection I got full bandwidth and I was occupied by GNOME's software and I don't think that it is something I have to do. I imagine you go out there and you're just even with shithead connections that I have. So the question was are there any plans to use delta rpms? Because on low bandwidth connections you can take quite a lot of time right now to download all updates. Maybe five or six years ago I once upon a time did a batch to LeapSif If anyone knows what that is LeapSif was a library that Richard Hughes wrote to do step solving better than YamDid and then LeapSif grew into LeapHeaf and then LeapHeaf grew into LeapDNF which is now. So there is actually a really old batch to do delta rpms and I remember finding it last year and I was like wow this is so old so maybe we should try to make that happen I have no recollection why we didn't merge it back then but there's a new project instead of delta rpms there's what's it called yeah that thing so maybe that's a yeah exactly so the comment was that the plan with Z-shunk is right now for metadata and maybe in the future for packages so I guess we need to support both then so all those package kit questions if anyone wants to help improve the package kit DNA back end that would be awesome because I have a lot of pressure to work on other things not package kit because that's the old technology so things are progressing super fast there but we can go home or go to pub so thank everybody for coming