 Okay, I guess we can start. So welcome everyone to this Debin mobile buff. Initially I had not planned to do it because not much had changed since last year, but because we are several people that were discussing these topics and yeah, we had still some changes since last year so it was just a good idea to refresh. There's a Gobi document mostly prepared by my peer attendees in Debin mobile and I wish this could can be a buff, so if you have something to say just raise a hand, we'll give you the microphone and the goal is I'm not here to present things, I'm here if we can somehow create a motivation for work to be done and instead of good discourses. So the agenda is to have an overview on where we are so that we are here to keep Debin relevant for mobiles. I think if you are here it's because you are somehow convinced that it's a topic that is very interesting for Debin and that is currently not well served by free software. The intention is then to review changes since last year and what we should do now. So inside Debin you want to present or I just click through. Okay, so the EFL stack, Enlightenment stack was mostly updated to the recent versions. The FSO which is the networking stack that was into OpenMoco upstream work with us to get their recent release into Debin so we also had an update into Debin. There are various people involved in Debin mobile that bought some virus devices and the hope they could run Debin on it. It hasn't been successful as far as I know. Another achievement was the Debin mobile email list. We had several discussions on Debin Devil and then on Debin project and whatever to have this list created which is Debin-Mobile at least at debin.org. The discussion was also around what this list should do because we already have lists for kernel discussions. We also have different lists for everything that is in between and the focus of this list is mostly everything that is presented to the user in terms of user interfaces and stuff but is not supposed to concern how do I build a Linux kernel for this or this device. So the list was created I think since last year. Since the moment it was created it has seen something like 25 to 30 mails so it's not a huge success. Not many discussions have happened there and some of the mails were just not at the right place at least not in the place as how we saw it. RC also opened which is Debin mobile on OFTC. We have mostly poll doing Twitter robot for us and pasting comments or URLs with relevant information from time to time. And I think anyone wants to comment on the thing? I didn't want to speak but I'm still speaking anyway. Outside Debin, the GPU driver reverse engineering project for our Mali Qualcomm and Dano PowerVR FIMJ 3DSC. So various projects are also beginning to get some power. The Android Linux kernel stuff is slowly merging into mainline as far as I know it's far from complete but there is a work in progress. The KDE community released Plasma Active which is a variation on the Plasma desktop that is installed by default on Debian KDE which is aimed at finger interfaces and tablet style interaction with Debian as far as I know Plasma Active is packaged in Debian is somehow working but not all parts of it probably. And the KDE community has been working on the Vivaldi tablet, you have probably heard of it. It's a supposedly completely free tablet that was released and is to sell with completely free open source stack up to Plasma. The underlying stack is mostly MIR based which is the rebirth of MIGO, whatever thing RPM based but it's a tablet that supposedly runs free software. As far as I know there are still some proprietary blobs but okay. OpenMoco Replicant, FSOS, HR, Synergies and expansion of hardware support. So replicants, as far as I know. Can you explain just a word? So Replicant is a fork of Android to replace all the non free blobs mostly most of that stuff is hardware enablement and they're doing a lot of reverse engineering work to help port Android to devices so that you don't have to run any blobs when you're running Android. That part of that work is also writing libraries so that other platforms can use those libraries to support the hardware as well and that includes FreeSmartphone.org and SHR and Debian or whatever. Cool, thanks. We have also seen the rebirth of the OpenMoco through the GTA 04 platform that is becoming available as far as I know it's a PCB that you have to put into an existing OpenMoco so that it's supposed to fix the bugs that were in the GTA 2 and 3. From OpenMoco, there's also Canaima which is a Debian derivative working with hardware vendors to produce Canaima mobile. I don't know much, but if someone can tell a word about it. Canaima is a sponsored distribution by Venezuelan government and they want to build a Debian phone with based on Canaima, Venezuelan and they are working on it. I'm not sure what else to say about it. Then we have also seen Mozilla starting Boots2Jecco, FirefuckOS, whatever things that Boots navigator and the Migo community that was born after virus merges was closed. Memo is being defunded and virus projects split out from Memo and Migo as a result. And so Jolla, like last week, something like that created a Twitter website to announce some work. We have seen more Nemo, Koryata et cetera, so the whole Deb-based Migo dream just evaded in smoke. They also released Tidzen, which was made by mostly the same people that were doing Migo, but with a complete restart from scratch, involving Samsung Intel, which is supposed to work with EFL, so Enlightenment and the kit repositories indicate that it's Debian. They've been to a heritage, but they have mostly been just putting every package into a git repository with initial commit and not, yeah. And WebOS has been freed. Okay, open discussion. What should we do now? What should, can we put in Debian? What should we put in Debian? Should we just give up now? Yeah. Up to you. Now sit down. Who wants to sit? Well, I think it's very important for Debian to keep relevant in the following years because we, desktop is really losing traction and mobile devices are more and more in the hands of people. And we have the problem of the base drivers and kernel support and binary blocks for 3D acceleration and all these kinds of problems, which is particular to each specific device. So that's probably have to be, not sure if some place like Linaro or some other foundations or institutions can deal to solve that problem. And I think Debian should maybe provide a way to integrate those pieces easily but not provide them because it's not compliant to the Debian software license. And also then we, the main problem with the OpenMoco has been the UI. So I think it would be nice to pick up some project upstream and bring the UI bits so we can use on mobiles. It strikes me that one of the major problems with putting Debian on any mobile device is the howler. We just don't understand how to interact with the hardware. A lot of devices come with Android. Can we regard Android as actually a Shimler under which, within which Debian services can run? If you imagine the Freedom Box, that has no obvious UI but you can run that in maybe an LXC container alongside Android. All you need to do is to take your Android phone, route it, and then you can install, for example, busybox-based systems at the moment. It's been fairly well tested. And it means you can use a version of an installer to install, to can install at least parts of Debian. As far as I know, there are applications on the Android markets that just install a Debian truth in which, yeah, then you can install Debian packages on the run on Android but the kernel is not free. I thought about a slightly different approach which, again, doesn't get you to a free kernel but it gets you to a lot of hardware enablement quickly and that is to just go take the Cyanogen mod build tree which has kernel and binary hardware device driver and so forth support now for dozens of different commercially available Android devices including current technology like, you know, Samsung Galaxy S2 devices and things like that, like the one in my pocket. And what if we were just to, you know, my original thoughts were, gee, wouldn't it be cool to take a webOS build tree and the Cyanogen mod build tree, slam them together and immediately have webOS builds for everything that Cyanogen mod had hardware support for. Wouldn't be 100% free because you'd still have binary blobs and the kernel and all of that but it would get an interesting user space up and running on a lot of different, you know, available pieces of hardware. The exact same approach could of course be used to drop, you know, some sort of a Debian packaging, you know, a system on top of, you know, these kernels and boot loaders and hardware support pieces that are out there. I think that this is one of those places where because of the nature of the devices that are being created, if we want to focus on building upper levels, you know, relevant user interfaces and things like that, not sweating in the short term that the hardware we can get is not possible to do great, free, completely freedom loving kernel and device driver support for and just co-opting the work that others have done to do community builds of Android for a lot of these devices to get the hardware enabling kernel pieces and then layer everything else we want on top of that, might be a way to get to a point where we can build a critical mass of users for some stack which then one or more vendors might be motivated to do purpose-built hardware for that actually would have the characteristics we want all the way down to the hardware. Which would mean some sort of Debian on Android or... It's not on Android, you know. So to be very clear, this is, to me, you know, Android implies that you've got the Dalvik, you know, virtual machine stuff and all of the Android related content above that. To me, what I'm talking about is taking the build trees and use, because they all use a Linux kernel and Linux kernel device drivers, many of which are in binary blob form. But what if you just, you know, use the portion of that build system that got you a working kernel and hardware support and built the rest of the stack on top of it? I don't care, you know, anything Android is in that stack or not. I happen to think Android devices are just fine in terms of utility, but they certainly are not just fine in terms of the number of sort of cloud dependencies they seem to sort of lead you to build out of the box and the way lots of other things in the stack work. So if we could build a completely free Debian style stack above the kernel, you know, imagine just using the kernel and hardware enablement support that all these folks working on, you know, Android community builds like Cyanogen Mod have done and then layer on top of that the rest of the stack that we would like to have on our devices, then maybe eventually get somebody to build a device that doesn't require non-free bits between our stack and the hardware. So that's a good idea, but I think it won't actually just work, or at least it would work, but you wouldn't get any power management, which is a big deal on all these mobile phones because that's the bit that's completely different between Android kernels and real kernels. So whilst it'll probably work, I think we'll find there's some ifs and buts, but it's worth a try because it is an interesting idea. I'm just not sure it'll actually just work like that. It's not quite that easy. I represent a commercial company who is using Mdebian to produce devices for the disabled people that can't speak, and it's wonderful. We've got something which will not change every one and a half indexes. We supply to the national health system in the UK and they require that we support devices for seven years after the final product is sold. If we use Android as a target delivery platform and have Mdebian running alongside it, it means that we can have our long-term support in Mdebian and we can track the shifting sands of new hardwares that comes out every year and a half, and Mdebian is never going to be able to track that. But there we have commodity devices which can be then targeted by Mdebian, and we can use it immediately, assuming that support to a particular version of Android. It's a way of keeping Mdebian relevant because otherwise we're just gonna be behind the curve continuously, maybe. I just comment who will do work. Maybe you comment on the Migo idea last year. I tried to package it most of the stack and I mean, it was based on Qt, so most of the Qt was in Mdebian and it was rather easy to start from that. The problem was project management and sanity, mostly, because the interfaces, both binary and code interfaces, were changing every two days and they had no idea of tagging or whatever and the complete stack was moving all the time and it was completely unreasonable to package this race reasonably in Mdebian or we should just have frozen a specific date and hope everything works. But I was mostly alone doing it, so it's also quite a huge pile of work because you have like tens and tens of packages of virus things that do various things that are not testable on our devices because it was mostly developed for their in-house products that were not yet out, so it was, it'll actually release in the end, yeah. So, yeah, sorry. So, I mean, so Mimo's now turned into Tizen, which is similar but different again. HTML5 instead of QT instead of GTK2, whatever the front end is, and I guess we don't really care about that as long as we can package the parts that actually make it a useful UI. So, I don't know if anybody's looked at the Tizen stuff yet. I've been to a couple of talks showing me what shiny things you can do in HTML5, but I haven't really understood the structure yet and kind of the same question for Weboss. Does it come in sensible sized parts that are amenable to packaging or is it some crazy pile of poo that is gonna be really hard to actually use? I mean, I've seen, a lot of people at ARM have been buying Weboss phones and going, hey, these are really cool and they're actually reasonably free and it's not Android and it's good. And again, the design seems sensible. So, I'm actually quite interested in having a look at that, but I haven't yet. Has anyone here actually know what we get, what we don't get? So, we have no clue, it turns out. Maybe we should look. Yeah, one of the questions I also had in that domain is what do we miss in Debian for something, boots to a gate check or something like that. I mean, we have almost all tools to boots to navigator full screen standard one user, but what does it mean to have an actual WebOS thing that does things in the navigator that we don't have yet? One of the things of coming out of the box is trying to have people testing all these technologies and have a play with Tyson or WebOS and see how difficult can be to package it or all these kind of questions and maybe write a report and send it to the main list so the rest of the community can discuss about it so that will be a helpful start. Sorry, so I have lots of interest but I haven't any work for ages so I have lots of questions and no actual answers. So, I had an open Moco and it kind of worked. Didn't work very well with Debian because the UI was wrong and you couldn't use your fingers and it was all tiny and crap and the battery went flat immediately. So, I put SHR on it and that actually worked quite well and that was the phone, O-phoneOS UI. So, that's right. No, O-phone, something. For a FSO, yes, that's it. So, that seems to work. There's been a lot that's been packaged for Debian. So, is there in fact any reason why that isn't adequate as a UI? Do we need to look at other ones? Is it kind of just old and crap or FSO? I mean, does that in fact do the job to an adequate level for people's uses or not? Thank you very much. Paul told me that FSO was a free stack and it was more aligned with the Debian philosophy of doing things while the others all of them have like some binary hidden thing and so FSO was nice but it's not like the latest thing or as fancy or having HTML5 or it doesn't go with newer technologies or at least that's what I understood. I may be wrong in talking crap because I haven't seen it really. As the developer who was responsible for taking out the OpenSync framework which was another kind of thing in this area and I'm really quite worried about FSO as well. The thing, the problem that comes up is doing a release freeze. Packages and frameworks like Debian Mobile wants to use they seem to become abandoned. They seem to become just bit rot in the archive and they frequently attract failed build from source. They frequently find that the maintainer's not responsive and therefore during this release process they frequently get removed. What are we gonna do about that? How can we keep these frameworks alive so they survive into stable because that's where users want them to be. So I'm following the FSO seed channels the OpenMaker community channel and FSO itself has been continually developed and they're adding new hardware support and stuff like that. In fact for the Weezy release they worked with Debian to get the latest FSO release into Debian. So for me community based projects like FSO are important because we can get involved and contribute to those projects more easily than something like Android which is completely controlled by Google and they just do code dumps. So yeah, that's another aspect to think about. Paul sometimes it's not just the actual framework itself but does FSO still depend on E17? Because that was one that had to be removed because of a series of issues that just wasn't being maintained effectively. So FSO is the middleware. So it's like a D-Bus API that controls the hardware. It doesn't have anything to do with the E17 or EFL or anything like that. But there are things that use it that also use EFL and E17, yeah. So E17 would be the UI layer and there are some things in that layer that interface with FSO to say turn on the wireless or whatever. It's that fragility that worries me. So E17 is also really busy upstream and is an important part of the Tizen stuff as I understand it. So it's not like these projects are dead. I mean they may not be well maintained or packaged in Debian but that's not because nobody's using them or nobody cares. So that's fixable basically. We can make this stuff work if anybody cares to make this stuff work. It seems to me to be the state. And if people aren't fixing bugs, well that's just the usual thing and release managers have to make decisions based on that. But I don't think, and yes, there's always a risk that upstream projects will die and disappear. Either we pick something and use it ourselves enough that it doesn't die or get other people to use it or we have to change our minds and change. There's nothing you can do about that fundamentally except try and make good choices. So we sit here and try and make good choices and we see what happens. One of the questions I was also asking myself is probably to have something mobile-ish in Debian, what we probably need is some sort of corporation that does the work in Debian first or at least bases its work on Debian. That's what MIGO did. It's just died in smoke but... My question is more what do we miss in Debian to make Debian an interesting platform for Debian mobile? I mean, we are probably convinced that it's a good platform for it but are we convincing people with money to pay developers to do that? And I don't know what's lacking. Open question. So the biggest problem I've had trying to do stuff is our fairly strict adherence to only supporting upstream kernels and the time it takes for Linaro or somebody in Samsung to make stuff work and then get their version working and then get it upstream to the kernel devs which takes months, especially if you're going through a massive reorganization of the whole ARM stack so nobody can do anything for like a year and a half and for that to come back down to Debian and that's two years later. So we as a random Debian dev going I want Debian installer to work on this device have to wait two years by which time you can't get that hardware anymore. So that kernel support cycle is a real impediment to doing anything in Debian. You can use our infrastructure but you've got to get your kernels from somewhere else and that's fine so long as the support for that in DI is easy to use and we tell people how to do it. But the problem is as soon as that works then you stop sending patches upstream for that because it's not your problem anymore and you don't care, you know you've got it booting so things take a long time and that's, everybody has this problem in different ways depending on exactly where they sit in the ecology of providers of hardware and providers of socks and kernel devs and distro people and it's a right pain in the arse. But that is a real practical impediment to getting work done. Just what's the freedom box people they've had exactly that problem as well. I don't know what the answers are. Linaro is trying to make that less broken but the problem is that it only really works for the devices that Linaro members care about which isn't necessarily the devices you can actually buy that we want to use because they're cheap. Is the packaging paradigm still sane in a mobile world? I mean, if you base your work on Debian but just change the kernel and still keep all the rest is the fact that we have packages that update or that we can update partly is still a good paradigm for mobile? So yeah, packages are great for all the reasons that packages are great and that hasn't changed. You can add software, you can take software away you don't end up with random crap on your device that you can't get rid of, that accidentally overwrites things. That's all marvelous. It's the process of upstreaming stuff. So the distro part of this is actually the problem not packaging per se. So I still think you want to use packaged kernels via flash kernel. You don't want to put random files on the device. So it may be for dev purposes but if you're giving it to anybody else it should come as a package installed with flash kernel which means you need flash kernel support and flash kernel needs to be less shit and which is all work underway but slowly usual sort of problems. So yeah, so again, we know what problems are requires quite a lot of work to fix and some of the stuff we can't do in the distro I think just because it is too slow, whatever happens. So we will have to be providing extra packages outside of Debian itself for some time. Well, unless we have a policy change within the project that we can package stuff that isn't upstream yet. For the kernel? Yeah, so the kernel people have been highly resistant to that for good reasons. It's a massive pain in the ass carrying massive huge patch trees. They don't want to get into that game and watching it in, you know, in Leonardo with the Samsung landing team and the TI landing team and the people who are trying to coordinate a bunch of distros and releases, you know, it's really complicated and lots of people who are very clever are spending a lot of time wrestling with this problem. We as Debian whoever it is that runs the kernel packages probably doesn't want to spend any more time than they already do on that. So they're, without lots more manpower they're just saying we're not having anything doesn't come from upstream because we can't cope and I think they're probably right but nothing stops us making extra kernel packages from other people's trees that work that people can install. So I think we can cope with that if people care enough. The problem is that as soon as you start doing that for 10 different devices it starts to get to be a really big deal. Well actually nothing in the policy prevents someone else to just package a new Linux kernel but it's just a huge amount of work. So there's some perspective on that from the OpenMoCode devices. Even the GTO 02 still doesn't have a full upstream kernel support for the whole of the device. The way that the Debian folks who are working on that have dealt with that is repository on alias with the kernels and all that sort of stuff. The problem is that you end up running really old kernels that Udev doesn't support and so they have had to be extra patches to allow that to work. And then there are new bugs introduced like I think 2629 is the most stable and then 2634 and 37 are the other two but they introduce issues with the micro SD card. Sometimes you can't boot, sometimes you can. So it's really horrible to be using old kernels and not having hardware support upstream. So just try and push upstream is absolutely the best thing to do. You just can't do anything else really. In parallel provide older kernels if possible but yeah. The questions, ideas, everybody's hungry. We still have 15 minutes so if you want to diverge to other parts of the mobile ecosystem then feel free. I don't know if you know but I will tell you. There's an interesting movement in Venezuela towards mobile devices. Venezuelan government might invest some quantity of money to develop some of the missing stuff to be a mobile, a Debian based mobile operating system. We're trying to make a Kanaima version that is installable on mobile devices. There's an interesting partnership between Venezuelan government and China government that includes some, I don't know. It is easy for us to get hardware from manufacturers like CTE and Huawei and that's only a comment so that you take an account. Yeah. Would it be possible for the Kanaima people to interact more on the Debian mobile list? Yeah, that would be because we now have the derivatives ecosystem that we know that the Kanaima is just one of the hundreds that we have but acting directly on the Debian mobile mailing list just to say this or this happened and opinions is just good to have more information. Yeah, I mean there's clearly I guess the Venezuelan and Chinese governments have some of the same concerns we do in that they'd prefer Google not to be in charge of everything they do as well. So there's a useful alignment. Are you targeting particular hardware? Have you already chosen a UI in the Middle West, a particular software stack? Do you already have a plan there? And if so, which one? Not actually, we're on the early stages. Actually, I'm here because of the same as you. But we don't want to, it's not that we don't want to, we prefer not shipping Android on the mobile devices. There's two major manufacturers in Venezuela. It's called Betelka and Orinokia. Then they have partnerships with these Chinese manufacturers I told you. But we're trying to do something that's Debian compatible, something that we just have to reuse our platform for Canaima and of course it's the easiest way because our developers are not trained in Android development. So that's the main reason why we would choose something Debian-based. You asked about, sorry, you asked something about devices. Yeah, we have some prototypes. Actually, I left my bag in the hack lab. Well, I can show you that later. I brought some prototypes. Actually, I was not the person that was going to be here, but anyway, I can show you the prototypes later. And we're experimenting on that, but only Android stuff, nothing Debian-based. And do you actually have people lined up to do work? Or is this just a kind of specking out thing? I think you could get something going here done right, which will be quite exciting. It would give a direction to this or what should we do? If you decide to do something, but that's probably a choice made and we'll all go, yeah, all right, that'll do. Anything that works because obviously you can focus on two or three of these rather than everybody trying 15 different things and none of them getting anywhere. So it's the usual question of people actually prepared to spend serious time and obviously a company that cares helps a lot just to people who are sat there all day working on things. I spent a few times yesterday with them talking about this and he also did a presentation on Kanaima, the derived distribution and they have like a community of developers, they're more than 50 and they are doing like parties and there is growing and growing in Venezuela. And a reply for the question you were asking before, they were like highly interested on HTML5 technologies and JavaScript UI-based systems for the stack, which then WebOS or Tyson might be aligned to this purpose and I think they are more interested also to learn about these technologies so they can spread the knowledge around the country and have more and more people contribute and. Maybe an interesting thing that Kanaima could do in collaboration with Debian or Debian Mobile for what it's worth is if we can concentrate on one or two devices that would be eight, that would, yeah devices that could be shipped around the world to various people, that could also help getting traction on this and as you said instead of just going with every Chinese tablet and hope it does something that in the end does not work. We were discussing about that but we didn't want to like make it official until we have like an approval and but this is something going on about that and then some hardware might be available for developers but it's still work in progress. Yeah, my only point is that it might be interesting for them to get in contact with various people not only in Venezuela to gain traction around this and I mean it's not only a matter of sending free devices to anyone, yeah. I guess another aspect, one of the problems with this is that the UI is quite closely tied to the hardware. How big is the TV? How many lights has it got on it? Where are the buttons? All that stuff needs to work nicely and which makes it difficult to work on the software independently of the hardware which of course is exactly what Debian wants to do and make things terribly general which is a bit like things that don't work very well and so insofar as we can pick a couple of devices and stick to them, freedom box people, you have to pick something to get anywhere but we have the additional problem that we're also trying to generalize everything. And the other which doesn't sit well with the new hardware every six months cycle of the crazy mobile phone people, yeah. Okay, we have five remaining minutes. Thank you very much from the Kanaima people for some more light, it's very interesting. Anyone wants to add something else? To the Gobi, I think we'll probably send the minutes to the Debian mobile or formatted things to the Debian mobile mailing list, but yeah. I suppose I should say that if people need anything from the Naro, come and hassle me about it. We won't probably give you what you want but in principle we exist to make stuff easier to do on ARM where stuff covers everything. Especially that problem of the kernel enablement across lots of different hardware. There is a lot of work going on so that it gets more like x86 world where you can have a kernel that works on quite a lot of devices and that will make our lives a lot easier when we finally get to that point and the standardized boot stuff. So we can expect life to improve in this area and I guess me and Steve McIntyre are the people in Debian to pester about stuff and we'll see what we can do. Thank you. If we don't have any other questions I just propose to close the session. Thank you everyone for attending and let's hope next year's buff will have a little more what we have done in Debian, more shiny. Thank you very much.