Last weekend I was in Southwest Harbour, Maine again for the annual LTSP hackfest (called By The Sea). It’s a fun and productive event and as always it’s been good catching up with LTSP folk, even though we were missing Oliver, Alkis and Vagrant.

Here is a summary of what I can recall from the discussions of the weekend…

Recent Happenings in LTSP

• New LTSP Website – After a really long time, LTSP finally has a new website. It’s a big improvement, there’s a new success stories page and the wiki is now self-hosted.
• LTSP PNP - This is  a new package (ltsp-pnp) that can safely be installed on existing machines to allow a user to log into an LTSP server using LDM.

Going Forward

Social

• On Friday, Chuck Liebow took us out for a boat ride around the harbour on the Sea Princess

• On Saturday night we had the big lobster dinner as per BTS tradition (I had steak since I’m not a big seafood person). We were to busy eating and telling stories to be taking any pictures
• And last but certainly not least, I finally met Eric Harrisson, who did a lot of work on K12-LTSP in the Portland schools district. He has an awesome hobby where he builds guitars out of… well, almost anything he can find.
  He brought along one of the experimental guitars he slapped together recently and told me all about how it’s put together. Even more amazing, he said I could have it! I was planning on getting an acoustic guitar anyway so I’m very thrilled about it. Not only is it a completely unique guitar but it sounds great too. I’m going to have to think of something to make back for him!

It was great seeing everyone again. I first started using LTSP around 9 years ago and never imagined back then that I’d get to meet the people behind it. Ron Colcernian sourced us some really cool LTSP tops that you can see us wearing in the group photo. I hope to get to BTS again next year!

A few months ago, I started trying out LXC (Linux Containers). Before that I used to use OpenVZ, which is an older and more mature contextualization implementation. I was pleased with how well LXC worked and started replacing my personal OpenVZ hosts with LXC.

It worked great, but it had a few quirks. While LXC itself works well, the user scripts that ship with it has some space for improvement. The lxc-list command lists anything that’s a directory in /var/lib/lxc, so if you have a lost+found directory, it will list it as a container (This has since been fixed upstream). Also, in some cases it would list containers twice or not at all. I was a bit annoyed with that, since OpenVZ’s “vzlist” tool prints out a nice table of your containers along with their IP addresses and other information. Since it’s very trivial to implement what I want in a shell script, I went ahead and did just that and called it RLXC.

I also missed the “vzctl exec <containername> command” to execute commands in containers and “vzctl enter <containername>” to gain a shell inside the container, so I added some more functionality to it so that I could configure ssh keys for these containers and use “rlxc enter” and “rlxc exec” like I used to do with the OpenVZ tools, but by using SSH.

I also realised that there are others too who wanted similar improvements in the LXC scripts and decided to continue improving RLXC and making it public.

Enter LLXC

I spoke to Stéphane about my ideas at the time and he introduced me to python3-lxc that he introduced on his blog yesterday. It provides Python bindings for liblxc, so I took the advantage of that and mostly re-implemented RLXC in Python and called it LLXC. The name doesn’t particularly mean anything, I’m open to suggestions for what to call it, if anyone cares.

Here are some screenshots that explains some of it better than I could do in words:

How to get it

As Stéphane mentioned in the python3-lxc blog entry, the API hasn’t yet been finalized and llxc itself is in an early state and many changes are planned, so it’s definitely not meant for production use yet, but since we believe in “release early, release often” in the free software community, here goes…

Currently, llxc.py itself is *very* Ubuntu specific and its only been tested on Ubuntu 12.04, but that will be fixed once more of its kinks have been ironed out. Some people are also working on getting python3-lxc on other distributions, which will help a lot.

The llxc.py script itself is hosted on Github: https://github.com/highvoltage/llxc

For python3-lxc and friends, you need to enable Stéphane’s experimental PPA: https://launchpad.net/~stgraber/+archive/experimental

You will then need to install the following packages: lxc, python3-lxc, python3-crypto, lvm, btrfs-tools

To generate the ssh keys used for ssh interaction between the containers, you need to run “llxc gensshkeys”.  The “enter” and “exec” commands also rely on your containers being in dns or in your /etc/hosts file, at least for now, which you may have to configure manually.

The Future

There is a lot that I’m planning to add, mostly to scratch my own itches. These include:

