AppStream & Listaller
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Klumpp, Matthias
AppStream provides a solution for application-centric software management using existing package managers, while Listaller extends the package manager with the ability to install 3rd-party applications in a secure way, without introducing additional UI. This talk explains the basic concepts of both projects and the motivation behind them, as well as the obstacles in cross-distro collaboration which we hit while developing these tools. Software management on Linux is traditionally done using packages, although desktop users are more interested in applications instead and do not care much about how something is packaged. Also, users often want to install software which is not available in the repositories (e.g. unpackaged stuff, as well as new versions of applications), without having to upgrade the whole distribution. AppStream provides a solution for application-centric software management using the existing package-managers, by providing extra metadata for packages. This allows developers to create cross-distro application-centers, like GNOME-Software or Apper. Listaller extends the package manager with the ability to install 3rd-party applications, which are not (yet) in the distribution's repositories. It builds on top of the AppStream specs and focuses on integration, so the installation process is completely transparent for users, and Listaller-installed applications can be managed with existing software-management tools. Because software from 3rd-party sources is a potential security risk, Listaller also tries to give users a hint if they can trust a certain application, and includes sandboxing for these applications. Both projects rely heavily on metadata provided by upstream projects and distributions. This talk will explain the concepts of AppStream and Listaller, which new metadata needs to be added and why as well as how distributions can make a software-center available for their users. If the time allows it, the talk will also highlight the problems we had with the AppStream project in the first place and how we could improve cross-distribution collaboration in general
 I'm sorry for the technical issues at the beginning. Well, I am Matthias Klum. I will talk about AppStream and the Stuller today. First of all, some boring stuff about me. Who am I? I am a package developer, a DBN developer. I contribute to KDE and GNOME. And I'm the currently Stuller maintainer, and I maintain AppStream together with Richard Hughes. I also started the Tanglo project last year together with other people. Yeah, but now to the more important stuff. What will the talk be about? First of all, I will identify the problem. What are we going to fix with AppStream and the Stuller? And then I will talk about AppStream, then about the Stuller. I will probably make this a bit quicker, so we have some time for discussion in the end. And then at the end, I will draw a conclusion about both projects. First of all, we need to know what is wrong with application management to understand why we need AppStream. First, the content of the distribution software repository is usually displayed in form of packages, but this is not very user-friendly, because every non-technical user finds tons of packages where some have names which he or she doesn't understand. And also he doesn't understand why there are so many packages and what development package is for. And if you just want to install Firefox, for example, you easily get lost in the package management. Also, the existing software centers are distribution-specific, and basically every new distribution would duplicate the effort of creating a software center, while a software center is an application which displays applications instead of packages. So compare it to an App Store if you want. Also, the applications are not very well represented to the user, because right now we have only the desktop file as metadata source and an icon which is usually associated with that. But no additional data, for example, localization is often missing, not on Debian. We do very well with that, but other distributions don't have that. There are no screenshots or bad screenshots, and there are lots of inconsistencies between distributions, because every distributor writes its own description for every single application, every single package. Also, there's no interaction possible from the side of the user with the software center. For example, it would be really cool if the user could give a rating, a review for new software, or if he could just report it back within the software center user interface, because if you just tried the application and it didn't work for him and he found it back, it's more a natural way to report it. So, yeah, this is about the application management, but there's also another issue, which is application distribution on multiple Linux distributions. The current situation is that we have PPAs, personal package archives at the Ubuntu world, and repositories for every other distribution to get new software. But for third-party applications, these are really insecure, because they can break distribution upgrades if you have a third-party repository enabled, which packages an application differently, and then the distributor also packages that thing, but also slightly different, and then the user wants to upgrade his system. He might easily break it due to conflicting packages. Also, there are scripts inside these packages which are executed by root, so with root permission. So, if you install the application, you can't be sure that it won't execute malicious stuff during installation before we can sandbox it. Also, handling of PPAs is not very user-friendly right now. Ubuntu does some work on that, but it's still not perfect. Also, the PPAs are distribution-specific. If I want to package a third-party application, I have to create one repository for every distribution, and in the RPM world, almost one RPM package for every distribution. Also, they have a complex structure, because they are made for package distribution and not for distribution of applications, which is what we are aiming for. There's another solution to install third-party stuff, which is binary installers, but these don't integrate well. They are not user-friendly, and they execute lots of stuff with root permission if they need to be executed as root. So, we need a simple and secure-to-cross desktop installation solution for third-party applications, which are not yet packaged by the distributor, who might not have time to backport everything. So, this has spawned two independent projects. One is AppStream, which mainly contains cross-distro specifications for building software centers and software-centered applications, which includes lots of metadata, a database spec for distributors to access to get information about what applications are available in the package database. Also, they include some optional new metadata for AppStream projects to ship, so we can enhance the available data to represent an application in a software center. They also offer the interactive features I spoke about before. The Stuller, on the other hand, generates cross-district application packages. It contains tools for app developers to make applications available for many distributions, and it contains also a metadata specification to describe dependencies on the next distributions. It is an optional component, so if you don't want to, you don't have to ship with Stuller, and it requires PackageKit, so if you ship with Stuller, you should make sure that PackageKit is available. So, first talk about AppStream. AppStream was first created in 2011 by these people from Fedora, Dabian, OpenSUSE, and Geya Ubuntu KDE, and some free desktop developers. They sat down together and discussed how we could collaborate, how we could do a collaboration in order to create a really good-looking software center which is available on multiple distributions, so not every distribution has to redo all the work again to make a software center happen. So, this resulted in the AppStream concept, which starts with a so-called Compose server which scans all the packages which are available in the repositories, extracts desktop files, icons, and app data. I will come to app data later. Then generates a large XML file containing all this metadata and all translations which gets compressed and shipped to the client together with an icon pack. The client then aggregates data from multiple sources, including the stuff which came from the Compose server but also stuff from a screenshot server, from a feedback server, and other possible sources to display the application to the user. In more detail, the desktop files and facturates are converted into XAPIEN database for additional features like easy-stamming and faster access to the information. The key of AppStream is the so-called AppStream XML, which contains all information about the application, which is the name, a unique application ID so we can identify it on the system and we can ensure that there are no duplicate applications, which is right now the desktop file name, a summary, a description, icon, author data, project group, which is, for example, GNOME or KDE, so we can filter applications if you don't want GNOME applications, you can say no GNOME or if you don't want KDE applications, you can say no KDE. You can also create different departments for that, so Mozilla is also a project group. Categories, which is available in desktop files already, MIME types, so you will be able to create a query for an application which is able to open or to process a MIME type which you don't know, which is also a useful feature for users who get a file which they can't open, so they will just ask the software center how can they open that. Keywords, pretty self-explanatory, and screenshot references and descriptions, so we have every application can have multiple screenshots, which also contain a small description on what the user can see on the image. It also contains a few other things which are less important. There are a few issues with that which we experienced after writing the upstream XML, which is that, also although it was localization, but there are a few issues we noticed after writing it. Surprisingly, some people don't like XML, which was a bit embarrassing for me because I first created that XML together with the others, and then I wanted to implement that in Debian, but people told me that XML is used nowhere in the infrastructure, and yeah, so Debian prefers Jaml for that instead of XML. So we created a new Debian extension project called Debian 11, which will enhance not only the, but it will enhance metadata in Debian in general. It will contain the upstream data, about additional components like codecs or themes or whatever you want to find in the packaging database. So it's a little bit more than just the upstream XML. The other problem is that, where do we get data from if the distributions don't have it in their repositories already, so if you can't extract it from the desktop file or if it is not already available in the description. The second problem is addressed by a so-called appdata. Appdata are also small XML files, which are shipped with upstream projects. They are a subset of the upstream XML specification. They contain URLs to a third-party service, which contain the screenshots. So this is where we get screenshots for upstream from. They are localized upstream, so we have one description which has a localization and we don't have to redo again and again on every distribution. There are no requirements to implement upstream. This is where we had some confusion about, because Fedora said that they would drop every application which doesn't have an appdata file from their software center, from no software, but this is a distributor's policy. So, upstream is perfectly fine without having an appdata file. It will just not display that much data about the application. Fedora is desirable to have an appdata file in an upstream project, so if you ship a GUI application, please provide an appdata file for it. External content, like screenshots, if it is on third-party servers, like I said before, is prone to be rebroken soon, because the upstream server might go down or there might be malicious stuff even in there and they might change it afterwards to something else. So, the distributor on creating of the upstream XML pack will download the screenshots, cache it on its own server, and modify it if necessary. So, the distributor still has control over that, but at first the information lays on the upstream server. Some statistics about the appdata. There is not that much to say, but what is really interesting is that GNOME already ships over 50% of its applications with appdata because they simply made it mandatory to have appdata, while there is only one KDE application with appdata. So, KDE really has to catch up there. I am drafting something which might enable having easy upstream on KDE as well. There are currently some issues with translation, but I am pretty sure that we will fix that in time. For Xfce, I still need to find the right people so we can talk about adopting appdata if they want to. I also mentioned another issue before, which is that we have two file formats, one Jamel format and one XML format. And that is also because Ubuntu was first and did it differently, and Ubuntu format, which also contains app information, which we want to have for software centers. So, you also have to have fallback solutions for screenshots, etc. So, it is getting a little bit more complex, at least during the transition phase where not everything is in the upstream XML format. So, we invented LibAppStream, which is like a common library every new software center can use to access this information. This will avoid that every software center has to repost the XML file or the Jamel file or the Ubuntu app install information, or has to download the screenshots from... has to detect the screenshots or download the screenshots from there and also consider a fallback solution if the distribution offers one. So, this LibAppStream stuff generates a sapient database, which contains all the data for software centers to access. So, the software center will basically only see the database and not the raw data it was generated from. Also, LibAppStream allows accessing the database via IGObject interface because many people were afraid of using the native sapient interface and the object allows creating bindings for almost any programming language out there. This is how it looks like in the end. We have an upstream plugin which runs inside the package Kedemon, so it will listen to refresh actions on the package Kedemon, and if it receives a refresh action, it will check if the upstream data is up to date and if it is not, pull the data from Ubuntu app install from DebianDep11 or from upstream XML, which all other distributions ship, and then generate the sapient database. As you can see, it also acquires information from different sources and the clients, if they want to, can access the sapient database directly, so they don't have to use LibAppStream. So, what about upstream adoption in GNOME? GNOME software was created last year with GNOME. It's the only really fully upstream compatible software center out there. It's fully supported in Fedora. It's pending on OpenSUSE as far as I know, and in Debian, it's blocked by the Debian 11 implementation, which just needs some more time. On KDE, we have APR, which is the KDE package Ked front-end, which aims to be both a package manager and an application manager, so to combine both words. APR has some initial support for upstream by LibAppStream, but that needs some more work because it's not working as well as we wanted it, so there are some issues. Update and inclusion into KDE projects is something we discuss right now there, and I also heard about a possible port of the Mew and Discover stuff to package Ked and upstream, so I think there was a lot of people working on that, at least one summer of code project, if I remember correctly. Yeah, on the distribution side, in Debian, I already talked about if Wundru has their app install, which came before AppStream, so it's not an invented tier syndrome this time. It will likely migrate to Debian solution, but we will see what happens. Fedora is Fedora. They were pioneers on the AppStream front-end chip that stuff first, and OpenSUSE has working AppStream XML, but I'm not sure if it's used productively. Last time, there were still ironing out some issues in the generation process. So far, unfortunately, Onignome has a software center which supports everything from the AppStream specification. This is about the application management part, so now I come to the application distribution part, which is the Stuller's domain. First, some background about the project. It was started in 2008 as an experiment. It was first never intended to be used productively anywhere. It covered some features of PackageKit and AppStream that time. It has its own package management abstraction layer just as PackageKit has, and it has some metadata extension just like AppStream has, but much simpler because of that. It switched PackageKit in 2009 for communication with the native package manager. Then later, it merged with AutoPackage. I'm not sure if you remember AutoPackage. It was started way, way before Stuller was created and shipped binary packages, but then development slowed down and later it merged with Stuller. We adopted some of its features and some of the projects which were created inside AutoPackage. AppStream was then started in 2011, so this part of Stuller was also obsolete, so we revoked that thing from scratch, which took almost a year, and now it only focuses on the distribution part, which it does, in my opinion, really well. Stuller's main goals are integration with the system, so we don't want that the user has another installation GUI to install an application while there already is a user interface with just the software center or the PackageKit application installer. Also, we don't want a second updater, so if you update your system, if the user updates their system, it should be one time thing, so he has one updater where he updates all applications, and not the second one like on Windows. Also, the installed applications should look like native applications, but they should not be treated as native applications. So they run in a sandbox, have different privileges, but because they come from a potentially malicious source and they are not checked by the distributor. Obviously, across this year and desktop compatible, it should be simple because we don't aim for a catch-all solution with Stuller. It should install applications, but that's it. It should not install stuff like an init system or install toolkits or everything which has reverse dependencies, because this is the domain, the native distribution package management that we are working in and where it makes sense to have it while the Stuller is designed only for applications. It should be secure, which means we have a security hints database, signatures and a sandbox which is currently under construction. We also ship some developer tools, which basically help us to generate a statically linked application or to make it relocatable or to do some automatic QA, like checking all the validity of all file formats used in the application. The basic concept of the Stuller is that it is a package kit plug-in which explains the integration part, because every application which talks to package kit will also automatically talk to the Stuller because it sits as a plug-in inside package kit and catches all the Stuller packages which are passing through and processes them before they reach the native back end in package kit. If you don't know about package kit, package kit has different back ends to talk to the native distribution package manager and the Stuller just sits in between them. Well, therefore, as I said, every package client is able to install the Stuller packages. Also, this is the connection to upstream. The Stuller drops some XML into the XML pool of upstream, which results in a really great representation of every Stuller installed application in the software center. So if the XML is present, it will be automatically processed by the tool which generates our sapien database for the software center. And therefore, the software center will know that the... will map the Stuller package to the application information and display it to the user so you can uninstall it, for example. Also, the Stuller uses a superset of the app data spec as source for application metadata, so every Stuller package will also include an app data XML file. So if we are going to install the application, we can already show information about what the user is currently installing. Yeah, well, as you might imagine, the Stuller consists of many tools to achieve that. It has some end-user tools which manage, for example, a database of trusted keys so the distributor can set which sources are trusted and the other ones aren't untrusted until the user adds the key manually. It shows some developer tools to generate portable applications to link against an older GLC version, for example, or the Simplify static linking. It also contains some tools to track dependencies and to visualize them. It also contains the offerings, packaging tools like lippkgm, which is the Stuller package generator, and a small QA tool which will, for example, validate XML files which were shipped with the application or check if the desktop file's integrity is okay. So distributors don't have to worry much about upstreams creating crappy packages because the packaging itself is damn simple, the upstream can't do much wrong with doing that, and the other stuff is checked by the QA tool automatically so we can already see common mistakes. It's just like Lintian but less powerful, unfortunately, so far. So if you create a package, it's a YouTube-era package creation, so really the simplest way to create an upstream package if everything works as intended, is that you have to write your app data description, then write a small options file which basically just defines if you want to make Listuller automatically detect all dependencies in your source tree and which version of the Listuller package you want to create. Then you need to write a file directory listing for the new package. Listuller will later decide where to install that application based on distributors' policy on that, but you need to create the directory structure for the application by yourself using some placeholders for the final path which Listuller will insert during installation. Then you can already build the package because there's a small tool included which will detect your build system and handle the installation part. Currently, it does not work with many build systems, so you can still give Listuller all the required information to build the application or you can just point it to the binary stuff and package that. So you don't have to build the application during the package creation process. Yeah, this is... I will skip that. Later, the package is GPZ signed, so any package which is not signed will be rejected for installation unless the distributor has lowered the policy to allow dangerous package installation, so you can expect Listuller package to have a signature. And during installation, Listuller will process all files installed by the package and also do some modifications if necessary, for example, adjust paths and desks of files, or, well, do almost anything the distributor finds useful in order to integrate that application. Right now, it's really only take a look at desks of files if they are sane and if they are in the right location. Yeah. So I will not talk about dependency solving, which might confuse you, also no presentation without a cat, because at the beginning I said Listuller should be simple and dependency solving is one of the most complex things, at least for if you aim to be cross-distributional as well. So why have this dependency solving if it's so painful to do it? Well, mainly if we statically link everything into one binary, we not only use more memory because we have to load all that stuff, but also if the distributor, for example, pushes an update to the toolkit, which closes the critical security sensitive bug, it will not reach the third-party application, which also ships that toolkit. So it is a potential security risk, which we don't have. So it makes some sense to have at least a base level of dependency solving for major dependencies, for example, system components like GLIP or toolkits. So yeah, the main problems here is that we want to simplify that, that the distributor might not provide enough metadata for Listuller to find the dependency in the native distributor database. So in that case, we can't sell an application if a dependency is missing. And also, what do we do if the ABI of the dependency is not stable, for example, if they decide to make some changes without bumping the so-name and, well, the application just can't use it. And also, what do we do if we absolutely require an old library version? Well, the answer to the last question is obviously statically linked. For the ABI stuff, there is no real solution. We simply rely on upstream projects to take care of that and don't break the ABI unless it's really necessary. In order to enhance the metadata about available dependencies in the distribution repositories, we created the so-called component files, which simplify dependency solving. I will go a bit faster here. Components are, for example, toolkits. I already explained that. And to install a Listuller application, the cell only needs the basic stuff. So all small dependencies which don't ship a component file and are not available on multiple distributions should be better be included directly in the package. They don't necessarily need to be statically linked. You can flag that thing as a library and Listuller will take care that the application can find it later after it was installed. Last but not least, Listuller can, in theory, also satisfy dependencies by downloading a statically linked package from third-party sources, which might not be wanted by the system administrator, so he can disable that. Listuller can also check Cpan, Cran, PyPy, or the gem library in order to satisfy dependencies of Python stuff, for example. So what is component information? Component information can be compared to a non-developer package config file. It describes all the component version and all the public interfaces it provides, which are, for example, libraries or binaries, but also stuff like icon sets or other data which is used by other applications, other than the project itself. So everything which is shared should be defined here. Later, we can then, during the package creation process, map the dependencies we found in the applications to a component, tell the user, well, you are shipping stuff here which doesn't have a component representation on the distribution, so you might want to statically link that or to include it there. And we can also check on which distributions the application will run because we have this information and we know which distribution ships it, so we can run the check like your GILI dependency is too high to run on Ubuntu 14.04 or something. Yeah, it also allows dynamic dependency detection, dynamic version detection, sorry, which means that if we ship the component definition with the package itself, we can, on the users on the target system, check if the dependency is installed without having to query the native package manager. Well, I already talked about that. As said before, we ship that DAF scan tool which is able to perform that task and to not only detect dependencies of binaries but also Python models and almost anything when you ship with the application. Yeah, I'm sorry for being faster here but some discussion time would be wanted. The future of the seller is, first, finalize and formalize the style specifications because some stuff does not have documentation yet, although it's getting better, and we want a formal standard for creating the style of packages, so others can review that and check if it's satisfying their needs. Also, it will result that in a stable package standard, so we won't break the packaging stuff anymore. As in projects, at least some should ship component definitions by default, so we are able to send a query to the native distribution database, for example, Instalami GTK3 bigger than 3.12 in version. This is not only helpful for the seller but also for projects which compare versions available in multiple distributions because we can just check for component definition files and then map them between distributions and detect which distribution has which version. This also will allow us to get rid of horrible stuff like the Valve developers did with Steam. They ship a small script called SteamDabs which is heavily dependent on Dabian for detecting dependencies. If we have component definitions, Steam could just ship a package kit-based file which is able to find all the stuff they need from third-party sources in the distribution's own repositories in a cross-distributional way without being dependent on Ubuntu or Dabian. Of course, the seller should go into more distributions. It's already shipped in some, but the coverage is not really high so far. Maybe in the end, I have a way for third-party developers to target all the new distributions with one app package because it's really desirable for upstream projects to have one thing that users can download or access from a single source and then have it. Then creating for one package, short native package for every distribution or cramming together some weird binary stuff. Conclusion about all projects. Well, I skipped that because you heard it just recently. We welcome contributors to AppStream and to Installer because there are currently very few people working on it and it would be great to get more feedback and to get more people involved. It's not the most... Apparently for some people, it's not the most interesting field to work in, but I can assure it's an awesome place. And we are all nice people. Conclusion about writing free desktop stuff which we experienced is that we should never do things leading to the impression that we want to force stuff coming from GNOME on KDE or coming from KDE on GNOME. It sounds natural, but it's really easily done to talk in a way that sounds to people that they would get stuff which was developed for GNOME and then is dumped on KDE with an argumentation, well, it's a standard. Please implement that stuff. Why? Because it's a standard. We have to take everyone with you if you want to succeed with something. On the contrary, sometimes you need someone to just go ahead with the project and have the others follow. The AppStream stuff was stalled for a very long time, unfortunately, because there were not enough people working on it and there was some stuff missing. We had some issues with the canonical CLA, for example, to get the software standard available on multiple distributions which in the end failed, so GNOME software was created but it was just delayed. We also needed Fedora to really push for AppStream in order to make it happen on more distributions. Also, it does not make sense to invest too much time in bike setting about details in the same manner. You should just go ahead with implementing something and users will complain about that later and then you can adjust it instead of debating about hypothetical stuff beforehand. That's it. Do you have questions? I've got a microphone up here, so folks who have questions, let's use this so it ends up on the video. We'll take questions in order of rows, so if you're down here and you forget your question, we're not going back. One question. Does the installer package provide a post-install, pre-install hooks like the Vian packages, for example? It provides... The package itself is not able to run any script because we execute it with root permission and therefore we don't want, at least not during installation phase, the packages able to execute any script. What is happening is that the installer will scan what is available in the package and then decide what is the best thing to do. For example, if it ships a desktop file, it will later update the desktop database. So it is doing that. And if the person who created the installer package wants to do something which he or she would need a script for, they could just file a bug against the installer and we will implement that for every other person as well in the installer directly. Thank you very much for the upstream. It's really, really needed. As an upstream developer, I tell you, we need some tools that protect us from distribution maintainers to actually fuck it up. So it's the opposite. My question is about this DEP11, I think it's called, the new universal DBM thing. What is, can you tell us more about this process that is ongoing? Well, it's a DAPI thing. DEP is a DAPI extension project. And this file will include information about components. So the component data I talked about under the installer site, but also information about the applications and stuff like codecs or kernel modules. So we can, if something is missing, if an application misses a module which would be necessary to work, for example, if you have a video converter which needs to convert something but some GSTRIMO module is missing to do that, it can make a package kit query to find out which package provides the missing component and can afterwards install it. So what we do with DAP11 is to push all this metadata into one file and make it available on every DAPI distribution using apt and enabling this feature. Which, it is just for DAPI. The file format is independent, of course everyone can use it. But yeah, the thing is mainly about DAPI. I'm currently working on implementing that stuff in the DAPI and ActiveKit. So I hope this will get ready soon. Do we have one more question? Do we have time for one more? Okay, great. Thank you very much. APPLAUSE Very good. Thank you. Thank you. I was way too fast. I was way too fast though. You know, I think that people so like most people, the rate of speed you talk when you're talking to most people is way slower than they can take in information people tend to get forward. So if you talk quickly during a presentation people actually like that because they don't get forward. I thought it was great. Yeah, and so. APPLAUSE Yeah, I'll show you this real quick. There's not a lot to it. I didn't think so. APPLAUSE
 I'm sorry for the technical issues at the beginning.  Well, I am Matthias Klum.  I will talk about AppStream and the Stuller today.  First of all, some boring stuff about me.  Who am I?  I am a package developer, a DBN developer.  I contribute to KDE and GNOME.  And I'm the currently Stuller maintainer,  and I maintain AppStream together with Richard Hughes.  I also started the Tanglo project last year together with other people.  Yeah, but now to the more important stuff.  What will the talk be about?  First of all, I will identify the problem.  What are we going to fix with AppStream and the Stuller?  And then I will talk about AppStream, then about the Stuller.  I will probably make this a bit quicker,  so we have some time for discussion in the end.  And then at the end, I will draw a conclusion about both projects.  First of all, we need to know what is wrong with application management  to understand why we need AppStream.  First, the content of the distribution software repository  is usually displayed in form of packages,  but this is not very user-friendly,  because every non-technical user finds tons of packages  where some have names which he or she doesn't understand.  And also he doesn't understand why there are so many packages  and what development package is for.  And if you just want to install Firefox, for example,  you easily get lost in the package management.  Also, the existing software centers are distribution-specific,  and basically every new distribution would duplicate the effort  of creating a software center,  while a software center is an application  which displays applications instead of packages.  So compare it to an App Store if you want.  Also, the applications are not very well represented to the user,  because right now we have only the desktop file as metadata source  and an icon which is usually associated with that.  But no additional data, for example,  localization is often missing, not on Debian.  We do very well with that, but other distributions don't have that.  There are no screenshots or bad screenshots,  and there are lots of inconsistencies between distributions,  because every distributor writes its own description  for every single application, every single package.  Also, there's no interaction possible from the side of the user  with the software center.  For example, it would be really cool if the user could give a rating,  a review for new software,  or if he could just report it back within the software center user interface,  because if you just tried the application and it didn't work for him  and he found it back, it's more a natural way to report it.  So, yeah, this is about the application management,  but there's also another issue,  which is application distribution on multiple Linux distributions.  The current situation is that we have PPAs,  personal package archives at the Ubuntu world,  and repositories for every other distribution to get new software.  But for third-party applications,  these are really insecure,  because they can break distribution upgrades  if you have a third-party repository enabled,  which packages an application differently,  and then the distributor also packages that thing,  but also slightly different,  and then the user wants to upgrade his system.  He might easily break it due to conflicting packages.  Also, there are scripts inside these packages  which are executed by root, so with root permission.  So, if you install the application,  you can't be sure that it won't execute malicious stuff during installation  before we can sandbox it.  Also, handling of PPAs is not very user-friendly right now.  Ubuntu does some work on that, but it's still not perfect.  Also, the PPAs are distribution-specific.  If I want to package a third-party application,  I have to create one repository for every distribution,  and in the RPM world, almost one RPM package for every distribution.  Also, they have a complex structure,  because they are made for package distribution  and not for distribution of applications,  which is what we are aiming for.  There's another solution to install third-party stuff,  which is binary installers, but these don't integrate well.  They are not user-friendly, and they execute lots of stuff  with root permission if they need to be executed as root.  So, we need a simple and secure-to-cross desktop installation solution  for third-party applications, which are not yet packaged by the distributor,  who might not have time to backport everything.  So, this has spawned two independent projects.  One is AppStream, which mainly contains  cross-distro specifications for building software centers  and software-centered applications,  which includes lots of metadata,  a database spec for distributors to access  to get information about what applications are available  in the package database.  Also, they include some optional new metadata  for AppStream projects to ship,  so we can enhance the available data  to represent an application in a software center.  They also offer the interactive features I spoke about before.  The Stuller, on the other hand, generates cross-district application packages.  It contains tools for app developers to make applications  available for many distributions,  and it contains also a metadata specification  to describe dependencies on the next distributions.  It is an optional component, so if you don't want to,  you don't have to ship with Stuller,  and it requires PackageKit,  so if you ship with Stuller, you should make sure that PackageKit is available.  So, first talk about AppStream.  AppStream was first created in 2011  by these people from Fedora, Dabian, OpenSUSE,  and Geya Ubuntu KDE, and some free desktop developers.  They sat down together and discussed how we could collaborate,  how we could do a collaboration  in order to create a really good-looking software center  which is available on multiple distributions,  so not every distribution has to redo all the work again  to make a software center happen.  So, this resulted in the AppStream concept,  which starts with a so-called Compose server  which scans all the packages which are available in the repositories,  extracts desktop files, icons, and app data.  I will come to app data later.  Then generates a large XML file containing all this metadata  and all translations which gets compressed  and shipped to the client together with an icon pack.  The client then aggregates data from multiple sources,  including the stuff which came from the Compose server  but also stuff from a screenshot server,  from a feedback server, and other possible sources  to display the application to the user.  In more detail, the desktop files and facturates  are converted into XAPIEN database  for additional features like easy-stamming  and faster access to the information.  The key of AppStream is the so-called AppStream XML,  which contains all information about the application,  which is the name, a unique application ID  so we can identify it on the system  and we can ensure that there are no duplicate applications,  which is right now the desktop file name, a summary,  a description, icon, author data, project group,  which is, for example, GNOME or KDE,  so we can filter applications if you don't want GNOME applications,  you can say no GNOME or if you don't want KDE applications,  you can say no KDE.  You can also create different departments for that,  so Mozilla is also a project group.  Categories, which is available in desktop files already,  MIME types, so you will be able to create a query  for an application which is able to open  or to process a MIME type which you don't know,  which is also a useful feature for users who get a file  which they can't open, so they will just ask the software  center how can they open that.  Keywords, pretty self-explanatory,  and screenshot references and descriptions,  so we have every application can have multiple screenshots,  which also contain a small description  on what the user can see on the image.  It also contains a few other things which are less important.  There are a few issues with that which we experienced  after writing the upstream XML,  which is that, also although it was localization,  but there are a few issues we noticed after writing it.  Surprisingly, some people don't like XML,  which was a bit embarrassing for me  because I first created that XML together with the others,  and then I wanted to implement that in Debian,  but people told me that XML is used nowhere  in the infrastructure, and yeah,  so Debian prefers Jaml for that instead of XML.  So we created a new Debian extension project called Debian 11,  which will enhance not only the,  but it will enhance metadata in Debian in general.  It will contain the upstream data,  about additional components like codecs or themes  or whatever you want to find in the packaging database.  So it's a little bit more than just the upstream XML.  The other problem is that, where do we get data from  if the distributions don't have it in their repositories already,  so if you can't extract it from the desktop file  or if it is not already available in the description.  The second problem is addressed by a so-called appdata.  Appdata are also small XML files,  which are shipped with upstream projects.  They are a subset of the upstream XML specification.  They contain URLs to a third-party service,  which contain the screenshots.  So this is where we get screenshots for upstream from.  They are localized upstream,  so we have one description which has a localization  and we don't have to redo again and again on every distribution.  There are no requirements to implement upstream.  This is where we had some confusion about,  because Fedora said that they would drop every application  which doesn't have an appdata file from their software center,  from no software, but this is a distributor's policy.  So, upstream is perfectly fine without having an appdata file.  It will just not display that much data about the application.  Fedora is desirable to have an appdata file in an upstream project,  so if you ship a GUI application,  please provide an appdata file for it.  External content, like screenshots,  if it is on third-party servers, like I said before,  is prone to be rebroken soon,  because the upstream server might go down  or there might be malicious stuff even in there  and they might change it afterwards to something else.  So, the distributor on creating of the upstream XML pack  will download the screenshots,  cache it on its own server, and modify it if necessary.  So, the distributor still has control over that,  but at first the information lays on the upstream server.  Some statistics about the appdata.  There is not that much to say,  but what is really interesting is that GNOME already ships  over 50% of its applications with appdata  because they simply made it mandatory to have appdata,  while there is only one KDE application with appdata.  So, KDE really has to catch up there.  I am drafting something which might enable having easy upstream  on KDE as well.  There are currently some issues with translation,  but I am pretty sure that we will fix that in time.  For Xfce, I still need to find the right people  so we can talk about adopting appdata if they want to.  I also mentioned another issue before,  which is that we have two file formats,  one Jamel format and one XML format.  And that is also because Ubuntu was first and did it differently,  and Ubuntu format, which also contains app information,  which we want to have for software centers.  So, you also have to have fallback solutions for screenshots, etc.  So, it is getting a little bit more complex,  at least during the transition phase where not everything  is in the upstream XML format.  So, we invented LibAppStream,  which is like a common library every new software center  can use to access this information.  This will avoid that every software center has to  repost the XML file or the Jamel file  or the Ubuntu app install information,  or has to download the screenshots from...  has to detect the screenshots or download the screenshots from there  and also consider a fallback solution if the distribution offers one.  So, this LibAppStream stuff generates a sapient database,  which contains all the data for software centers to access.  So, the software center will basically only see the database  and not the raw data it was generated from.  Also, LibAppStream allows accessing the database via IGObject interface  because many people were afraid of using the native sapient interface  and the object allows creating bindings for almost any programming language out there.  This is how it looks like in the end.  We have an upstream plugin which runs inside the package Kedemon,  so it will listen to refresh actions on the package Kedemon,  and if it receives a refresh action,  it will check if the upstream data is up to date  and if it is not, pull the data from Ubuntu app install from DebianDep11  or from upstream XML, which all other distributions ship,  and then generate the sapient database.  As you can see, it also acquires information from different sources  and the clients, if they want to, can access the sapient database directly,  so they don't have to use LibAppStream.  So, what about upstream adoption in GNOME?  GNOME software was created last year with GNOME.  It's the only really fully upstream compatible software center out there.  It's fully supported in Fedora.  It's pending on OpenSUSE as far as I know,  and in Debian, it's blocked by the Debian 11 implementation,  which just needs some more time.  On KDE, we have APR, which is the KDE package Ked front-end,  which aims to be both a package manager and an application manager,  so to combine both words.  APR has some initial support for upstream by LibAppStream,  but that needs some more work because it's not working as well as we wanted it,  so there are some issues.  Update and inclusion into KDE projects is something we discuss right now there,  and I also heard about a possible port of the Mew and Discover stuff to package Ked and upstream,  so I think there was a lot of people working on that,  at least one summer of code project, if I remember correctly.  Yeah, on the distribution side, in Debian, I already talked about  if Wundru has their app install, which came before AppStream,  so it's not an invented tier syndrome this time.  It will likely migrate to Debian solution, but we will see what happens.  Fedora is Fedora.  They were pioneers on the AppStream front-end chip that stuff first,  and OpenSUSE has working AppStream XML,  but I'm not sure if it's used productively.  Last time, there were still ironing out some issues in the generation process.  So far, unfortunately, Onignome has a software center  which supports everything from the AppStream specification.  This is about the application management part,  so now I come to the application distribution part,  which is the Stuller's domain.  First, some background about the project.  It was started in 2008 as an experiment.  It was first never intended to be used productively anywhere.  It covered some features of PackageKit and AppStream that time.  It has its own package management abstraction layer just as PackageKit has,  and it has some metadata extension just like AppStream has,  but much simpler because of that.  It switched PackageKit in 2009 for communication with the native package manager.  Then later, it merged with AutoPackage.  I'm not sure if you remember AutoPackage.  It was started way, way before Stuller was created and shipped binary packages,  but then development slowed down and later it merged with Stuller.  We adopted some of its features and some of the projects which were created inside AutoPackage.  AppStream was then started in 2011,  so this part of Stuller was also obsolete,  so we revoked that thing from scratch, which took almost a year,  and now it only focuses on the distribution part,  which it does, in my opinion, really well.  Stuller's main goals are integration with the system,  so we don't want that the user has another installation GUI to install an application  while there already is a user interface with just the software center  or the PackageKit application installer.  Also, we don't want a second updater,  so if you update your system, if the user updates their system,  it should be one time thing,  so he has one updater where he updates all applications,  and not the second one like on Windows.  Also, the installed applications should look like native applications,  but they should not be treated as native applications.  So they run in a sandbox, have different privileges,  but because they come from a potentially malicious source  and they are not checked by the distributor.  Obviously, across this year and desktop compatible,  it should be simple because we don't aim for a catch-all solution with Stuller.  It should install applications, but that's it.  It should not install stuff like an init system  or install toolkits or everything which has reverse dependencies,  because this is the domain, the native distribution package management  that we are working in and where it makes sense to have it  while the Stuller is designed only for applications.  It should be secure, which means we have a security hints database,  signatures and a sandbox which is currently under construction.  We also ship some developer tools,  which basically help us to generate a statically linked application  or to make it relocatable or to do some automatic QA,  like checking all the validity of all file formats used in the application.  The basic concept of the Stuller is that it is a package kit plug-in  which explains the integration part,  because every application which talks to package kit  will also automatically talk to the Stuller  because it sits as a plug-in inside package kit  and catches all the Stuller packages which are passing through  and processes them before they reach the native back end in package kit.  If you don't know about package kit,  package kit has different back ends to talk to the native distribution package manager  and the Stuller just sits in between them.  Well, therefore, as I said, every package client is able to install the Stuller packages.  Also, this is the connection to upstream. The Stuller drops some XML  into the XML pool of upstream,  which results in a really great representation of every Stuller installed application  in the software center.  So if the XML is present, it will be automatically processed  by the tool which generates our sapien database for the software center.  And therefore, the software center will know that the...  will map the Stuller package to the application information  and display it to the user so you can uninstall it, for example.  Also, the Stuller uses a superset of the app data spec  as source for application metadata,  so every Stuller package will also include an app data XML file.  So if we are going to install the application,  we can already show information about what the user is currently installing.  Yeah, well, as you might imagine, the Stuller consists of many tools to achieve that.  It has some end-user tools which manage, for example, a database of trusted keys  so the distributor can set which sources are trusted  and the other ones aren't untrusted until the user adds the key manually.  It shows some developer tools to generate portable applications  to link against an older GLC version, for example, or the Simplify static linking.  It also contains some tools to track dependencies and to visualize them.  It also contains the offerings, packaging tools like lippkgm,  which is the Stuller package generator,  and a small QA tool which will, for example,  validate XML files which were shipped with the application  or check if the desktop file's integrity is okay.  So distributors don't have to worry much about upstreams creating crappy packages  because the packaging itself is damn simple,  the upstream can't do much wrong with doing that,  and the other stuff is checked by the QA tool automatically  so we can already see common mistakes.  It's just like Lintian but less powerful, unfortunately, so far.  So if you create a package, it's a YouTube-era package creation,  so really the simplest way to create an upstream package  if everything works as intended,  is that you have to write your app data description,  then write a small options file which basically just defines  if you want to make Listuller automatically detect all dependencies in your source tree  and which version of the Listuller package you want to create.  Then you need to write a file directory listing for the new package.  Listuller will later decide where to install that application  based on distributors' policy on that,  but you need to create the directory structure for the application by yourself  using some placeholders for the final path  which Listuller will insert during installation.  Then you can already build the package  because there's a small tool included which will detect your build system  and handle the installation part.  Currently, it does not work with many build systems,  so you can still give Listuller all the required information to build the application  or you can just point it to the binary stuff and package that.  So you don't have to build the application during the package creation process.  Yeah, this is... I will skip that.  Later, the package is GPZ signed,  so any package which is not signed will be rejected for installation  unless the distributor has lowered the policy to allow dangerous package installation,  so you can expect Listuller package to have a signature.  And during installation, Listuller will process all files installed by the package  and also do some modifications if necessary,  for example, adjust paths and desks of files,  or, well, do almost anything the distributor finds useful  in order to integrate that application.  Right now, it's really only take a look at desks of files  if they are sane and if they are in the right location.  Yeah.  So I will not talk about dependency solving,  which might confuse you, also no presentation without a cat,  because at the beginning I said Listuller should be simple  and dependency solving is one of the most complex things,  at least for if you aim to be cross-distributional as well.  So why have this dependency solving if it's so painful to do it?  Well, mainly if we statically link everything into one binary,  we not only use more memory because we have to load all that stuff,  but also if the distributor, for example, pushes an update to the toolkit,  which closes the critical security sensitive bug,  it will not reach the third-party application,  which also ships that toolkit.  So it is a potential security risk, which we don't have.  So it makes some sense to have at least a base level of dependency solving  for major dependencies, for example, system components like GLIP or toolkits.  So yeah, the main problems here is that we want to simplify that,  that the distributor might not provide enough metadata for Listuller  to find the dependency in the native distributor database.  So in that case, we can't sell an application if a dependency is missing.  And also, what do we do if the ABI of the dependency is not stable,  for example, if they decide to make some changes without bumping the so-name  and, well, the application just can't use it.  And also, what do we do if we absolutely require an old library version?  Well, the answer to the last question is obviously statically linked.  For the ABI stuff, there is no real solution.  We simply rely on upstream projects to take care of that  and don't break the ABI unless it's really necessary.  In order to enhance the metadata about available dependencies  in the distribution repositories, we created the so-called component files,  which simplify dependency solving.  I will go a bit faster here.  Components are, for example, toolkits.  I already explained that.  And to install a Listuller application, the cell only needs the basic stuff.  So all small dependencies which don't ship a component file  and are not available on multiple distributions should be better be included directly in the package.  They don't necessarily need to be statically linked.  You can flag that thing as a library and Listuller will take care  that the application can find it later after it was installed.  Last but not least, Listuller can, in theory, also satisfy dependencies  by downloading a statically linked package from third-party sources,  which might not be wanted by the system administrator, so he can disable that.  Listuller can also check Cpan, Cran, PyPy, or the gem library  in order to satisfy dependencies of Python stuff, for example.  So what is component information?  Component information can be compared to a non-developer package config file.  It describes all the component version and all the public interfaces it provides,  which are, for example, libraries or binaries,  but also stuff like icon sets or other data which is used by other applications,  other than the project itself.  So everything which is shared should be defined here.  Later, we can then, during the package creation process,  map the dependencies we found in the applications to a component,  tell the user, well, you are shipping stuff here  which doesn't have a component representation on the distribution,  so you might want to statically link that or to include it there.  And we can also check on which distributions the application will run  because we have this information and we know which distribution ships it,  so we can run the check like your GILI dependency is too high  to run on Ubuntu 14.04 or something.  Yeah, it also allows dynamic dependency detection,  dynamic version detection, sorry,  which means that if we ship the component definition with the package itself,  we can, on the users on the target system,  check if the dependency is installed without having to query the native package manager.  Well, I already talked about that.  As said before, we ship that DAF scan tool which is able to perform that task  and to not only detect dependencies of binaries but also Python models  and almost anything when you ship with the application.  Yeah, I'm sorry for being faster here but some discussion time would be wanted.  The future of the seller is, first, finalize and formalize the style specifications  because some stuff does not have documentation yet, although it's getting better,  and we want a formal standard for creating the style of packages,  so others can review that and check if it's satisfying their needs.  Also, it will result that in a stable package standard,  so we won't break the packaging stuff anymore.  As in projects, at least some should ship component definitions by default,  so we are able to send a query to the native distribution database,  for example, Instalami GTK3 bigger than 3.12 in version.  This is not only helpful for the seller but also for projects  which compare versions available in multiple distributions  because we can just check for component definition files  and then map them between distributions  and detect which distribution has which version.  This also will allow us to get rid of horrible stuff  like the Valve developers did with Steam.  They ship a small script called SteamDabs  which is heavily dependent on Dabian for detecting dependencies.  If we have component definitions,  Steam could just ship a package kit-based file  which is able to find all the stuff they need  from third-party sources in the distribution's own repositories  in a cross-distributional way without being dependent on Ubuntu or Dabian.  Of course, the seller should go into more distributions.  It's already shipped in some, but the coverage is not really high so far.  Maybe in the end,  I have a way for third-party developers to target all the new distributions  with one app package because it's really desirable  for upstream projects to have one thing that users can download  or access from a single source and then have it.  Then creating for one package,  short native package for every distribution  or cramming together some weird binary stuff.  Conclusion about all projects.  Well, I skipped that because you heard it just recently.  We welcome contributors to AppStream and to Installer  because there are currently very few people working on it  and it would be great to get more feedback  and to get more people involved.  It's not the most...  Apparently for some people, it's not the most interesting field to work in,  but I can assure it's an awesome place.  And we are all nice people.  Conclusion about writing free desktop stuff  which we experienced is that we should never do things  leading to the impression that we want to force stuff  coming from GNOME on KDE or coming from KDE on GNOME.  It sounds natural, but it's really easily done to talk  in a way that sounds to people that they would get stuff  which was developed for GNOME and then is dumped on KDE  with an argumentation, well, it's a standard.  Please implement that stuff.  Why? Because it's a standard.  We have to take everyone with you if you want to succeed with something.  On the contrary, sometimes you need someone to just go ahead  with the project and have the others follow.  The AppStream stuff was stalled for a very long time, unfortunately,  because there were not enough people working on it  and there was some stuff missing.  We had some issues with the canonical CLA, for example,  to get the software standard available on multiple distributions  which in the end failed, so GNOME software was created  but it was just delayed.  We also needed Fedora to really push for AppStream  in order to make it happen on more distributions.  Also, it does not make sense to invest too much time  in bike setting about details in the same manner.  You should just go ahead with implementing something  and users will complain about that later and then you can adjust it  instead of debating about hypothetical stuff beforehand.  That's it.  Do you have questions?  I've got a microphone up here, so folks who have questions,  let's use this so it ends up on the video.  We'll take questions in order of rows, so if you're down here  and you forget your question, we're not going back.  One question.  Does the installer package provide a post-install, pre-install hooks  like the Vian packages, for example?  It provides...  The package itself is not able to run any script  because we execute it with root permission  and therefore we don't want, at least not during installation phase,  the packages able to execute any script.  What is happening is that the installer will scan  what is available in the package and then decide  what is the best thing to do.  For example, if it ships a desktop file,  it will later update the desktop database.  So it is doing that.  And if the person who created the installer package  wants to do something which he or she would need a script for,  they could just file a bug against the installer  and we will implement that for every other person as well  in the installer directly.  Thank you very much for the upstream.  It's really, really needed.  As an upstream developer, I tell you,  we need some tools that protect us from distribution maintainers  to actually fuck it up.  So it's the opposite.  My question is about this DEP11, I think it's called,  the new universal DBM thing.  What is, can you tell us more about this process  that is ongoing?  Well, it's a DAPI thing.  DEP is a DAPI extension project.  And this file will include information about components.  So the component data I talked about under the installer site,  but also information about the applications  and stuff like codecs or kernel modules.  So we can, if something is missing, if an application misses  a module which would be necessary to work, for example,  if you have a video converter which needs to convert something  but some GSTRIMO module is missing to do that,  it can make a package kit query to find out  which package provides the missing component  and can afterwards install it.  So what we do with DAP11 is to push all this metadata into one file  and make it available on every DAPI distribution  using apt and enabling this feature.  Which, it is just for DAPI.  The file format is independent, of course everyone can use it.  But yeah, the thing is mainly about DAPI.  I'm currently working on implementing that stuff  in the DAPI and ActiveKit.  So I hope this will get ready soon.  Do we have one more question?  Do we have time for one more?  Okay, great. Thank you very much.  APPLAUSE  Very good. Thank you.  Thank you.  I was way too fast.  I was way too fast though.  You know, I think that people  so like most people, the rate of speed you talk  when you're talking to most people is way slower  than they can take in information people tend to get forward.  So if you talk quickly during a presentation  people actually like that because they don't get forward.  I thought it was great.  Yeah, and so.  APPLAUSE  Yeah, I'll show you this real quick.  There's not a lot to it.  I didn't think so.  APPLAUSE
_FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_0_407.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_408_1727.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_1728_1847.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_1848_3107.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_3108_3647.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_3648_4007.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_4008_4427.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_4428_4787.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_4788_6251.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_6252_6419.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_6420_7511.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_7512_9131.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_9132_9623.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_9624_9899.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_9900_10499.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_10500_11591.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_11592_11975.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_11976_12563.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_12564_13499.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_13500_16535.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_16536_18455.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_18456_18731.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_18732_19319.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_19320_20975.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_20976_22103.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_22104_25823.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_25824_27827.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_27828_32123.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_32124_33443.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_33444_34067.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_34068_34511.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_34512_38651.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_38652_41063.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_41064_42503.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_42504_43739.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_43740_46415.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_46416_48335.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_48336_49355.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_49356_51995.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_51996_52751.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_52752_53219.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_53220_55043.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_55044_57371.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_57372_58139.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_58140_58319.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_58320_58523.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_58524_59003.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_59004_59591.png _FOSDEM_2014__AppStream___Listaller_DBkBQxnGXmQ_59592_59814.png