 To say, give no options, then you take the default, which is to update and upgrade whatever the current package state is. So you can see it generated a signature file with details about update and upgrade. Now, let's assume you take the signature file, update.urize on a USB stick, and switch to a Windows box. And on the Windows box, you are supposed to run the get operation, which is for get, you can just simply run get and give it the file. And maybe you can increase the number of connections so that we can quickly complete the demo. And you can also create a simple archive file for simplicity update.zip. So when you do this, any platform which supports Python, it will be able to download all the APT database, package database, and other things. So this turns out to be a Jesse box. I'm Jesse Willis, so it's pulling in Jesse. This operation was not supposed to be run as root. It can be run as normal user, but the set and the install operation, APT requires them to be run as root. So as you see, it created a zip archive, which has all the details about package management, and the user does not have to worry. He can just copy it onto a transfer to a USB stick and take it back home to the Debian machine. So we're back to the Debian machine, and you can just say, in this case, you need root over here, apt offline, install, and give it the, what is the name, update.zip. And so it did everything. It has updated your APT database. It ensures that all the packages that have been downloaded have not been tampered. For that, it ensures that it verifies the signature of every package database file. I'll just extend this example a little bit more and create a new set of, okay, set an example of, suppose you want to install a new package, and you can give an option, install packages, and let's say Emacs, which may have some more dependencies, and it will create the database for Emacs and all its dependencies. You can go back to the Windows box and say the same thing, perhaps with Emacs.zip, and what was the name? Install it for us. And you can also download bug reports on the offline machine, I mean, for reference on the offline machine, if you are interested in knowing what were the reported bugs at that point in time. So you can just say bug reports, but this is only supported for the Debian BTS. And if you do this, it will download all the packages and the dependencies, and in the background, also is downloading the bug reports for those packages. The progress bar is not very complete. I had to write a progress bar, which could work on the Windows command interpreter and it's a little painful. Yeah, so this is something which is fixed, but in the version that I'm running here, it's not fixed. This is happening mostly due to multi-arc packages, for the same package name, you have multiple architectures, so in that case, the bug reports are common. Think I'll just complete this one. Meanwhile, yes, sure. Okay, I'll just, since it's still downloading the bug reports, which is slow, App to Offline also has a graphical user interface for people who may be more interested in a UI. It's written in PyQt again, so it works on Linux, Windows, and Mac. Okay, we have one question, I guess. My question is about whether or not the signatures, and I know that the app has some timing constraints for when app signatures are considered legitimate, and if you're offline, maybe your clocks are not synced, if you ran into any issues around unsynced clocks and the imports of the keys. Like, have you tested this with a clock that's set in the future, for example, on the machine that's doing the stuff as root, or tested it with a clock set far in the past to see how it behaves? I never thought about that at all. Maybe I should go test it, but the only testing I did was ensuring that the integrity of the downloads are legit, not tampered with. Okay, so one of the app attacks is a pinning attack where you only show people the archive from a date before a critical fix entered so that the person can't effectively upgrade, and the signatures I'll check out in that case is just old, so it's worth testing it against the different synced clocks. Okay. Very cool, by the way. Thank you for working on it. I have a minute, so actually my download is complete, so I can just wrap it up saying that if you run app.offline.installemax.zip, since there were bug reports for Emacs, you have all the bug reports listed and you can take an example of seven, nine, one, eight, one, eight, and if you do, you get the entire bug reports, as it is, and you can decide whether you'd like to upgrade or not. That's pretty much about app.offline. Thank you very much. Just as a reminder, if you have a question, please wait for a microphone to appear in your hands and then ask the question. Oh, whilst we, whilst we faff about a bit, please welcome Yol, who is going to talk to you about right, sorry, I can do it this way, right to left support in LibreOffice and he'll be ready in a moment. The clock is ticking. A bit about right to left issues in LibreOffice. I guess that this is, except for maybe the resolution, should be very familiar, regular LibreOffice. Who here uses LibreOffice? It should be fairly reasonable. So we're going to go over how it looks like in right to left mode and then add a little bit of translation. First, we'll show how it looks in right to left mode. As you can notice, all the menus are on the right side and the direction of the items is also shifted. So the new button is actually here on the right side and the menu open like this. Okay, yes, I know it looks really weird and that's with the English translation. A little bit at the beginning. At that point, we still don't have any directionality. There's a difference in when writing text between the alignment of the text, like let's have text to align to the left, to the center, to the right, but there's a difference between where's the dot is and this is directionality. Currently, we're still in left to right directionality. So this is why the dot is at the far end. In this interface, because we only change the interface itself, we don't have directionality options. So what I'm going to do, just install the Hebrew support, which also the mother turns on the directionality features and we don't need this anymore. But first of all, although we have the Hebrew support, it's still an English interface. Excuse me for doing this behind the scenes, but it can be done from the interface itself. Okay, so it looks quite the same, but it has Hebrew translations. But, okay, we enabled complex text layout, which is CTL, this is the software here, and it says Hebrew and whenever you tick this one, you have a few more buttons in Hebrew of this and let's see where it is in the interface, probably somewhere here. And yes, this is directionality, okay? I switch back to English interface so you could read it as well, but it wouldn't be just me who can read stuff. So these are the two buttons which are added and control the directionality. So if we had text and a dot, now the dot goes to the other side. And this is regardless of alignment, okay? These are totally two different things, which directionality and alignment cause hell for other languages, although usually native speakers to English or any Latin language are not familiar to the directionality, it causes many troubles. LibreOffice has a few more bugs regarding supporting different directionalities. And for example, I'm only going to press the right arrow button. So I'm going from one cell to another, and then going right, it just flips cells. It's a weird bug and I can't actually reach the middle of that cell, okay? This is just because of directionality issues. These kind of bugs appear in a lot of places in LibreOffice or for that matter, any software that try to support right to left. Thank you. And we here have even more complex bugs we're trying to mix in English for the middle of a Hebrew sentence. Trying to control where the punctuation mark goes, especially at the end. What happens when a sentence starts with an English word, then let's say GTK thinks the whole sentence is in English, but the rest is in Hebrew, so there's sometimes needs to force the directionality. One option, let me get a new one, yeah, okay? So one of the things, oh, of course, for those who see comments are on the other side, obviously, okay, compare it to English. We can insert, also can insert special marks, and well, I'm not sure if you all support RLM and LRM which force the directionality, which sometimes we need to add to different sentences in order to force it to be seen correctly. For example, sometimes in the Debian in story translations or other translations done by me, so it's mostly Debian. We put these kind of marks to force the display setting. Any questions? Thank you very much. Oh, yeah, wait, question. Wait, wait, wait for the mic. Doesn't work. Please one up, please. Up, test. This other one? Test, test, test. Okay, thank you. Okay, so ask me and I'll repeat the question. It goes to the video. It's the same problems for Arabic, Farsi, Urdu, which is in Pakistan. Although Hebrew is spoken by very few people in, you know, relatively to other languages, computer-wise we're doing quite a lot of noise and especially in other products with open source or without open source, usually support for Hebrew considers quite well. I'm trying to influence delivery office developers to fix all the bugs, so I try to do a yearly or bi-yearly status report and next month I'm going to the conference to talk to them personally, so each year I'm trying to fix a few more bugs. Any more questions? Thank you. Thank you very much. Just want to move on, then my next up is Impey talking about Black Box Automated Testing Operating Systems, how do you do it? Please. Hello? Test, test, is it okay? Test, test. Test, test, test, test, test, test, test, test, test. Test, test. It's not loud enough. Not loud enough? Yeah. I think they think it's very quiet. Test, test. Test, test. Okay? Test, test, test, test. Yeah, yeah, okay. Should I just start? Okay, so, hello. I'm going today to speak about how we test tails in work. The tails is an operating system, it's a live system and we have, in the last few years, developed some kind of testing framework that could be possibly reused by other projects. So I'm going to introduce how to do it and show it a bit. So the way we do it is that we mostly do integration testing, that is, what we care about is mostly testing the exact product we're going to ship to users, not isolated parts. We want to see if the entire thing works together properly. So we are not doing much unit testing, we are doing some, but that's not what this talk is about. So that's no big news. I mean, lots of operating systems have integration tests. What is maybe a little bit specific to the way we're doing it is that we are focusing on black box testing. That is, we are testing the system from the outside. We are trying to, we try to interact with the system under test, that is, a running phase, in as much as we can, the same way as most users would do it. Which means we don't trust the system under test. We are not asking the system under test, hey, did you manage that? We are clicking buttons and stuff like that and checking either expected results, appears or spoken or something. In contrast, many other integration testing of operating system have seen use the, use accessibility interfaces discovered over D-Bus, which is fine because you actually test that you have accessibility support, but it's also cheating quite a bit. You're always actually asking the system over test if it's behaving properly, which is not the way we prefer to do it. So I'm going to start with showing some short excerpts of the day's automated test suite running. It's a video and then I run some more live. So as you can see on an agnome interface and here what we are trying to see, it's verifying that evens can open PDF files and print files in the home directory. As you see, it succeeds, we're happy, we go home. And then we are going to test if we can open a PDF file from home, it still works. Why are we testing that? It's mostly because we are shipping a power profile. That restricts what evens can do. So we are first testing if it works in the places where it's supposed to be able to read and write from it too. And then we are going to test, maybe not actually, yes, we are going to test whether we can open a PDF file that's in OmGnoupiG. And the result is that we won't see it anyway. We have a forbidden message and we actually see also checking in the kernel logs if Aparmore has logged the denier. We can do a lot more. We can also pretend to install days on a USB device. In this case, we are using Libvert and it can emulate virtual USB devices. So the next test case we'll see is to clone and install days on a USB stick and then rebooting, setting up a person volume and then doing basically the same events test. So for this one framework is based on three main tools. One is Libvert. Libvert, we use it to manage VMs, start shutdown them to manage snapshots in order to make the whole thing a bit faster. We use it to manage networks, storage, including virtual USB sticks and quite a few other things like memory snapshots and shared folders. So the second tool we are using intensively is Sikuli. Sikuli, we use it to interact with the operating system. That is to find images on screen, like buttons and click on them to emit input events like clicking and typing text. And we don't use it's OCR feature because in our experience it's very suboptimal. And all this is driven by Cucumber, which is a Ruby tool that allows one to write tests in a kind of human readable way that can be used to discuss with design teams, UX people, users. For example, before developing new feature, you can discuss with the other stakeholders how it should look like, how it should work. So I'm going to show you how some of these test definition look like. So for example, these tests checks that Taze does not leak the hostname when over the land, when doing DHCP requests. So that's, we're not very good at writing these things in a very nice way, but at least it's more readable by technical people than many or most other ways of writing to make tests. So it's, you're writing this way and then you have to implement each step, that is each line in another file somewhere else. That's more or less the same, but a bit more complicated because here we are setting up a new network manager connection to make sure that our tweaks apply not only to the default connection, but also to manually configure the ones. Let me go on showing some bits of this. So the next test case is about, we also, we have some test specific bits in the test suite like we're actually sniffing the network, the VM runs in constantly and after the fact we are checking that no connection was sent to the internet without going for talk. And we have tests that should fail when we check the fail. Like here, we are using the NSF brother that is this special web browser and tail that is allowed to go out without tour. And so we check that our test suite frameworks actually notices that there's traffic going out without tour, which gives us more confidence when we are testing that we cannot find any otherwise. Okay, yeah. So the, yeah. So that's it. Equally, you can go on the third. So we have a few test specific bits and more ideas about how it could be used elsewhere. That's the main purpose of this talk. So a few months ago, is the whole girls tried to extract the framework from the tail's get three and reuse it for the DIY installation, DIY tests. And it's the effort stopped mainly thanks to the affordable build with vertex, but it's not impossible at all and anyone could do it. So we could use that to test for example that you can just upgrade from JC to stretch graphically from a desktop. We could use that to ensure some sanity checks like we have no services listening to the network except SAGD, stuff like that. We could use it for app armor. We do that in taste a lot. It could be done in Debian. It's also a good, a nice way to, sorry, sorry. Yeah, it's also nice way to describe what we're supposed to support. That is to describe a minimal feature set and negotiate it with other stakeholders, users, design people and all, and then make sure we have no regression in the new Debian release. And ideally I'd like to see it used in integrating to auto package tests. I have no idea how it's doable or not. And I also think we also have some tests that you can check that we, an application is playing audio, which could be test used to check that our car for example probably reads text, it's supposed to read. That's it. That sounds, we hear me, but we don't hear the computer. For the computer. We, I don't know how to say it. I don't know how to say it, I don't know how to say it. I don't know how to say it, I don't know how to say it. So what's that? Oh, it works, but well. Well, let's go. Okay, thanks so hello everybody. So I would like to introduce to you today the work which is done by the HEPRA developers. HEPRA, which is a company which tries making a fully universal Debian to make it universally usable. Indeed, as we know Debian is the universal operating system because it can be run on various platforms. But I would like in my dreams that also Debian could be used by really all the people who tries to use free software and the computers. And especially I would love that the site and the problem which can be present when you are blind or we have problems of the site are not present. And for that, here's somewhat what we propose, what we provide and the developments we started doing and how it can be shipped in Debian. The first thing is, well, it's a French system of course because it's originally a French system but you recognize everyone can recognize that it's a mate desktop. We chose mate because the GNOME 3 experience was absolutely terrible for us for various reasons. Firstly, because when GNOME 3 was released some years ago, it wasn't accessible at all. It was so less accessible that some Debian developers which is blind left Debian. And also because GNOME 3 today which is more accessible indeed, is yet very difficult to understand for a blind people. Difficult because there are some panels but we don't know where are panels, where are icons, icons and how things are organized. So for any people, for beginner people it's very difficult to train that and to learn that. That's why we chose mate but the first reason. On mate, we can move on the desktop, moving the keys and the arrow keys. We added on mate a layer which enables the speech synthesizer as you can hear. This speech synthesizer which is based on the orchestra reader and a speech synthesizer which is not free, unfortunately, enables the people to have the full control of the computer without the help of his eyes. So it is very important for him. For example, it can go in the panel to choose the program he wants to run. Accessory module, accessibility module. We chose also library, 4.2. Why this release and why it's different from the official library in Debian because in 4.2 there are not some accessibility bugs which exist in the official library in Debian. So we chose this release to be sure that the user can have a good experience. And I talk about the beginner user, the basic user. In writer, from the screen reader, we can have access to all the parts of the screen by the keyboard and by the screen reader. And on mate, I need to precise also that we have such access to the panel, the top panel. How many? Five minutes, okay. So of the top panel and of the bottom panel. Then on this layer, we added a compose layer. Why compose? Because compose enables visual effects which can be very interesting. For example, we can easily with comps apply a zoom with this combination. And oops, I don't have the tree first. And we can also do some color tweaks. For example, to revert the colors or revert the colors. It's the easiest for me to have such technology. Of course, so it can do a color reversal. So thanks to that, we have a PC that can be used by blind people, by people who have sight problems. And that's people who are blind or people who have a difficult vision. And to finish, I would say that we access by that to ice whistle, to ice dog, and all the accessible debian applications. And to finish, I would say that if we choose mate also, it's because it enables to not follow the theme's logic. For example, if you are not happy with the coloration of some bar, of the coloration of some object, you can change it in the mate preferences menu. Alboge, bureau cad, sit here. Preferon, adobe, app, app, app, app, app, app, app, app. You can choose. Vianne, con panos, con control, boge. Vianne, con panos, con control, boge. Preferon, de la app, app, app, app, app, app, app, app, app, app, app, app, app, app, app, app, app, adobe, app, app, app, app, app, app, app, app, app, app, app, app, app, app, app, app, app, app, app, app. Here you can choose the appearance of each object of your theme. And it's much interesting, very interesting because in the GNOME 3 or the typical desktop today, you cannot do that. And so if you only need to turn the colors of the mouse, of the color of such items, you cannot do it. With mate, you can do that because the customization is fully possible. And so it enables a universal access to the computer and it enables Debian to be quickly universal. So that's, we hope to upload in the next Debian, at least in part. For example, we are searching for a mentor to upload copies so that we have these effects and we can set Debian to have this. And it enables to have that in Debian to provide a fully accessible system also for the beginner users. And this is a simulation for all boys. I go, I'm waiting. Now, but Mario, it's very interesting because I didn't know you were here. And I'm very interested in that. Now, but to be honest with you, I was very careful because I didn't want to speak for him because, well, I'm not him. But if he's here, I would be very interesting to know what you thought about GNOME 3 and why you, well, you stopped maintaining GNOME 3 two years ago and maybe you could explain why you preferred to choose Mac instead of Linux today. And if there is a right reason, and I think it's very interesting if you could explain it. I think. I have a second that I can use that then I do not see everything they care for the box that's been coming. So it really has to give up on to at least something in the process. That's exactly what motivated us to try to back to GNOME 2 to find back the accessibility, the full accessibility and the reasons for which today also, GNOME 3 isn't very used because it's very a problem for us today to be used in the daily life for the people in the computing in general. Yeah, thank you. Thank you. Bye for all of you. Well, it was really interesting. Oops. Thank you. Oh yeah. Okay, so set a timer for two and a half minutes. Is there an HDMI? Ah, perfect. Okay, yeah, Nadi, set it up, wow. Set a timer for two and a half minutes and we'll see what I can do, great. Oh yeah. So I'm going to show you storm.debian.net which is a sort of Google Docs alternative that anyone involved in Debian can use for Debian stuff. So I'm gonna zoom out. Okay, great. So this is what the main dashboard looks like and I'm gonna make a text document and share it with people in IRC and then I'm gonna sit down and you're all gonna keep chatting without me. So in Sandstorm, which is the software that powers this, you can click install apps. We'll install Etherpad. I'll click a new Etherpad document. I'll click share and I'll make a link that I can publish on IRC. Great, great. So now everyone in IRC, please deface my pad. So I'm hopeful that Debian people can consider using this as a possible alternative to Titanpad because one cool thing about Sandstorm is you can upload your own packages. You're not limited to whatever Titanpad does and the other advantage of a Titanpad is that you have this sort of home view where you can see the documents you've made. So I'll go back into this one. Come on, hopefully someone's just, yes, great. And in order to use the service, as any of you can use it, you'll have to email me to get an invite which I'll send to you. Great. And Clint said he would co-maintain this with me. I don't know if Clint's in the audience. Okay, but yeah, you can all use this. The front page of storm.debian.net says how. Thanks. So this is a rather short presentation, only seven slides. So it was originally planned like a for a lightning talk but I managed to hand him a proposal that late. So yeah, yay. So now just full size it somehow. I'll full screen it and then I'll show you. Okay, so I'm presenting today duck the Debian URL checker. The reason behind this is function. Yes, thank you. Yeah, the reason why I did this is exactly this. You see a depth checkout box everywhere and then it, yeah, it says physically a depth checker does not work. There was look, and I was like, it was in a time I was trying to get my, to increase my involvement into Debian and it was like, okay, this should be fixed somehow. And then, yeah, there are many like in the control file, there are several rules defined. For example, you have the VCS Git URL or the VCS browser URL, which in this case shows me the repositories throughout probably you already seen the screen. Yeah, the whole thing is I checked those links and entries in the control file on a daily basis. Kind of we have about 2,000, yeah, 2,300, something packages which have broken URLs. These are either home pages or upstream, yeah, upstream home pages or problems with the emails of the maintenance or yeah, any other problems with URLs. And there's also a package away level which you can run locally and this also shows all those information for you and I made a challenge. So if you like fix one of your packages until the end of DevCon 11, you get one of those awesome lighters. I know this is kind of like a short time so I have a bag full of them here and if you really promise me hard to fix your stuff then you can take one out. Thank you.