• Awareness of other hosts, so that the list command can show you all containers in the “awareness”. You’d also be able to clone, move, etc containers between hosts.
• Easily modify container configuration
• Hooks everywhere, and at least one hook for configuring a configuration management system such as salt, bcfg2, puppet or chef.
• More checks and tips everywhere. Is the host running low on memory? Disk space? Perhaps list available resources on variable hosts and make some suggestions based on that.
• There a not-very-descriptive ROADMAP file in the distribution, check that for more details.

I’ll have some packaging for this available soon and work on making more things work right out of the box, updates will follow. Also, feedback and patches are very welcome!

This afternoon I noticed that one of my machines didn’t have my default .bashrc loaded, which colourises (or ‘colorizes’ for Americans or ‘colourizes’ for Canadians) my shell so that I know on which machine I am so that I don’t accidentally do something silly like reboot the wrong host. One problem I’ve had with this is that there are limited colours available that makes sense to use for a shell prompt. Right as I was thinking this, I was looking at my Byobu screen sessions and thinking “Hmm! I like those logos, maybe I could use them in my shell!”.

So in just a few minutes I had a little script to help you configure those for your shell. Here is a screenshot of the shell logos in action. On my laptop I use a red background when I have a root shell:

This is what the shello script looks like that sets it up:

I might get bored by seeing it soon and get rid of it, but at least I had a little fun with it.

If you’d like to try it out, then you can get the script right here: https://github.com/highvoltage/shello

It doesn’t do anything like validating input yet, I’d also like to add something that creates some kind of a checksum of your hostname and choose a unicode character based on that. Maybe I’ll finish it up this weekend, or maybe I’ll have new things to write about!

When the Joy theme was picked as the chosen theme for Debian 7.0 (Wheezy), I wanted to do what I could to get as much of it in the archive as possible before the freeze that occurred in June. I’ve been working with Paul Tagliamonte and Vagrant Cascadian and I’m glad that it resulted in some nice things!

The Joy theme is modest and beautiful and I think Debian 7.0 is going to be one of the best looking Debian releases so far.

Joy Plymouth Theme

Plymouth is the part that provides the boot splash. It also takes care of a few other things, like showing prompts and progress indicators for filesystem checks, password prompts for encrypted devices and more so that the splash doesn’t need to exit to show those. It’s very scriptable, The installers for the Genesi Efika range of devices even use it for it’s front-end.

I needed to start with a Plymouth theme where I knew the prompts for all the things that happen during boot was at least more or less implemented, so I started off with one that I know works well, the Edubuntu one. So, fun fact: Debian 7.0′s Plymouth theme is actually based on the Edubuntu one.

I had to play with the colours a bit to get it right, Edubuntu has a light background so I had to invert contrast for things like the input box, but I think it came out nicely.

Splashy isn’t in the archives anymore and it’s not widely used anymore, so I cleaned it up from the desktop-base package so that there’s less clutter shipped with it.

Joy LTSP/LDM Theme

This screenshot actually looks a bit uglier than it should because I took it on a VM that doesn’t have 24bit colour, but we’re looking into what we can do to make it look better on 16bit colour as well.

During Debconf in Nigaragua, Vagrant and I worked on getting the LDM theme in shape. I have already done what I thought was most of the work by the time Debconf started, but it turns out there was a lot more to it to do it properly. We managed to get rid of the gtk2-engines-murrine dependency, which in itself is quite tiny, but it’s a bit backwards in that it depends on the whole rest of the murrine-themes which brings in too much. We took the time to get the dependencies/recommends/etc right and to make it the default theme in Debian without messing it up for any Debian derivatives. It all came together and now when you install LTSP on Debian, you get the Joy theme by default! I’m really glad about that because I didn’t get the Spacefun LDM theme done in time for the Squeeze release. Enjoy!

During the last Ubuntu Developer Summit, developer and contributor outreach was a topic that came up in a wide variety of sessions. In one of the sessions where we discussed the future of MOTU (the Ubuntu Masters of the Universe team), Evan Broder suggested that we try channels that might not necessarily be the usual geeky channels, like just taking $25 and buying some Facebook ads.

I’ve never bought any Facebook ads before and thought I’d give it a shot. I didn’t have time to prepare a nice campaign, or a nice landing page or anything fancy, but instead of putting it off until I can I decided to just run with it and see what happens.

I merely created an ad that said “Want to improve Ubuntu? Join the  Ubuntu Masters of the Universe team and help fix bug and upload packages!”. It linked back the the Ubuntu MOTU wiki page, which isn’t exactly glamorous, but it contains a lot of useful information on how to get involved.

Impressions and Clicks

Facebook lets you choose which targets you want to focus on. It even suggested a few, I mostly stuck with the defaults that it suggested and tweaked a little. This ended up being the targets:

This advert targets 129,520 users:

• who live in one of the countries: United States or United Kingdom
• who like ubuntu, linux or #OMG! Ubuntu!
• who speak English (UK) or English (US)
• who are in the category Science/Technology or the category Computer Programming

Did it work?

Well, did it get more people interested in contributing to Ubuntu? I have no idea. This experiment was mostly to see what $25 gets you in ads. Evan said he’s still up for contributing $25 for something like that, so perhaps we’ll do another round and make it more campaign like and more targeted. I’m actually somewhat dissapointed with the stats that Facebook provides. I was hoping for something more like Google Analytics where you could see where your visitors are from, which language they speak and which interest lead them to the ad. Maybe we’ll just try out Google ads next.

I actually think that it’s easy enough to target people via social networks like Google+. There are so many geeky people on there and from what I’ve seen, people are quite eager to share information that’s put together well and worth while sharing. It’s probably possible to put together a really good, effective campaign without even spending any money on it.

Any thoughts? Please share!

After wanting to attend Debconf for so long, things finally got real. No visa issues this time (Nicaragua is nice like that), tickets are booked… everything is ready! I’m excited to finally be able to attend one of these and meet some new Debian people and learn more about how Debian works.

• Arrival: Landing in Managua on 7 July,  13:20 local time
• Departure: Leaving from Managua on 14 July, 12:10 local time

See you there!

First off, congratulations to the Launchpad.net team for reaching bug #1000000. They’ve managed to build a huge platform that scales very well. Very few bug trackers live to that milestone and it’s amazing how they have managed to keep it snappy and also keep downtime so low by doing continuous roll-out.

1 000 000 x 67

A million bugs are a lot, but even more mind-blowing: for every bug filed in Launchpad.net, 67 iPads have been sold. Educational institutions everywhere are jumping on the iPad bandwagon, and in the Edubuntu project, we believe that the tools are quickly coming together that allows us to deliver a product that can be truly competitive with the iPad in educational environments.

We’re currently re-designing the Edubuntu website and will soon have a dedicated section to this project, but in the meantime, please join us on the edubuntu-devel mailing list and introduce yourself, or on the #edubuntu IRC channel on Freenode.

I’m glad you asked! At the Ubuntu Developer Summit, sessions are arranged by track. There are some topics that don’t have official tracks, but you end up seeing the same people in the same kind of sessions and it ends up being a track for all practical intents and purposes. One of these “meta-tracks” that emerged at this UDS was about software packages in Ubuntu. These were discussions related to how packages are organised in Ubuntu, how they’re maintained and synced with Debian, how to get upstream software developers excited about Ubuntu and more.

These were the sessions where I could walk in and be sure to find some combination of Stefano Rivera, Allison Randal, Asheesh Laroia, Evan Broder, Iain Lane, Andrew Starr-Bochiccio, Daniel Holbach, Andrew Mitchell, Micah Gersten, Bhavani Shankar and more in there

These sessions included:

• APT Improvements
• Upstream App Developer Documentation
• App Developer events
• software-center-q-client
• Backports BoF
• Continuing Packaging Guide Improvements
• Refine our SRU process to be more agile while avoiding too many pitfalls
• App Developer external outreach
• software-center-q-server
• Promote and encourage upstream delivery in Ubuntu
• Packaging requirements for Apps in Ubuntu
• LTS backport testing in 12.04
• Phased updates of software packages
• Merging / onto /usr
• Discussions of what should get uploaded to -proposed and when
• Review of the ARB process using MyApps
• Application Review Board
• Debian Health Check
• Developer Membership Board Discussion
• MOTU BOF Session
• Transition the archive to Java 7
• Finish the archive reorg
• Advertise new apps in the Software Center
• working session result of apt-improvements
• MyApps submission experience and expectations for upstreams
• Ubuntu App Developer Site incremental improvements
• Reaching out to future Ubuntu developers
• If a crash is already fixed by an update, prompt to install it

Archive Re-organisation

I’ll jump in with the big and controversial topic. When Ubuntu was founded, Canonical and the Ubuntu community was small and could only support a subset of the Debian archives. This supported subset became known as main. Initially it was less than 1GB large, the rest of what you’d usually find in the Debian main archive became known as Universe, and a group of people, named in jest after a he-man series, became known as the Masters of the Universe (MOTU) team.

Main was maintained mostly by Canonical staff and the universe archive was maintained by Canonical staff and community members. Over time, more and more community members started to maintain packages in main. Flavours such as Edubuntu, Kubuntu and Xubuntu were later allowed to install from universe and it was later enabled by default. In the initial LTS release, only main packages were supported long-term. These days, there are many packages in universe that are supported for the full 5 years on LTS releases. Previously, only packages in main had translations shipped for them. This is also no longer true. The lines between main and universe have become so blurred that having the separation no longer made any sense. Around the last LTS release (10.04), the topic of an archive re-organisation emerged. It was a big discussion, and when the Developer Membership Board was formed the MOTU Council was disbanded (which in my opinion was a bad idea) in part of that and also in anticipation for the archive re-organisation. Some people took that as meaning that MOTU is dead or that it would stop to exist. That is certainly not the case.

Unfortunately, the archive re-organisation became very complicated very quickly. There still needs to be a way for Canonical to identify packages that they officially support if someone wants to throw money at them for supporting it. We can’t have everything translated because the language packs would just grow too big. How would we deal with managing build-dependencies and make sure that people depend on high-quality tools and libraries? Soon after the initial archive re-organisation was started, it stalled. In my opinion this caused lots of confusion and did damage to the Ubuntu project.

Having said that, I’m glad to report that the discussion at this UDS was extremely positive and it seems like the archive re-organisation might actually be completed over the next two releases. Other benefits will include how support meta-data is stored. The tools that currently use the support fields (update-manager, ubuntu-support-status, software-center, etc) will now get the support metadata from an external file, which means that packages in Ubuntu wouldn’t need a diff with Debian’s packages anymore for support meta-data. Also, the archive layout will be simpler and easier to understand. MOTU would probably change from “Masters of the Universe” to “Masters of the Unseeded”. Packages that are seeded are packages that are provided on standard Ubuntu flavours (Ubuntu Core, Ubuntu Desktop, Ubuntu Server, Edubuntu, Kubuntu, Xubuntu, Lubuntu, etc). The rest of the archive that are unseeded would then still be maintained by a newly defined MOTU group.

It’s a big hairy issue and I’ve just touched on some of the areas, but what’s great is that progress is being made again and that people are serious about making it happen. Colin Watson has a work item to take the discussion further on the Ubuntu development mailing list. I’m positive that things will be moving forward on that front for this cycle, even if it ends up taking another cycle to iron out some of the smaller kinks.

Application Review Board

In a previous cycle, Canonical put together a process by which application developers could get their non-free, commercial applications in to the Software Center via authenticated PPA. It seemed unfair to have a process where non-free software could make it into the Ubuntu software center but free software couldn’t, so a process was formed to let apps in the software center via an extras repository. This process is overseen by the Application Review Board. I joined this board right about 6 months ago. We’ve had the usual problems that Ubuntu teams have (because, in reality the ARB is more of a team than a board, the name is a misnomer, I wish less Ubuntu teams had this issue), like lack of time, getting sporadically distracted by other work, but on top of that, we didn’t have our process quite smoothed out yet. The web interface that we used to manage apps had some huge issues (like making apps completely disappear from the interface when requesting feedback from the developer).

For the last weeks, quite a few people have worked hard to help fix the issues in the process and in the web app. There were *many* sessions at this UDS regarding upstream developers, the ARB, the MyApps web interface, etc. At times I thought that there were too many, but it was just right. A lot of issues were discussed, problems were solved, and while I felt like the ARB process was in an alpha stage during the last cycle, I think it’s more like a beta-state process now. I think we’re very close to having a process that’s smooth and easy for both the people that submit these apps, and the people who review them.

Currently the ARB has some backlog that we need to sort through, we’ll probably use that to help improve the process further and make Ubuntu a fun and welcoming platform to develop for.

We also absolutely want people to contribute their software to the right place. If a package belongs in Debian, Ubuntu, a PPA or any other archive instead, we’d like to advise the user properly. I took a work item to put together a flowchart to help people decide where to submit their app, because there’s way to many guides and howtos and someone could read the entire New Maintainers Guide and still won’t know where to submit their app

I know I’m a bit thin on the details on the sessions here, but I’ll do more blog posts on that. I just wanted to provide some background and explain that good progress is made, and that things are greatly improving with the ARB process. In the ARB, many of us are aspiring to becoming Debian Developers so that we can help sponsor packages there when it’s appropriate.

Debian Health Check

The Debian Health Check session as become a regular session at UDS. We had a bunch of DD’s in the room that could comment on the Debian-Ubuntu relationship, but we didn’t have someone who specifically represented Debian. Some of the issues I’ve mentioned previously (like the ARB) were discussed. Also the Ayatana patches from Ubuntu that are hard to get into Debian (which includes Unity).

What is nice is that we have quite a few people who started out with Ubuntu that became Debian Developers. The relationship between Debian and Ubuntu seems quite healthy and it seems that both projects gain great benefit from each other.

MOTU Birds of a Feather

The archive-reorg was discussed, and MOTUs future role was discussed in anticipation of it. There was some discussion about things that have worked well in the last few cycles that should be revitalised. MOTU needs some more announcements of what it’s doing to cause some buzz around its activities. Too few people know what MOTU does and how it does it. Evan Broder and I plan to try some experiments with Facebook ads to see what kind of people/interest they bring in MOTU

The MOTU team is also very eager to get long-term ARB apps into the archive. Having apps in universe would mean less work and restrictions than having them in extras.

As MOTU we’re very committed to it and its goals, but there needs to be some restructuring/updating of the current documentation. It might also need a new vision/mission-statement, etc. This cycle is going to be a revitalisation cycle for MOTU in whatever form it will continue to exist. We hope that many people will get excited about packaging and quality in the Ubuntu archive and help contribute to that

Getting it all down is impossible

I wish I could do a better job at this blog post, but I’m still somewhat suffering from information overload from last week, and if I try to get it perfect and get everything in there then this post will never get finished. If you have questions, feel free to give a poke on #ubuntu-motu on freenode, there’s bound to be someone who could answer questions on any of these topics if you’re willing to hang around a bit. I still haven’t even touched on Backports, APT improvements, SRU streamlining, etc, but you should be able to find most of the information from those sessions in their blueprints. If you’ve made it this far, thanks for reading!

Today at the Ubuntu Developer Summit we had a session to plan out the next release of Edubuntu.

For the Edubuntu 12.10 core product, we’re doing some typical Edubuntu updates and features, which include:

• Authentication step in the installer for AD/Samba4/LDAP
• We’ll be reviewing the installed apps, add gnote, refresh the kde-edu apps selection
• Dynamic installer slideshow, based on options selected
• Juju charms for educational web apps (Moodle, WordPress Multisite, etc)
• Remote Live Installer (booting an Edubuntu/Ubuntu livecd over the network
• Education-specific software highlights in Software Center
• Speed-up installation by optimising the way we ship language packs
• A variety of Desktop/Artwork tweaks and fixes

Edubuntu Labs: Get Excited and Make Things

On Tuesday I had 2.5 minutes to speak about Edubuntu during a plenary session where I presented some of our more ambitious plans in Edubuntu. We want to make it easier for people to work on their ideas and projects that might be good for Edubuntu, but that doesn’t necessarilly fit into our main product yet or in a 6 month release cycle. For that, we’re starting Edubuntu Labs (subject to namechange). A playground for experimental and exciting features that might one day make it as a supported Edubuntu product. Internally, we’re starting two of these projects to kick it off.

1. Edubuntu Server

Edubuntu Server is a product we discontinued a few years back. Due to popular demand, we’re considering reviving it as a product. Aspects we’re currently investigating:

• Zentyal Small Business Server
• A built-in disk-cloning tool using LTSP
• A remote installer for Ubuntu based installer media
• Schooltool
• Schooltool integration into Zentyal
• Samba4

2. Edubuntu Tablet

All of this is still early work, but I wanted to get it out there as early as possible. Over the next 2 weeks there’ll be more official announcements on the Edubuntu website. We’re looking for more contributors to help us out with this, please join us on #edubuntu and add it to your autojoin and introduce yourself on the edubuntu-devel mailing list