April 23, 2014

A simple, easy, fast and useful app! Change the color of your folders in Nautilus in a really easy way, so that you can get a better visual layout!

Folder Color in Ubuntu

How to install? Just enter this command into a Terminal, logout and enjoy it!
sudo add-apt-repository ppa:costales/folder-color ; sudo apt-get update ; sudo apt-get install folder-color -y

More info.
on April 23, 2014 05:29 PM

U talking to me?

Mark Shuttleworth

This upstirring undertaking Ubuntu is, as my colleague MPT explains, performance art. Not only must it be art, it must also perform, and that on a deadline. So many thanks and much credit to the teams and individuals who made our most recent release, the Trusty Tahr, into the gem of 14.04 LTS. And after the uproarious ululation and post-release respite, it’s time to open the floodgates to umpteen pent-up changes and begin shaping our next show.

The discipline of an LTS constrains our creativity – our users appreciate the results of a focused effort on performance and stability and maintainability, and we appreciate the spring cleaning that comes with a focus on technical debt. But the point of spring cleaning is to make room for fresh ideas and new art, and our next release has to raise the roof in that regard. And what a spectacular time to be unleashing creativity in Ubuntu. We have the foundations of convergence so beautifully demonstrated by our core apps teams – with examples that shine on phone and tablet and PC. And we have equally interesting innovation landed in the foundational LXC 1.0, the fastest, lightest virtual machines on the planet, born and raised on Ubuntu. With an LTS hot off the press, now is the time to refresh the foundations of the next generation of Linux: faster, smaller, better scaled and better maintained. We’re in a unique position to bring useful change to the ubiquitary Ubuntu developer, that hardy and precise pioneer of frontiers new and potent.

That future Ubuntu developer wants to deliver app updates instantly to users everywhere; we can make that possible. They want to deploy distributed brilliance instantly on all the clouds and all the hardware. We’ll make that possible. They want PAAS and SAAS and an Internet of Things that Don’t Bite, let’s make that possible. If free software is to fulfil it’s true promise it needs to be useful for people putting precious parts into production, and we’ll stand by our commitment that Ubuntu be the most useful platform for free software developers who carry the responsibilities of Dev and Ops.

It’s a good time to shine a light on umbrageous if understandably imminent undulations in the landscape we love – time to bring systemd to the centre of Ubuntu, time to untwist ourselves from Python 2.x and time to walk a little uphill and, thereby, upstream. Time to purge the ugsome and prune the unusable. We’ve all got our ucky code, and now’s a good time to stand united in favour of the useful over the uncolike and the utile over the uncous. It’s not a time to become unhinged or ultrafidian, just a time for careful review and consideration of business as usual.

So bring your upstanding best to the table – or the forum – or the mailing list – and let’s make something amazing. Something unified and upright, something about which we can be universally proud. And since we’re getting that once-every-two-years chance to make fresh starts and dream unconstrained dreams about what the future should look like, we may as well go all out and give it a dreamlike name. Let’s get going on the utopic unicorn. Give it stick. See you at vUDS.

on April 23, 2014 05:16 PM

On the last UDS we talked about migrating from upstart to systemd to boot Ubuntu, after Mark announced that Ubuntu will follow Debian in that regard. There’s a lot of work to do, but it parallelizes well once developers can run systemd on their workstations or in VMs easily and the system boots up enough to still be able to work with it.

So today I merged our systemd package with Debian again, dropped the systemd-services split (which wasn’t accepted by Debian and will be unnecessary now), and put it into my systemd PPA. Quite surprisingly, this booted a fresh 14.04 VM pretty much right away (of course there’s no Plymouth prettiness). The main two things which were missing were NetworkManager and lightdm, as these don’t have an init.d script at all (NM) or it isn’t enabled (lightdm). Thus the PPA also contains updated packages for these two which provide a proper systemd unit. With that, the desktop is pretty much fully working, except for some details like cron not running. I didn’t go through /etc/init/*.conf with a small comb yet to check which upstart jobs need to be ported, that’s now part of the TODO list.

So, if you want to help with that, or just test and tell us what’s wrong, take the plunge. In a 14.04 VM (or real machine if you feel adventurous), do

  sudo add-apt-repository ppa:pitti/systemd
  sudo apt-get update
  sudo apt-get dist-upgrade

This will replace systemd-services with systemd, update network-manager and lightdm, and a few libraries. Up to now, when you reboot you’ll still get good old upstart. To actually boot with systemd, press Shift during boot to get the grub menu, edit the Ubuntu stanza, and append this to the linux line: init=/lib/systemd/systemd.

For the record, if pressing shift doesn’t work for you (too fast, VM, or similar), enable the grub menu with

  sudo sed -i '/GRUB_HIDDEN_TIMEOUT/ s/^/#/' /etc/default/grub
  sudo update-grub

Once you are satisfied that your system boots well enough, you can make this permanent by adding the init= option to /etc/default/grub (and possibly remove the comment sign from the GRUB_HIDDEN_TIMEOUT lines) and run sudo update-grub again. To go back to upstart, just edit the file again, remove the init=sudo update-grub again.

I’ll be on the Debian systemd/GNOME sprint next weekend, so I feel reasonably well prepared now. :-)

Update: As the comments pointed out, this bricked /etc/resolv.conf. I now uploaded a resolvconf package to the PPA which provides the missing unit (counterpart to the /etc/init/resolvconf.conf upstart job) and this now works fine. If you are in that situation, please boot with upstart, and do the following to clean up:

  sudo rm /etc/resolv.conf
  sudo ln -s ../run/resolvconf/resolv.conf /etc/resolv.conf

Then you can boot back to systemd.

on April 23, 2014 02:10 PM

vBlog Teaser

Svetlana Belkin

I’m thinking of doing a vBlog about Ubuntu and other things:


on April 23, 2014 01:54 PM

Juju sos is my entryway into Go code and the juju internals. This plugin will execute and pull sosreports from all machines known to juju or a specific machine of your choice and copy them locally on your machine.

An example of what this plugin does, first, some output of juju status to give you an idea of the machines I have:

┌[poe@cloudymeatballs] [/dev/pts/1] 
└[~]> juju status
environment: local
machines:
  "0":
    agent-state: started
    agent-version: 1.18.1.1
    dns-name: localhost
    instance-id: localhost
    series: trusty
  "1":
    agent-state: started
    agent-version: 1.18.1.1
    dns-name: 10.0.3.27
    instance-id: poe-local-machine-1
    series: trusty
    hardware: arch=amd64 cpu-cores=1 mem=2048M root-disk=8192M
  "2":
    agent-state: started
    agent-version: 1.18.1.1
    dns-name: 10.0.3.19
    instance-id: poe-local-machine-2
    series: trusty
    hardware: arch=amd64 cpu-cores=1 mem=2048M root-disk=8192M
services:
  keystone:
    charm: cs:trusty/keystone-2
    exposed: false
    relations:
      cluster:
      - keystone
      identity-service:
      - openstack-dashboard
    units:
      keystone/0:
        agent-state: started
        agent-version: 1.18.1.1
        machine: "2"
        public-address: 10.0.3.19
  openstack-dashboard:
    charm: cs:trusty/openstack-dashboard-0
    exposed: false
    relations:
      cluster:
      - openstack-dashboard
      identity-service:
      - keystone
    units:
      openstack-dashboard/0:
        agent-state: started
        agent-version: 1.18.1.1
        machine: "1"
        open-ports:
        - 80/tcp
        - 443/tcp
        public-address: 10.0.3.27

Basically what we are looking at is 2 machines that are running various services on them in my case Openstack Horizon and Keystone. Now suppose I have some issues with my juju machines and openstack and I need a quick way to gather a bunch of data on those machines and send them to someone who can help. With my juju-sos plugin, I can quickly gather sosreports on each of the machines I care about in as little typing as possible.

Here is the output from juju sos querying all machines known to juju:

┌[poe@cloudymeatballs] [/dev/pts/1] 
└[~]> juju sos -d ~/scratch
2014-04-23 05:30:47 INFO juju.provider.local environprovider.go:40 opening environment "local"
2014-04-23 05:30:47 INFO juju.state open.go:81 opening state, mongo addresses: ["10.0.3.1:37017"]; entity ""
2014-04-23 05:30:47 INFO juju.state open.go:133 dialled mongo successfully
2014-04-23 05:30:47 INFO juju.sos.cmd cmd.go:53 Querying all machines
2014-04-23 05:30:47 INFO juju.sos.cmd cmd.go:59 Adding machine(1)
2014-04-23 05:30:47 INFO juju.sos.cmd cmd.go:59 Adding machine(2)
2014-04-23 05:30:47 INFO juju.sos.cmd cmd.go:88 Capturing sosreport for machine 1
2014-04-23 05:30:55 INFO juju.sos main.go:119 Copying archive to "/home/poe/scratch"
2014-04-23 05:30:56 INFO juju.sos.cmd cmd.go:88 Capturing sosreport for machine 2
2014-04-23 05:31:08 INFO juju.sos main.go:119 Copying archive to "/home/poe/scratch"
┌[poe@cloudymeatballs] [/dev/pts/1] 
└[~]> ls $HOME/scratch
sosreport-ubuntu-20140423040507.tar.xz  sosreport-ubuntu-20140423052125.tar.xz  sosreport-ubuntu-20140423052545.tar.xz
sosreport-ubuntu-20140423050401.tar.xz  sosreport-ubuntu-20140423052223.tar.xz  sosreport-ubuntu-20140423052600.tar.xz
sosreport-ubuntu-20140423050727.tar.xz  sosreport-ubuntu-20140423052330.tar.xz  sosreport-ubuntu-20140423052610.tar.xz
sosreport-ubuntu-20140423051436.tar.xz  sosreport-ubuntu-20140423052348.tar.xz  sosreport-ubuntu-20140423053052.tar.xz
sosreport-ubuntu-20140423051635.tar.xz  sosreport-ubuntu-20140423052450.tar.xz  sosreport-ubuntu-20140423053101.tar.xz
sosreport-ubuntu-20140423052006.tar.xz  sosreport-ubuntu-20140423052532.tar.xz

Another example of juju sos just capturing a sosreport from one machine:

┌[poe@cloudymeatballs] [/dev/pts/1] 
└[~]> juju sos -d ~/scratch -m 2
2014-04-23 05:41:59 INFO juju.provider.local environprovider.go:40 opening environment "local"
2014-04-23 05:42:00 INFO juju.state open.go:81 opening state, mongo addresses: ["10.0.3.1:37017"]; entity ""
2014-04-23 05:42:00 INFO juju.state open.go:133 dialled mongo successfully
2014-04-23 05:42:00 INFO juju.sos.cmd cmd.go:70 Querying one machine(2)
2014-04-23 05:42:00 INFO juju.sos.cmd cmd.go:88 Capturing sosreport for machine 2
2014-04-23 05:42:08 INFO juju.sos main.go:99 Copying archive to "/home/poe/scratch"

Fancy, fancy :)

Of course this is a work in progress and I have a few ideas of what else to add here, some of those being:

  • Rename the sosreports to match the dns-name of the juju machine
  • Filter sosreport captures based on services
  • Optionally pass arguments to sosreport command in order to filter out specific plugins I want to run, ie

    $ juju sos -d ~/sosreport -- -b -o juju,maas,nova-compute

As usual contributions are welcomed and some installation instructions are located in the readme

on April 23, 2014 05:52 AM
After working with my ambilight clone for a few days, I discovered the biggest annoyance was that it wouldn't turn off after turning off the TV.  I had some ideas on how I could remotely trigger it from the phone or from an external HTPC but I really wanted a self contained solution in case I decided to swap the HTPC for a FireTV or a Chromecast.

This brought me to trying to do it directly via my remote.  My HTPC uses a mceusb, so I was tempted to just get another mceusb for the pi.  This would have been overkill though, the pi has tons of unused GPIO's, it can be done far simpler (and cheaper).

I looked into it and discovered that someone actually already wrote a kernel module that directly controls an IR sensor on a GPIO.  The kernel module is based off the existing lirc_serial module, but adapted specifically for the raspberry pi.  (See http://aron.ws/projects/lirc_rpi/ for more information)

Hardware

All that's necessary is a 38 kHz IR sensor.  You'll spend under $5 on one of them on Amazon (plus some shipping) or you can get one from radio shack if you want something quick and local.  I spent $4.87 on one at my local radio shack.

The sensor is really simple, 3 pins.  All 3 pins are available in the pi's header.  One goes to 3.3V rail, one to ground, and one to a spare GPIO.  There's a few places on the header that you can use for each.  Just make sure you match up the pinout to the sensor you get.  I chose to use GPIO 22 as it's most convenient for my lego case.  The lirc_rpi defaults to GPIO 18.

Some notes to keep in mind:

  1. While soldering it, be cognizant of which way you want the sensor to face so that it can be accessed from the remote.  
  2. Remember that you are connecting to 3.3V and Ground from the Pi header.  The ground connection won't be the same as your rail that was used to power the pi if you are powering via USB.  
  3. The GPIO pins are not rated for 5V, so be sure to connect to the 3.3V.



Software


LIRC is available directly in the raspbian repositories.  Install it like this:

# sudo apt-get install lirc

Manually load the module so that you can test it.

# sudo modprobe lirc_rpi gpio_in_pin=22

Now use mode2 to test that it's working.  Once you run the command, press some buttons on your remote.  You should be output about space, pulse and other stuff.  Once you're satisfied, press ctrl-c to exit.

# mode2 -d /dev/lirc0

Now, add the modules that need to be loaded to /etc/modules.  If you are using a different GPIO than 18, specify it here again.  This will make sure that lirc_rpi loads on boot.

/etc/modules

lirc_dev
lirc_rpi gpio_in_pin=22


Now modify /etc/lirc/hardware.conf to match this configuration to make it work for the rpi:

/etc/lirc/hardware.conf

# /etc/lirc/hardware.conf
#
# Arguments which will be used when launching lircd
LIRCD_ARGS="--uinput"

#Don't start lircmd even if there seems to be a good config file
#START_LIRCMD=false

#Don't start irexec, even if a good config file seems to exist.
#START_IREXEC=false

#Try to load appropriate kernel modules
LOAD_MODULES=true

# Run "lircd --driver=help" for a list of supported drivers.
DRIVER="default"
# usually /dev/lirc0 is the correct setting for systems using udev 
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"

# Default configuration files for your hardware if any
LIRCD_CONF=""
LIRCMD_CONF=""

Next, we'll record the buttons that you want the pi to trigger the backlight toggle on.  I chose to do it on the event of turning the TV on or off.  For me I actually have a harmony remote that has separate events for "Power On" and "Power Off" available.  So I chose to program KEY_POWER and KEY_POWER2.  If you don't have the codes available for both "Power On" and "Power Off" then you can just program "Power Toggle" to KEY_POWER.

# irrecord -d /dev/lirc0 ~/lircd.conf

Once you have the lircd.conf recorded, move it into /etc/lirc to overwrite /etc/lirc/lircd.conf and start lirc

# sudo mv /home/pi/lircd.conf /etc/lirc/lircd.conf
# sudo /etc/init.d/lirc start

With lirc running you can examine that it's properly recognizing your key event using the irw command.  Once irw is running, press the button on the remote and make sure your pi recognizes it.  Once you're done press ctrl-c to exit.

# irw

Now that you've validated the pi can recognize the command, it's time to tie it to an actual script.  Create /home/pi/.lircrc with contents like this:

/home/pi/.lircrc

begin
     button = KEY_POWER
     prog = irexec
     repeat = 0
     config = /home/pi/toggle_backlight.sh off
end

begin
     button = KEY_POWER2
     prog = irexec
     repeat = 0
     config = /home/pi/toggle_backlight.sh on
end

My toggle_backlight.sh looks like this:

/home/pi/toggle_backlight.sh

#!/bin/sh
ARG=toggle
if [ -n "$1" ]; then
ARG=$1
fi
RUNNING=$(pgrep hyperion-v4l2)
if [ -n "$RUNNING" ]; then
if [ "$ARG" = "on" ]; then
exit 0
fi
pkill hyperion-v4l2
hyperion-remote --color black
exit 0
fi
if [ "$ARG" = "off" ]; then
hyperion-remote --color black
exit 0
fi
#spawn hyperion remote before actually clearing channels to prevent extra flickers
hyperion-v4l2 --crop-height 30 --crop-width 10 --size-decimator 8 --frame-decimator 2 --skip-reply --signal-threshold 0.08&
hyperion-remote --clearall


To test, run irexec and then press your remote button.  With any luck irexec will launch the toggle script and change your LED status.

# irexec

Lastly, you need to add irexec to your /etc/rc.local to make it boot with the pi.  Make sure you put the execution before the exit 0

/etc/rc.local

su pi -c "irexec -d"
su pi -c "/home/pi/toggle_backlight.sh off"

Reboot your pi, and make sure everything works together.  

# sudo reboot


on April 23, 2014 05:48 AM

I just completed upgrading four computers to Ubuntu 14.04 tonight. My testing machine has been running 14.04 since early alpha phase, but in the last two days I upgrade by work Lenovo W520, my person Lenovo T530 and the self-assembled desktop with a core2duo and Nvidia 8800 GTS that I haded down to my son.

Confidence In Ubuntu
On Friday of this week I will be involved in delivering training to a group of Boy Scout leaders at a Wood Badge course. I will utilize my primary laptop, the T530, to give a presentation and produce the Gilwell Gazette. I completed a great deal of prep work on Ubuntu 13.10 and if I did not have complete confidence in Ubuntu 14.04 I would have waited until after the weekend to upgrade. I needed to be confident that the multi-monitor functionality would work, that documents produced in an earlier version of Libre Office would not suddenly change the page layouts. In short, I was depending on Ubuntu being dependable and solid more than I usually do.

Subtle Changes Add Flexibility and Polish
Ubuntu added some very small tweaks that truly add to the overall user experience. The borderless windows, new lock screen, and smaller minimum size of launcher icons all add up to slight, but pleasant changes.

Here is a screen shot of the 14.04 desktop on the Lenovo T530.

14.04 desktop

14.04 desktop


on April 23, 2014 03:10 AM




This article is cross-posted on Docker's blog as well.

There is a design pattern, occasionally found in nature, when some of the most elegant and impressive solutions often seem so intuitive, in retrospect.



For me, Docker is just that sort of game changing, hyper-innovative technology, that, at its core,  somehow seems straightforward, beautiful, and obvious.



Linux containers, repositories of popular base images, snapshots using modern copy-on-write filesystem features.  Brilliant, yet so simple.  Docker.io for the win!


I clearly recall nine long months ago, intrigued by a fervor of HackerNews excitement pulsing around a nascent Docker technology.  I followed a set of instructions on a very well designed and tastefully manicured web page, in order to launch my first Docker container.  Something like: start with Ubuntu 13.04, downgrade the kernel, reboot, add an out-of-band package repository, install an oddly named package, import some images, perhaps debug or ignore some errors, and then launch.  In few moments, I could clearly see the beginnings of a brave new world of lightning fast, cleanly managed, incrementally saved, highly dense, operating system containers.

Ubuntu inside of Ubuntu, Inception style.  So.  Much.  Potential.



Fast forward to today -- April 18, 2014 -- and the combination of Docker and Ubuntu 14.04 LTS has raised the bar, introducing a new echelon of usability and convenience, and coupled with the trust and track record of enterprise grade Long Term Support from Canonical and the Ubuntu community.
Big thanks, by the way, to Paul Tagliamonte, upstream Debian packager of Docker.io, as well as all of the early testers and users of Docker during the Ubuntu development cycle.
Docker is now officially in Ubuntu.  That makes Ubuntu 14.04 LTS the first enterprise grade Linux distribution to ship with Docker natively packaged, continuously tested, and instantly installable.  Millions of Ubuntu servers are now never more than three commands away from launching or managing Linux container sandboxes, thanks to Docker.


sudo apt-get install docker.io
sudo docker.io pull ubuntu
sudo docker.io run -i -t ubuntu /bin/bash


And after that last command, Ubuntu is now running within Docker, inside of a Linux container.

Brilliant.

Simple.

Elegant.

User friendly.

Just the way we've been doing things in Ubuntu for nearly a decade. Thanks to our friends at Docker.io!


Cheers,
:-Dustin
on April 23, 2014 01:12 AM

April 22, 2014

One of the less exciting points in the day of a Debian Developer is the moment they realize they have to create a repackaged upstream source tarball.

This is often a process that they have to repeat on each new upstream release too.

Wouldn't it be useful to:

  • Scan all the existing repackaged upstream source tarballs and diff them against the real tarballs to catalog the things that have to be removed and spot patterns?
  • Operate a system that automatically produces repackaged upstream source tarballs for all tags in the upstream source repository or all new tarballs in the upstream download directory? Then the DD can take any of them and package them when he wants to with less manual effort.
  • Apply any insights from this process to detect non-free content in the rest of the Debian archive and when somebody is early in the process of evaluating a new upstream project?

Google Summer of Code is back

One of the Google Summer of Code projects this year involves recursively building Java projects from their source. Some parts of the project, such as repackaged upstream tarballs, can be generalized for things other than Java. Web projects including minified JavaScript are a common example.

Andrew Schurman, based near Vancouver, is the student selected for this project. Over the next couple of weeks, I'll be starting to discuss the ideas in more depth with him. I keep on stumbling on situations where repackaged upstream tarballs are necessary and so I'm hoping that this is one area the community will be keen to collaborate on.

on April 22, 2014 08:34 PM

Favourite Twitter Post

Jonathan Riddell

KDE Project:

There's only 1 tool to deal with an unsupported Windows XP...

on April 22, 2014 12:11 PM

Recently my friend Joël Franusic was stressing out about sending postcards to his Kickstarter backers and asked me to help him out. He pointed me to the excellent service Lob.com, which is a very developer-friendly API around printing and mailing. We quickly had some code up and running that could take a CSV export of Kickstarter campaign backers, verify addresses, and trigger the sending of customizable, actual physical postcards to the backers.

Screen Shot 2014-04-14 at 2.24.30 PM

We wanted to share the project such that it could help out other Kickstarter campaigns, so we put it on Github: https://github.com/mrooney/kickstarter-lob.

Below I explain how to install and use this script to use Lob to send postcards to your Kickstarter backers. The section after that explains how the script works in detail.

Using the script to mail postcards to your backers

First, you’ll need to sign up for a free account at Lob.com, then grab your “Test API Key” from the “Account Details” section of your account page. At this point you can use your sandbox API key to test away free of charge and view images of any resulting postcards. Once you are happy with everything, you can plug in credit card details and start using your “Live” API key. Second, you’ll need an export from Kickstarter for the backers you wish to send postcards to.

Now you’ll want to grab the kickstarter-lob code and get it set.

These instructions assume that you’re using a POSIX compatible operating system like Mac OS X or Linux. If you’re using Mac OS X, open the “Terminal” program and type the commands below into it to get started:

git clone https://github.com/mrooney/kickstarter-lob.git
cd kickstarter-lob
sudo easy_install pip # (if you don’t have pip installed already)
pip install -r requirements.txt
cp config_example.json config.json
open config.json

At this point, you should have a text editor open with the configuration information. Plug in the correct details, making sure to maintain quotes around the values. You’ll need to provide a few things besides an API key:

  • A URL of an image or PDF to be used for the front of the postcard.
    This means that you need to have your PDF available online somewhere. I suggest using Amazon’s S3 service to host your PDF.

  • A message to be printed on the back of the postcard (the address of the receiver will automatically show up here as well).

  • Your return address.

Now you are ready to give it a whirl. Run it like so. Make sure you include the filename for your Kickstarter export:

$ python kslob.py ~/Downloads/your-kickstarter-backer-report.csv
Fetching list of any postcards already sent...
Verifying addresses of backers...
warning: address verification failed for jsmith@example.com, cannot send to this backer.
Already sent postcards to 0 of 161 backers
Send to 160 unsent backers now? [y/N]: y
Postcard sent to Jeff Bezos! (psc_45df20c2ade155a9)
Postcard sent to Tim Cook! (psc_dcbf89cd1e46c488)
...
Successfully sent to 160 backers with 0 failures

The script will verify all addresses, and importantly, only send to addresses not already sent to. The script queries Lob to keep track of who you’ve already sent a postcard to; this important feature allows you to download new Kickstarter exports as people fill in or update their addresses. After downloading a new export from Kickstarter, just run the script against the new export, and the script will only send postcards to the new addresses.

Before anything actually happens, you’ll notice that you’re informed of how many addresses have not yet received postcards and prompted to send them or not, so you can feel assured it is sending only as many postcards as you expect.

If you were to run it again immediately, you’d see something like this:

$ python kslob.py ~/Downloads/your-kickstarter-backer-report.csv
 Fetching list of any postcards already sent...
 Verifying addresses of backers...
 warning: address verification failed for jsmith@example.com, cannot send to this backer.
 Already sent postcards to 160 of 161 backers
 SUCCESS: All backers with verified addresses have been processed, you're done!

After previewing your sandbox postcards on Lob’s website, you can plug in your live API key in the config.json file and send real postcards at reasonable rates.

How the script works

This section explains how the script actually works. If all you wanted to do is send postcards to your Kickstarter backers, then you can stop reading now. Otherwise, read on!

Before you get started, take a quick look at the “kslob.py” file on GitHub: https://github.com/mrooney/kickstarter-lob/blob/master/kslob.py

We start by importing four Python libraries: “csv”, “json”, “lob”, and “sys”. Of those four libraries, “lob” is the only one that isn’t part of Python’s standard library. The “lob” library is installed by using the “pip install -r requirements.txt” command I suggest using above. You can also install “lob-python” using pip or easy_install.

#!/usr/bin/env python
import csv
import json
import lob
import sys

Next we define one class named “ParseKickstarterAddresses” and two functions “addr_identifier” and “kickstarter_dict_to_lob_dict”

“ParseKickstarterAddresses” is the code that reads in the backer report from Kickstarter and turns it into an array of Python dictionaries.

class ParseKickstarterAddresses:
   def __init__(self, filename):
       self.items = []
       with open(filename, 'r') as csvfile:
           reader = csv.DictReader(csvfile)
           for row in reader:
               self.items.append(row)

The “addr_identifier” function takes an address and turns it into a unique identifier, allowing us to avoid sending duplicate postcards to backers.

def addr_identifier(addr):
   return u"{name}|{address_line1}|{address_line2}|{address_city}|{address_state}|{address_zip}|{address_country}".format(**addr).upper()

The “kickstarter_dict_to_lob_dict” function takes a Python dictionary and turns it into a dictionary we can give to Lob as an argument.

def kickstarter_dict_to_lob_dict(dictionary):
   ks_to_lob = {'Shipping Name': 'name',
                'Shipping Address 1': 'address_line1',
                'Shipping Address 2': 'address_line2',
                'Shipping City': 'address_city',
                'Shipping State': 'address_state',
                'Shipping Postal Code': 'address_zip',
                'Shipping Country': 'address_country'}
   address_dict = {}
   for key in ks_to_lob.keys():
       address_dict[ks_to_lob[key]] = dictionary[key]
   return address_dict

The “main” function is where the majority of the logic for our script resides. Let’s cover that in more detail.

We start by reading in the name of the Kickstarter backer export file. Loading our configuration file (“config.json”) and then configuring Lob with the Lob API key from the configuration file:

def main():
   filename = sys.argv[1]
   config = json.load(open("config.json"))
   lob.api_key = config['api_key']

Next we query Lob for the list of postcards that have already been sent. You’ll notice that the “processed_addrs” variable is a Python “set”, if you haven’t used a set in Python before, a set is sort of like an array that doesn’t allow duplicates. We only fetch 100 results from Lob at a time, and use a “while” loop to make sure that we get all of the results.

print("Fetching list of any postcards already sent...")
processed_addrs = set()
postcards = []
postcards_result = lob.Postcard.list(count=100)
while len(postcards_result):
    postcards.extend(postcards_result)
    postcards_result = lob.Postcard.list(count=100, offset=len(postcards))

One we fetch all of the postcards, we print out how many were found:

print("...found {} previously sent postcards.".format(len(postcards)))

Then we iterate through all of our results and add them to the “processed_addrs” set. Note the use of the “addr_identifier” function, which turns each address dictionary into a string that uniquely identifies that address.

for processed in postcards:
    identifier = addr_identifier(processed.to.to_dict())
    processed_addrs.add(identifier)

Next we set up a bunch of variables that will be used later on, variables with configuration information for the postcards that Lob will send, the addresses from the Kickstarter backers export file, and variables to keep track of who we’ve sent postcards to and who we still need to send postcards to.

postcard_from_address = config['postcard_from_address']
postcard_message = config['postcard_message']
postcard_front = config['postcard_front']
postcard_name = config['postcard_name']
addresses = ParseKickstarterAddresses(filename)
to_send = []
already_sent = []

At this point, we’re ready to start validating addresses, the code below loops over every line in the Kickstarter backers export file and uses Lob to see if the address is valid.

print("Verifying addresses of backers...")
for line in addresses.items:
    to_person = line['Shipping Name']
    to_address = kickstarter_dict_to_lob_dict(line)
    try:
        to_name = to_address['name']
        to_address = lob.AddressVerify.verify(**to_address).to_dict()['address']
        to_address['name'] = to_name
    except lob.exceptions.LobError:
        msg = 'warning: address verification failed for {}, cannot send to this backer.'
        print(msg.format(line['Email']))
        continue

If the address is indeed valid, we check to see if we’ve already sent a postcard to that address. If so, the address is added to the list of addresses we’ve “already_sent” postcards to. Otherwise, it’s added to the list of address we still need “to_send” postcards to.

if addr_identifier(to_address) in processed_addrs:
    already_sent.append(to_address)
else:
    to_send.append(to_address)

Next we print out the number of backers we’ve already sent postcards to and check to see if we need to send postcards to anybody, exiting if we don’t need to send postcards to anybody.

nbackers = len(addresses.items)
print("Already sent postcards to {} of {} backers".format(len(already_sent), nbackers))
if not to_send:
    print("SUCCESS: All backers with verified addresses have been processed, you're done!")
    return

Finally, if we do need to send one or more postcards, we tell the user how many postcards will be mailed and then ask them to confirm that those postcards should be mailed:

query = "Send to {} unsent backers now? [y/N]: ".format(len(to_send), nbackers)
if raw_input(query).lower() == "y":
    successes = failures = 0

If the user enters “Y” or “y”, then we start sending postcards. The call to Lob is wrapped in a “try/except” block. We handle calls to the Lob library that return a “LobError” exception, counting those calls as a “failure”. Other exceptions are not handled and will result in the script exciting with that exception.

for to_address in to_send:
    try:
        rv = lob.Postcard.create(to=to_address, name=postcard_name, from_address=postcard_from_address, front=postcard_front, message=postcard_message)
        print("Postcard sent to {}! ({})".format(to_address['name'], rv.id))
        successes += 1
    except lob.exceptions.LobError:
        msg = 'Error: Failed to send postcard to Lob.com'
        print("{} for {}".format(msg, to_address['name']))
        failures += 1

Lastly, we print a message indicating how many messages were sent and how many failures we had.

    print("Successfully sent to {} backers with {} failures".format(successes, failures))
else:

(If the user pressed a key other than “Y” or “y”, this is the message that they’ll see)

print("Okay, not sending to unsent backers.")

And there you have it, a short script that uses Lob to send postcards to your Kickstarter backers, with code to only send one postcard per address, that gracefully handles errors from Lob.

I hope that you’ve found this useful! Please let us know of any issues you encounter on Github, or send pull requests adding exciting new features. Most importantly, enjoy easily bringing smiles to your backers!

on April 22, 2014 12:00 PM

April 21, 2014

Welcome to the Ubuntu Weekly Newsletter. This is issue #364 for the week April 14 – 20, 2014, and the full version is available here.

In this issue we cover:

The issue of The Ubuntu Weekly Newsletter is brought to you by:

  • Elizabeth Krumbach Joseph
  • Paul White
  • Emily Gonyer
  • Tiago Carrondo
  • Jose Antonio Rey
  • Jim Connett
  • And many others

If you have a story idea for the Weekly Newsletter, join the Ubuntu News Team mailing list and submit it. Ideas can also be added to the wiki!

Except where otherwise noted, content in this issue is licensed under a Creative Commons Attribution 3.0 License BY SA Creative Commons License

on April 21, 2014 09:30 PM
Recently I came across www.androidpolice.com/2014/04/07/new-app-huey-synchronizes-philips-hue-lights-with-your-movies-and-tv-shows-for-awesome-ambient-lighting-effects/ and thought it was pretty neat.  The lights were expensive however, and it required your phone or tablet to be in use every time you wanted to use it which seemed sub-optimal.

I've been hunting for a useful project to do with my Raspberry Pi, and found out that there were two major projects centered around getting something similar setup.

Ambi-TV: https://github.com/gkaindl/ambi-tv
Hyperion: https://github.com/tvdzwan/hyperion/wiki

With both software projects, you take an HDMI signal, convert it to analog and then capture the analog signal to analyze.  Once the signal is analyzed a string of addressable LED's is programmed to match what the borders are colored.
I did my initial setup using both software packages but in the end preferred using Hyperion for it's easy of use of configuration and results.

Necessary Hardware

I purchased the following (links point to where I purchased):
Other stuff I already had on hand that was needed:
  • Soldering tools
  • Spare prototyping board
  • Raspberry pi w/ case
  • Extra HDMI cables
  • Analog Composite cable 
  • Spare wires

Electronics Setup

Once everything arrived, I soldered a handful of wires to a prototyping board so that I could house more of the pieces in the raspberry pi case.  I used a cut up micro USB cord to provide power from the 5V rail and ground to the pi itself and then also to one end of the 4 pin JST adapter.

Prototyping board, probably this size is overkill,
but I have flexibility for future projects to add on now.
The power comes into the board and is used to power both the LEDs and the the raspberry pi from a single power source.  The clock and data lines for the LED string are connected to some header cable to plug into the raspberry pi.

GPIO connectors

The clock and data lines on the LPD8806 strip (DI/CI)  matched up to these pins on the raspberry pi:
Pin 19 (MOSI)          LPD8806 DAT pin
Pin 23 (SCLK) LPD8806 CLK pin
Although it's possible to power the raspberry pi from the 5V and ground rails in the GPIO connector on the pi instead of micro USB, there is no over current protection on those rails.  In case of any problems with a current spike the pi would be toast.

Case

Once I got everything put into the pi properly, I double checked all the connections and closed up the case.
My pi case with the top removed and an
inset put in for holding the proto board
Whole thing assembled

TV mounted LEDs

I proceeded to do the TV.  I have a 46" set, which works out to 18 LEDs on either side and 30 LEDs on the top and bottom.  I cut up the LED strips and used double sided tape to affix to the TV.  Once the LED strips are cut up you have to solder 4 pins from the out end of one strip to the in end of another strip.  I'd recommend looking for some of the prebuilt L corner strips if you do this.  I didn't use them and it was a pain to strip and hold such small wires in place to solder in the small corners.  All of the pins that are marked "out" on one end of the LED strip get connected to the "in" end on the next strip.

Back of TV w/ LEDs attached

Corner with wires soldered on from out to in

External hardware Setup

From the output of my receiver that would be going to my TV, I connect it to the input of the HDMI splitter.
The HDMI splitter's primary output goes to the TV.
The secondary output goes to the HDMI2AV adapter.
The HDMI2AV adapter's composite video output gets connected to the video input of the USB grabber.
The USB grabber is plugged directly into the raspberry pi.


Software Setup

Once all the HW was together I proceeded to get the software set up.  I originally had an up to date version of raspbian wheezy installed.  It included an updated kernel (version 3.10).  I managed to set everything up using it except the grabber, but then discovered that there were problems with the USB grabber I purchased.
Plugging it in causes the box to kernel panic.  The driver for the USB grabber has made it upstream in kernel version 3.11, so I expected it should be usable in 3.10 with some simple backporting tweaks, but didn't narrow it down entirely.

I did find out that kernel 3.6.11 did work with an earlier version of the driver however, so I re-did my install using an older snapshot of raspbian.  I managed to get things working there, but would like to iron out the problems causing a kernel panic at some point.

USB Grabber instructions

The USB grabber I got is dirt cheap but not based off the really common chipsets already supported in the kernel with the versions in raspbian, so it requires some extra work.
  1. Install Raspbian snapshot from 2013-07-26.  Configure as desired.
  2. git clone https://github.com/gkaindl/ambi-tv.git ambi-tv
  3. cd ambi-tv/misc && sudo sh ./get-kernel-source.sh
  4. cd usbtv-driver && make
  5. sudo mkdir /lib/modules/3.6.11+/extra
  6. sudo cp usbtv.ko /lib/modules/3.6.11+/extra/
  7. sudo depmod -a

Hyperiond Instructions

After getting the grabber working, installing hyperion is a piece of cake.  This will set up hyperiond to start on boot.
  1. wget -N https://raw.github.com/tvdzwan/hyperion/master/bin/install_hyperion.sh
  2. sudo sh ./install_hyperion.sh
  3. Edit /etc/modprobe.d/raspi-blacklist.conf using nano.  Comment out the line with blacklist spi-bcm2708
  4. sudo reboot

Hyperion configuration file

From another PC that has java (OpenJDK 7 works on Ubuntu 14.04)
  1. Visit https://github.com/tvdzwan/hyperion/wiki/configuration and fetch the jar file.
  2. Run it to configure your LEDs.
  3. From the defaults, I particularly had to change the LED type and the number of LEDs around the TV.
  4. My LEDs were originally listed at RGB but I later discovered that they are GRB.  If you encounter problems later with the wrong colors showing up, you can change them here too.
  5. Save the conf file and scp it into the /etc directory on your pi
  6. sudo /etc/init.d/hyperiond restart

Test the LED's

  1. Plug in the LEDs and install the test application at https://github.com/tvdzwan/hyperion/wiki/android-remote
  2. Try out some of the patterns and color wheel to make sure that everything is working properly.  It will save you problems later diagnosing grabber problems if you know things are sound here (this is where I found my RGB/GRB problem).
Test pattern

Set up things for Hyperion-V4L2

I created a script in ~ called toggle_backlight.sh.  It runs the V4L2 capture application (hyperion-v4l2) and sets the LEDs accordingly.  I can invoke it again to turn off the LEDs.  As a future modification I intend to control this with my harmony remote or some other method.  If someone comes up with something cool, please share.

#!/bin/sh
ARG=toggle
if [ -n "$1" ]; then
        ARG=$1
fi
RUNNING=$(pgrep hyperion-v4l2)
if [ -n "$RUNNING" ]; then
        if [ "$ARG" = "on" ]; then
                exit 0
        fi
        pkill hyperion-v4l2
        exit 0
fi
hyperion-v4l2 --crop-height 30 --crop-width 10 --size-decimator 8 --frame-decimator 2 --skip-reply --signal-threshold 0.08&

That's the exact script I use to run things.  I had to modify the crop height from the defaults that were on the directions elsewhere to avoid flicker on the top.  To diganose problems here, I'd recommend using the --screenshot argument of hyperion-v4l2 and examining output.

Once you've got it good, add it to /etc/rc.local to start up on boot:

su pi -c /home/pi/toggle_backlight.sh

Test It all together

Everything should now be working.

Here's my working setup:

on April 21, 2014 08:44 PM

Bicentennial Man PosterEver since we started building the Ubuntu SDK, we’ve been trying to find ways of bringing the vast number of Android apps that exist over to Ubuntu. As with any new platform, there’s a chasm between Android apps and native apps that can only be crossed through the effort of porting.

There are simple solutions, of course, like providing an Android runtime on Ubuntu. On other platforms, those have shown to present Android apps as second-class citizens that can’t benefit from a new platform’s unique features. Worse, they don’t provide a way for apps to gradually become first-class citizens, so chasm between Android and native still exists, which means the vast majority of apps supported this way will never improve.

There are also complicates solutions, like code conversion, that try to translate Android/Java code into the native platform’s language and toolkit, preserving logic and structure along the way. But doing this right becomes such a monumental task that making a tool to do it is virtually impossible, and the amount of cleanup and checking needed to be done by an actual developer quickly rises to the same level of effort as a manual port would have. This approach also fails to take advantage of differences in the platforms, and will re-create the old way of doing things even when it doesn’t make sense on the new platform.

Screenshot from 2014-04-19 14:44:22NDR takes a different approach to these, it doesn’t let you run our Android code on Ubuntu, nor does it try to convert your Android code to native code. Instead NDR will re-create the general framework of your Android app as a native Ubuntu app, converting Activities to Pages, for example, to give you a skeleton project on which you can build your port. It won’t get you over the chasm, but it’ll show you the path to take and give you a head start on it. You will just need to fill it in with the logic code to make it behave like your Android app. NDR won’t provide any of logic for you, and chances are you’ll want to do it slightly differently than you did in Android anyway, due to the differences between the two platforms.

Screenshot from 2014-04-19 14:44:31To test NDR during development, I chose the Telegram app because it was open source, popular, and largely used Android’s layout definitions and components. NDR will be less useful against apps such as games, that use their own UI components and draw directly to a canvas, but it’s pretty good at converting apps that use Android’s components and UI builder.

After only a couple days of hacking I was able to get NDR to generate enough of an Ubuntu SDK application that, with a little bit of manual cleanup, it was recognizably similar to the Android app’s.

This proves, in my opinion, that bootstrapping an Ubuntu port based on Android source code is not only possible, but is a viable way of supporting Android app developers who want to cross that chasm and target their apps for Ubuntu as well. I hope it will open the door for high-quality, native Ubuntu app ports from the Android ecosystem.  There is still much more NDR can do to make this easier, and having people with more Android experience than me (that would be none) would certainly make it a more powerful tool, so I’m making it a public, open source project on Launchpad and am inviting anybody who has an interest in this to help me improve it.

on April 21, 2014 06:54 PM
On Friday I started my app "GetThereDC". I started by adding the locations of all of the Bikeshare stations in DC to a map. Knowing where the stations are is great, but it's a bummer when you go to a station and there are no bikes, or there are no empty parking spots. Fortunately, that exact information is in the XML feed, so I just need a way to display it.  
The way I decided to do it is to make the POI (the little icons for each station on the map) clickable, and when the user clicks the POI to use the Popover feature in the Ubuntu Components toolkit to display the data.

Make the POI Clickable

When you want to make anyting "clickable" in QML, you just use a MouseArea component. Remember that each POI is constructed as a delegate in the MapItemView as an Image component. So all I have to do is add a MouseArea inside the Image and respond to the Click event. So, not my image looks like this:
           sourceItem: Image  
{
id: poiImage
width: units.gu(2)
height: units.gu(2)
source: "images/bike_poi.png"
MouseArea
{
anchors.fill: parent
onClicked:
{
print("The POI was clicked! ")
}
}
}
This can be used anywhere in QML to make an image respond to a click. MouseArea, of course, has other useful events as well, for things like onPressed, onPressAndHold, etc...

Add the Roles to the XmlListModel

I already know that I'll want something to use for a title for each station, the address, as well as the number of bikes and the number of parking slots. Looking at the XML I can see that the "name" property is the address, so that's a bonus. Additionally, I can see the other properties I want are called "nbBikes" and "nbEmptyDocks". So, all I do is add those three new roles to the XmlListModel that I constructed before:
   XmlListModel  
{
id: bikeStationModel
source: "https://www.capitalbikeshare.com/data/stations/bikeStations.xml"
query: "/stations/station"
XmlRole { name: "lat"; query: "lat/string()"; isKey: true }
XmlRole { name: "lng"; query: "long/string()"; isKey: true }
XmlRole {name: "name"; query: "name/string()"; isKey: true}
XmlRole {name: "available"; query: "nbBikes/string()"; isKey: true}
XmlRole {name: "freeSlots"; query: "nbEmptyDocks/string()"; isKey: true}
}

Make a Popover Component

The Ubuntu SDK offers some options for displaying additional information. In old school applications these might be dialog boxes, or message boxes. For the purposes of this app, Popover looks like the best bet. I suspect that over time the popover code might get a little complex, so I don't want it to be too deeply nested inside the MapItemView, as the code will become unwieldy. So, instead I decided to add a file called BikeShareStationPopover.qml to the components sub-directory. Then I copy and pasted the sample code in the documentation to get started. 

To make a popover, you start with a Component tag, and then add a popover tag inside that. Then, you can put pretty much whatever you want into that Popover. I am going to go with a Column and use ListItem components because I think it will look nice, and it's the easiest way to get started. Since I already added the XmlRoles I'll just use those roles in the construction of each popover. 

Since I know that I will be adding other kinds of POI, I decided to add a Capital Bike Share logo to the top of the list so users will know what kind of POI they clicked. I also added a close button just to be certain that users don't get confused about how to go back to the map. So, at the end of they day, I just have a column with ListItems:
 import QtQuick 2.0  
import Ubuntu.Components 0.1
import Ubuntu.Components.ListItems 0.1 as ListItem
import Ubuntu.Components.Popups 0.1
Component
{
id: popoverComponent
Popover
{
id: popover
Column
{
id: containerLayout
anchors
{
left: parent.left
top: parent.top
right: parent.right
}
ListItem.SingleControl
{
control: Image
{
source: "../images/CapitalBikeshare_Logo.jpg"
height: units.gu(5)
width: units.gu(5)
}
}
ListItem.Header { text: name}
ListItem.Standard { text: available + " bikes available" }
ListItem.Standard { text: freeSlots + " parking spots available"}
ListItem.SingleControl
{
highlightWhenPressed: false
control: Button
{
text: "Close"
onClicked: PopupUtils.close(popover)
}
}
}
}

Make the Popover Component Appear on Click

So, now that I made the component code, I just need to add it to the MapItemView and make it appear on click. So, I add the tag and give it an id to the MapQuickItem Delegate, and change the onClicked handler for the MouseArea to open the popover:
 delegate: MapQuickItem  
{
id: poiItem
coordinate: QtPositioning.coordinate(lat,lng)
anchorPoint.x: poiImage.width * 0.5
anchorPoint.y: poiImage.height
z: 9
sourceItem: Image
{
id: poiImage
width: units.gu(2)
height: units.gu(2)
source: "images/bike_poi.png"
MouseArea
{
anchors.fill: parent
onClicked:
{
PopupUtils.open(bikeSharePopover)
}
}
}
BikeShareStationPopover
{
id: bikeSharePopover
}
}
And when I run the app, I can click on any POI and see the info I want! Easy!

Code is here
on April 21, 2014 03:30 PM

April 20, 2014

Lubuntu 14.04

Lubuntu Blog

First of all, my apologies for disappear due to personal reasons (went out for a few days). But it's here, Lubuntu 14.04 codename Trusty Tahr. The missing links for PowerPC machines have been recovered. Feel free to go to the Downloads section and grab it. If you need more info check the release page.
on April 20, 2014 07:52 PM

ubuntu-open-week

And the Ubuntu Open Week for this cycle is just around the corner! This will be three days full of excitement, where you will be able to know what different teams and people in the community do. Whether you are a developer, a designer, a tester or a community member, this is the right event if you want to get involved with the community and are looking for a starting point.

The event will take place from April 22nd to April 24th 2014, from 15 to 19 UTC each day. During these three days we will have people from various teams, such as the Server, Documentation, and Juju teams. There are twelve different sessions scheduled, so make sure to find which ones interest you and write the times down in your calendars! The full schedule can be found at the Open Week Wiki page.

All sessions will take place at #ubuntu-classroom and #ubuntu-classroom-chat on irc.freenode.net (click here to join from your web browser). There are three sessions in the schedule which are labeled with the [ON AIR!] tag, which means the session will be streamed live at the Ubuntu on Air! webpage.

In the case you can not attend the event, logs will be linked in the schedule as soon as they become available. For On Air! sessions, they will be available at the Ubuntu on Air! YouTube Channel. Hope to see you all there!


on April 20, 2014 03:15 AM

April 19, 2014

The past week has been exhilarating and exhausting for our Kubuntu crew. I'm sure the other *buntu teams were working just as hard. Not just packaging, because that goes on all the time, though not at this intense pace. But the attention to detail, the testing, polishing, patching, discussion with developers to get those patches upstream, coordination with Debian, cleaning up copyright files, man pages and other documentation, making screen shots, our user docs and new website, more testing, more polish.... it was truly an amazing effort.

I used `ubuntu-bug` from the cli more than I ever have before, testing out the betas. It was an amazing experience to file the bug, and then see it fixed within the day! This happened again and again. The entire Ubuntu ecosystem really works well together. My thanks to those developers who read and respond to those bug reports.

What I love about Kubuntu is how everyone pitches in. All of us try to maintain balance in our lives, so that there is time for leisure and enrichment, along with work. Also, the work is fun, because the team enjoys one another, posting fun links, joking around, but continuing to work away on our todo lists. Even those who didn't have time for packaging, often stopped by the devel channel to find out what needed testing. It all helped!

Since I'm not a devel, all this was inspiring rather than exhausting. So I had the time and energy to spend time helping out folks with questions and trouble in #kubuntu and #kde. That felt great! We were able to answer most of the questions, and overcome most of the difficulties.

One issue that came up quite a few times in the last couple of days, was PPAs. On a clean install, of course all old PPAs are blown away. On an upgrade, however, they can linger and cause lots of perplexing problems. Official PPAs like backports are fine, but specialty ones should be removed before upgrading. If you need them, you can always re-add after the upgrade. For the same reason, unpin any packages you have pinned.

It is really fabulous to be able to present the latest KDE software into our Kubuntu LTS. This will give us the freedom to try out the newest stuff from KDE based on the sparkly new Frameworks, Plasma Next and so forth, in our next release. So, our users will be able to use software supported for five years if they want, while also having the option to install 14.10 (if all goes well) and check out the newest.
on April 19, 2014 10:35 PM

UbuconLA is happy to announce that Canonical and the Ubuntu Community will be sponsors in this version 2014.

Also, the Ubuntu Community will be present in the event with members from Spain, India, Uruguay, Venezuela, Mexico, Peru, Colombia, giving talks and workshops… the perfect place to learn a lot about Linux, Ubuntu ,Community, all in this amazing event.

 

 

You can find more information about the UbuconLA in the official site and wikipage


on April 19, 2014 05:57 PM

Today, tweaking the Bootstrap_Walker class used by Melany for another project, I discovered an interesting issue with the title attribute.

Melany allows you to prepend a menu item with an icon coming from the Glyphicon set included in Twitter Bootstrap in a very easy way: just put the glyphicon name in the menu item’s title attribute field and let the Melany do the rest. See an example in the following image:

How to prepend icons to menu items

How to prepend icons to menu items

So, what’s the problem? Well, if you try to define a true title attribute, it won’t work, because the Bootstrap_Walker handles this attribute as if it were an icon. Let me do an example. If you want to set the title attribute to “This link opens in a new tab”, the resulting markup is:

<a href="[menu_item_url]"><span class="glyphicon This link opens in a new tab"></span>&nbsp;[navigation_label]</a>

Of course, you wanted something like this:

<a href="[menu_item_url]" title="This link opens in a new tab">[navigation_label]</a>

I solved this issue with a simple check to see if the word glyphicon is in the title attribute, so you can now use this real attribute without problems. The fix is already in the 1.1.0-dev version, but will soon be released in the 1.0.5 series too.

I hope this has not caused you too many hassles.

Oh, do you know Melany 1.1.0 Alpha2 has been released? Check it out!

on April 19, 2014 05:31 PM

After some last minute critical fixes and ISO respins by the release team (thanks again Infinity, we owe you and the rest of the release team a beer), the Mythbuntu team is proud to announce we have removed our socks (see relevant post) and released Mythbuntu 14.04 LTS. This is the Mythbuntu team's second LTS release and is supported until shortly after the 16.04 release.

With this release, we are providing mirroring on sponsored mirrors and torrents. It is very important to note that this release is only compatible with MythTV 0.27 systems. The MythTV component of previous Mythbuntu releases can be be upgraded to a compatible MythTV version by using the Mythbuntu Repos. For a more detailed explanation, see here.

You can get the Mythbuntu 14.04 ISO from our downloads page.

Highlights

  • MythTV 0.27 (2:0.27.0+fixes.20140324.8ee257c-0ubuntu3)
  • This is our second LTS release (the first being 12.04). See this page for more info.

Underlying system

  • Underlying Ubuntu updates are found here

MythTV

  • Recent snapshot of the MythTV 0.27 release is included (see 0.27 Release Notes)
  • Mythbuntu theme fixes

We appreciated all comments and would love to hear what you think. Please make comments to our mailing list, on the forums (with a tag indicating that this is from 14.04 or trusty), or in #ubuntu-mythtv on Freenode. As previously, if you encounter any issues with anything in this release, please file a bug using the Ubuntu bug tool (ubuntu-bug PACKAGENAME) which automatically collects logs and other important system information, or if that is not possible, directly open a ticket on Launchpad (http://bugs.launchpad.net/mythbuntu/14.04/).

Known issues

  • Upgraders should hold off until our first point (14.04.1) coming this summer. (See bugs #1307546 )
  • Don't select VNC during install. It can be activated later. (Bug #1309752)
  • If you are upgrading and want to use the HTTP Live Streaming you need to create a Streaming storage group
on April 19, 2014 02:04 PM

Hi,

Two days ago, the entire world has celebrated the release of Ubuntu GNOME 14.04 LTS and the other official flavours of Ubuntu.

Ubuntu GNOME Team has received many Emails and Posts on our Social Media Channels about the very same question/issue.

“Why the system information is showing Ubuntu 13.10 instead of Ubuntu 14.04″?!

Same question is being asked daily even before the final release of Ubuntu GNOME 14.04.

Ubuntu GNOME Team is asking everyone to please read the release notes of Ubuntu GNOME 14.04 LTS before downloading or upgrading to Ubuntu GNOME 14.04 LTS.

This is actually a must-do step with any new release/version of any Operating System/Software in the world and to be more specific here, it is a must-do step every time Ubuntu and its official flavours announce a new release every 6 months.

Why reading the release notes is very important?
The answer is very simple: because the release notes will explain everything about the new release and above all, show the known issues for every new release that all users must be aware of before anything else.

Sorry for the inconvenience
Ubuntu GNOME Team would like to apologize if we caused any kind of confusion and/or headache to the users of Ubuntu GNOME. Our Developers are working on the known issues, specially this problem:

System Details shows Ubuntu 13.10 instead of 14.04

A Workaround
Meanwhile, you can check and verify which release/version of Ubuntu GNOME you’re using by following these steps:

How can I find the version of Ubuntu that is installed?

Thank you!
As always, thank you for choosing and using Ubuntu GNOME and thanks for reading this very important note. Please keep that in mind with each and every release, you do need to read the release notes. This will save your time and save the trouble for you and for everyone else.

Enjoy and have fun with Ubuntu GNOME 14.04 LTS

Ali/amjjawad
On behalf of Ubuntu GNOME Team

on April 19, 2014 12:18 PM
We had the Trusty Tahr Release Party today at the University of Liberal Arts Bangladesh (ULAB), Dhaka. It was the official Ubuntu 14.04 release party of Ubuntu Bangladesh LoCo team in cooperation with “ULAB Computer Programming Club”. This time, we did it within two days of … Continue reading
on April 19, 2014 09:56 AM

Hy at PyCon 2014

Paul Tagliamonte

I gave a talk this year at PyCon 2014, about one of my favorite subjects: Hy. Many of my regular readers will have no doubt explored Hy's thriving GitHub org, played with try-hy, or even installed it locally by pip installing it. I was lucky enough to be able to attend PyCon on behalf of Sunlight, with a solid contingint of my colleagues. We put together a writeup on the Sunlight blog if anyone was interested in our favorite talks.

Tons of really amazing questions, and such an amazingly warm reception from so many of my peers throughout this year's PyCon. Thank you so much to everyone that attended the talk. As always, you should Fork Hy on GitHub, follow @hylang on the twitters, and send in any bugs you find!

Hopefully I'll be able to put my talk up in blog-post form soon, but until then feel free to look over the slides or just watch the talk.

An extra shout-out to @akaptur for hacking on Hy during the sprints, and giving the exception system quite the workthrough. Thanks, Allison!

on April 19, 2014 12:13 AM

April 18, 2014

Xspice in containers

Serge Hallyn

For some time I’ve been wanting to run ubuntu-desktop and others, remotely, in containers, using spice. Historically vnc has been the best way to do remote desktops, but spice should provide a far better experience. Unfortunately, Xspice has always failed for me, most recently segfaulting on startup. But fortunately, this is fixed in git, and I’m told a new release may be coming soon. While waiting for the new release (0.12.7?), I pushed a package based on git HEAD to ppa:serge-hallyn/virt.

You can create a container to test this with as follows:

lxc-create -t download -n desk1 -- -d ubuntu -r trusty -a amd64
lxc-start -n desk1 -d
lxc-attach -n desk1

Then inside that container shell,

add-apt-repository ppa:serge-hallyn/virt
apt-get update
apt-get install xserver-xspice ubuntu-desktop

ubuntu-desktop can take awhile to install. You can simply install fvwm and xterm if you want a quicker test. Once that’s all one, copy the xspice configuration file into your home directory, uncompress it, set the SpiceDisableTicketing option (or configure a password), and use the config file to configure an Xorg session:

cp /usr/share/doc/xserver-xspice/spiceqxl.xorg.conf.example.gz /root
cd /root
gunzip spiceqxl.xorg.conf.example.gz
cat >> spiceqxl.xorg.conf.example.gz << EOF
Option "SpiceDisableTicketing" "1"
EOF
/usr/bin/Xorg -config /root/spiceqxl.xorg.conf.example :2 &

Now fire up unity, xterm, or fvwm:

DISPLAY=:2 unity

Now connect using either spicy or spicec,

spicec -h  -p 5900

Of course if the container is on a remote host, you’ll want to set up some ssh port forwards to enable that, but if needed then that’s a subject for another post.


on April 18, 2014 08:12 PM

A little radiation goes a long way.

Your microwave can be used for more than reheating coffee.

It is far more versatile a device, for instance, you can make these fat-free potato chips ("crisps" for you British gentlepeople) in one with very little effort.

    Ingredients

  • 1 potato,
  • sea salt, to taste
  • any other seasoning or spice that you'd like to flavour the chips with.
  • Needed Equipment

  • Microwave
  • Useful Equipment

  • a mandoline –brilliant thing to have, even a sub-$20 will do
  • a silicon sheet –for a non-stick surface in the microwave, I recommend the brand "Silpat"

    Directions

  1. Thinly cut the potato into even, 2-3 millimeter slices.
  2. Here, a mandoline is incredibly useful (even perhaps ideal or necessary).
  3. Rinse the excess starch off the potato slices and shake/pat/spin off the excess water.
  4. Place the slices onto a non-stick microwave-safe (no metals!) sheet, without overlap.
  5. Microwave on high power for 2 minutes. This'll remove a lot of the water in the potato and you'll begin to see them browning.
  6. Flip the slices and microwave for another minute. Keep an eye on them while they're in there to prevent burning.
  7. Remove any nicely browned chips.
  8. For any not fully done, zap on high in 10 second intervals until they too are browned.
  9. Season with salt, to your tastes, and/or any other thing really.
  10. Enjoy, guilt-free. :)
on April 18, 2014 08:00 PM

PLUMgrid , the leader in Virtual Network Infrastructure (VNI), today announced that PLUMgrid VNI 3.0 has achieved certification for Red Hat Enterprise Linux OpenStack Platform . The certification ensures that PLUMgrid VNI 3.0 has been integrated, tested and certified for use with Red Hat Enterprise Linux OpenStack Platform.
PLUMgrid VNI 3.0 is a secure virtual networking product for large-scale OpenStack clouds. Built using PLUMgrid Platform and IO Visor™ technology , it provides an easy and simple solution to build cloud infrastructure at scale and offer secure, multi-tenant network services to OpenStack cloud users. Based on a highly automated workflow, PLUMgrid VNI 3.0 enables applications and users to deploy private Virtual Domains™ in seconds without changing the physical network fabric.

Source:

http://www.marketwatch.com/story/plumgrid-virtual-network-infrastructure-achieves-certification-for-red-hat-enterprise-linux-openstack-platform-2014-04-14

on April 18, 2014 07:18 PM

IBM says that now is great time for KVM (Kernel-based Virtual Machine) technology as a result of key contributions from its large developer community.
The KVM hypervisor is an open source virtualization technology and, increasingly, it is becoming an important tool in any Linux user’s handbook, especially in light of OpenStack.
KVM is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V) and consisting of a loadable kernel module (kvm.ko) that provides the core virtualization infrastructure and a processor-specific module (kvm-intel.ko) or (kvm-amd.ko).
IBM says that hypervisors have had to better manage compute, network, and storage resources — and that this need that has been fulfilled by KVM.

Source:

http://www.drdobbs.com/open-source/ibm-now-is-the-time-for-kvm/240167057

on April 18, 2014 07:17 PM
HUD shown over terminal app with commands visible

Most expert users know how powerful the command line is on their Ubuntu system, but one of the common criticisms of it is that the commands themselves are hard to discover and remember the exact syntax for. To help a little bit with this I've created a small patch to the Ubuntu Terminal which adds entries into the HUD so that they can be searched by how people might think of the feature. Hopefully this will provide a way to introduce people to the command line, and provide experienced users with some commands that they might have not known about on their Ubuntu Phone. Let's look at one of the commands I added:

UnityActions.Action {
  text: i18n.tr("Networking Status")
  keywords: i18n.tr("Wireless;Ethernet;Access Points")
  onTriggered: ksession.sendText("\x03\nnm-tool\n")
}

This command quite simply prints out the status of the networking on the device. But some folks probably don't think of it as networking, they just want to search for the wireless status. By using the HUD keywords feature we're able to add a list of other possible search strings for the command. Now someone can type wireless status into the HUD and figure out the command that they need. This is a powerful way to discover new functionality. Plus (and this is really important) these can all be translated into their local language.

It is tradition in my family to spend this weekend looking for brightly colored eggs that have been hidden. If you update your terminal application I hope you'll be able to enjoy the same tradition this weekend.

on April 18, 2014 05:46 PM

So at last it’s here. Ubuntu 14.04 LTS

And I have to say ‘Thank you’ for pushing this out.

I am running Trusty Tahr for a long time now, while it was still in development on my workstation. And it’s one of the best releases so far.

Even during development only some glitches were encountered, but were easily workarounded, and this is actually pretty amazing.

When you followed Ubuntu for some years now (and to some extend also invovled in pushing software to it), you know that this wasn’t always the case.

We had a couple of really serious hickups, but this release was very handsome. I think Canonicals push towards automated QA and the upload pocket behaviour change were the right things to do.

Thanks Guys, for delivering this amazing release. You really can celebrate and drink a lot of booze and have a good meal (well, now that Jono is the definitive Ubuntu Smoker King, he could serve some delicious pulled pork or whatever he is able to smoke ;))

Again, thank you, you all know who you are. You guys are amazing. Rock On!

on April 18, 2014 03:13 PM

You never really understand a person until you consider things from his point of view — until you climb into his skin and walk around in it.
–To Kill a Mockingbird, Atticus Finch

These aren’t purely my thoughts. I’m sure I read something somewhere that sparked them, but I don’t have a link or citation, so I’m just being honest that I am not the source of all that I have written here, although I am using my words. Oh, and great book.

I’ve been thinking about this. I love the idea and I will always strive to learn about and understand other’s perspectives. But, I feel inadequate, like if I am to be honest, I really cannot do this. Not completely, anyway.

No matter how hard we try, we will each still see things with some skewing from your own perspective. We can never really know what it’s like to be that other person.

When you hear, see, or experience other people’s lives you may try to put yourself in their shoes and consider how you would deal with life as it has been dealt to them. That is noble.

However, it is impossible for us to actually do so. We hear, see, and experience things differently and our history and emotional, spiritual, mental, and intellectual makeup and status affect that. We each create our own reality based on our experiences filtered through all those layers of what we call self.

You can live with someone your/their whole life but that doesn’t mean you really understand their perspective. You may know intimate details or have a pretty good idea of what the other person is likely to think or do in certain situations based on past responses and patterns of behavior, but that is not really the same thing.

No matter how much we think we do, we are unable to climb fully into the mind and perspective of someone else. We are all made up of our perceptions, experiences of success and failures, societal programming, genders, and more. Humans are complex

To fully grasp another person’s perspective in its purest form we would have to wipe clear all of who we are and then copy over to ourselves who the other person is. It is not possible to eliminate our biases this way.

I’m starting to think that we can never really climb inside someone else’s skin, but we can hope to acquire a better understanding. The attempt is worth the effort, even if it can never be complete. We can learn to walk beside someone else. We can attempt to see things from their perspective. In doing so, we each hope we gave and gained something from it, drawing each of us a little bit closer to the other.

on April 18, 2014 01:26 PM
Yesterday I started work on an app that I personally want to use. I don't have a car, so I use services like Metro Bus, Metro Rail, Car2Go, and BikeShare around DC all the time. It's annoying to go to each different web page or app to get the information that I want, so I decided to write an app that combines it all for me in one place.

After asking around, I settled on a best practice for Ubuntu map apps, and I was pointed to this excellent code as a basis:
http://bazaar.launchpad.net/~yohanboniface/osmtouch/trunk/view/head:/OSMTouch.qml

It was so easy and fun once I got started, that I decided to show the world. So, here we go.

I started with a "Simple UI" project. Then I deleted the default column that it started with, and I set the title of the Page to an empty string. While I was at it, I changed the height and width to be more like a phone's dimensions to make testing a little easier. So my starter code for an emply Window looks like this:
 import QtQuick 2.0  
import Ubuntu.Components 0.1
import "components"
MainView {
objectName: "mainView"
applicationName: "com.ubuntu.developer.rick-rickspencer3.MapExample"
width: units.gu(40)
height: units.gu(60)
Page
{
title: i18n.tr("")
}
}
So what's missing now is a map. First I need to import the parts of Qt where I get location and map information, so I add these imports:
 import QtPositioning 5.2  
import QtLocation 5.0
Then I can use the Map tag to add a Map to the MainView. I do four things in the Map to make it show up. First, I tell it to fill it's parent (normal for any component). Then I set it's center property. I choose to do this using a coordinate. Note that you can't make a coordinate in a declarative way, you have to construct it like below. The center property tells the map the latitude and longitude to be centered on. Then I choose the zoom level, which determines the scale of the map. Finally, I need to specify the plug in. For various reasons, I choose to use the Open Street Maps plugin, though feel free to experiment with others. So, a basic funcitonal map looks like this:
   Page  
{
title: i18n.tr("")
Map
{
anchors.fill: parent
center: QtPositioning.coordinate(38.87, -77.045)
zoomLevel: 13
plugin: Plugin { name: "osm"}
}
}
When I run it, I get a lot of functionality for free. On the desktop I can drag the map, and when I run the app on my phone or tablet, I can pinch to zoom in or out. All that functionality comes for free. Of course, you are free to add mapping controls as desired, but I find that map works well out of the box, at least on a device that supports pinch and zoom.


Typically, a map displays little pinpoints. These are often referred to as Points of Interest, or more typically "POI". It's delightfully easy to populate your map with POI using our old friend XmlListModel. First, you will need some XML that has location information. For this exmaple, I am going to use the Bike Share feed for Washington, DC. It's easy to get and to parse, so it makes a nice example. You can see the feed here:
https://www.capitalbikeshare.com/data/stations/bikeStations.xml

So let's use it to set up our XmlListModel. First, of course, we need to import the XmlListModel functionality.


 import QtQuick.XmlListModel 2.0  
Next, we'll make the list model, and use the query and Roles functionality to set up the model with the latitude and longitude of each POI inside the model. This is *exactly* like using the XmlListModel for a typical list view. Very cool.
   XmlListModel  
{
id: bikeStationModel
source: "https://www.capitalbikeshare.com/data/stations/bikeStations.xml"
query: "/stations/station"
XmlRole { name: "lat"; query: "lat/string()"; isKey: true }
XmlRole { name: "lng"; query: "long/string()"; isKey: true }
}
Now that I have my list model set up, it's time to display them on the Map. We don't do that with a ListView, but rather wtih a MapItemView. This works exactly the same as a ListView, except it displays items on a map instead of in a list. Just like a ListView I need a delegate that will translate use data from the each item in the XmlListModel to create a UI element. In this case, it's a MapQuickItem instead of a ListItem (or similar). A MapQuickItem needs to know 4 things.

  1. The model where it will get the data. In this case, it's my XmlListModel, but it could be a javascript list or other model as well.
  2. A latitude and longitude for the POI, which I set up as roles in the XmlListModel.
  3. An offset for whatever I am using for POI so that it is positioned properly. In this case I have made a little pushpin image out of the bikeshare logo (I know it's bad I'll make a better one later :) ). The offset is set by anchorPoint, so I make the anchorPoint the bottom and center of of the pushpin. 
  4. Something to use for the POI. In this case, I choose to use an image. Note that it is important to use grid units, or the POI may appear too small on some devices, and too large on others. Grid Units make them "just right" on all devices, and ensure that users can click them on any device. 


So, here is my MapItemView that goes *inside* the Map tag. It's a MapItemView for the map, after all.

       MapItemView  
{
model: bikeStationModel
delegate: MapQuickItem
{
id: poiItem
coordinate: QtPositioning.coordinate(lat,lng)
anchorPoint.x: poiImage.width * 0.5
anchorPoint.y: poiImage.height
sourceItem: Image
{
id: poiImage
width: units.gu(2)
height: units.gu(2)
source: "bike_poi.png"
}
}
}
Now when I run the app, the POI are displayed. As you would expect, when the user moves the Map, the MapItemView automatically displays the correct POI. It's really that easy.


If you want to add interactivity, that's easy, you can simply add a MouseArea to the Image and then use things like Ubuntu.Components.Popups to popup additional information about the POI. 


This sample code is here: http://bazaar.launchpad.net/~rick-rickspencer3/+junk/MapExample/view/head:/MapExample.qml
on April 18, 2014 01:10 PM

Kubuntu 14.04 LTS was released yesterday along with the all new KDE SC 4.13.  Browsing around the internet this morning the feedback feels really good.  Here’s some of my favourite quotes.

spiros spiros on Google+

Thank you for this great release :)

César J. Pinto on Google+

My God… I’m very surprise with kubuntu… it feels more fast than unity and gnome. wow…. I just…. i have no words to describe my happiness :D

@srikrishnaholla on Twitter

Downloading #kubuntu 14.04 LTS. Man, I’ve missed #kde !

 

@gholmer on Twitter
 

Get it while it’s hot! Newest Ubuntu with the king of desktop environments, KDE! #kubuntu http://www.kubuntu.org

@apachelogger on Twitter [OK he's not entirely neutral]

This is the best release so far! Such awesome, so #Kubuntu 14.04 LTS! http://goo.gl/jQFdZJ  #bestreleaseever

@jotakinhan on Twitter

Using #kubuntu again after using other distros for long time and its great!

@LowEndGeek on Twitter

Re-visiting #kde on #kubuntu 14.04 Working much better than regular #ubuntu

One of the first reviews was on Tux Arena:

“It is a beautiful release and it will definitely be here to stay for quite some time”

And in my inbox:

From: Robert Kovacs

Subject: Excellent Release Kubuntu 14.04

Date: Fri, 18 Apr 2014 00:15:33 -0400

Thanks for all the hard work!. Kudos to the Kubuntu team. Just installed     Kubuntu 14.04 and everything is working fine. Was using Kubuntu 12.04.3,    which was also a great release.

Cheers!.
Bob Kovacs (USA)

on April 18, 2014 11:50 AM

Just finished up the first draft of an Installfest worksheet.  Let me know what you think…

XP to Ubuntu Worksheet

on April 18, 2014 05:20 AM

April 17, 2014

My apologies in advance for the shorter blog post about this, but like many other Ubuntu folks, I am absolutely exhausted right now. Everyone, across the board, has been working their collective socks off to make Ubuntu 14.04 LTS a fantastic release on desktop, server, and cloud, and pull together our next iteration of Ubuntu for smart-phones and tablets. Consequently, when the trigger is pulled to share our final product with the world, release day is often less of a blistering and energetic woo-hoo, but more of an exhausted but satisfying oh-yeah (complete with beer firmly clenched in hand).

I am hugely proud of this release. The last six months have arguably been our busiest yet. No longer are we just working on desktop and server editions of Ubuntu, but we are building for the cloud and full convergence across the client. No longer are we “just” pulling together the fruits of upstream software projects but we are building our own platform too; the Ubuntu SDK, developer eco-system, charm store, image-based updates, push notifications, app lifecycle, and more. While the work has been intense and at times frantic, it has always been measured and carefully executed. Much of this has been thanks to many of our most under-thanked people; the members of our tremendous QA and CI teams.

Today, tomorrow, and for weeks to come our users, the press, the industry, and others will assess our work in Ubuntu 14.04 across these different platforms, and I am very confident they will love what they see. Ubuntu 14.04 embodies the true spirit of Ubuntu; innovation, openness, and people.

But as we wait to see the reviews let’s take a moment for each other. Now is a great time to reach out to each other and those Ubuntu folks you know (and don’t know) and share some kudos, some thanks, and some great stories. Until we get to the day where machines make software, today software is made by people and great software is built by great people.

Thanks everyone for every ounce of effort you fed into Ubuntu and our many flavors. We just took another big leap forward towards our future.

on April 17, 2014 10:58 PM
on April 17, 2014 10:19 PM

Trust in Trusty 14.04 LTS

Jonathan Riddell

KDE Project:


Trust in Me

You've been waiting for it, we've been working hard on it.. it's the new Long Term Support release of Kubuntu!

This means we've been working hard on removing bugs, polishing features and not adding new ones. This will probably be the last release before KDE Frameworks 5 and Plasma Next gets introduced so for those who like to live life on the cautious side you'll be pleased to know the Long Term Support label means we'll have important bug fixes and security fixes for the next 5 years. It'll also get backports of important KDE software for the next couple of years.


But that doesn't mean there's nothing new. Take a look at the release announcement for a long list. For one thing we're the first distro to ship with KDE SC 4.13 fresh out today. It brings a much nicer desktop search capability that makes search fly.

Muon is slicker, all new Driver Manager means hardware works better, Gwenview plugins mean it's easier to upload to Facebook, KDE Connect makes your phone talk to your laptop.

All wrapped up with the safety of commercial support if you need it and plenty of community support if you need that.

I'd like to thank Harald who put in a lot of effort in this release, even writing up release notes which I've never found anyone to help with before. Rohan did crutial last minute bugfixes including at the last minute and nifty new features like the Driver Manager. Aurelien took care of Ubiquity to get your installs looking nice. We've all new documentation thanks to Aaron and Valerie and others. Scott kept the policy ticking over. Phillip got things packaged, debfx had bug fixes when it was needed most, Michal keeping an eye on the important packages, Scarlett being the Queen of packaging for KF5 and others. Really what a wonderful team effort.

And next? We'll be looking at making KDE Frameworks usable, Plasma 2014.6 may be the next desktop and who knows we may even get something working with Wayland. it's exiting! Come and join us, chat in #kubuntu-devel and join the kubuntu-devel mailing list.

on April 17, 2014 10:16 PM

I’m pleased to announce the general availability of OpenStack 2014.1 (Icehouse) in Ubuntu 14.04 LTS and in the Ubuntu Cloud Archive (UCA) for Ubuntu 12.04 LTS.

Users of Ubuntu 14.04 need take no further action other than follow their favourite install guide – but do take some time to checkout the release notes for Ubuntu 14.04.

Ubuntu 12.04 users can enable the Icehouse pocket of the UCA by running:

sudo add-apt-repository cloud-archive:icehouse

The Icehouse pocket of the UCA also includes updates for associated packages including Ceph 0.79 (which will be updated to the Ceph 0.80 Firefly stable release), Open vSwitch 2.0.1, qemu 2.0.0 and libvirt 1.2.2 – you can checkout the full list here.

Thanks goes to all of the people who have contributed to making OpenStack rock this release cycle – both upstream and in Ubuntu!

Remember that you can report bugs on packages from the UCA for Ubuntu 12.04 and from Ubuntu 14.04 using the ubuntu-bug tool – for example:

ubuntu-bug nova

will report the bug in the right place on launchpad and add some basic information about your installation.

The Juju charms for OpenStack have also been updated to support deployment of OpenStack Icehouse on Ubuntu 14.04 and Ubuntu 12.04.  Read the charm release notes for more details on the new features that have been enabled during this development cycle.

Canonical have a more concise install guide in the pipeline for deploying OpenStack using Juju and MAAS  – watch this space for more information…

EOM

 


on April 17, 2014 09:51 PM

14.04 Release Today

Svetlana Belkin

Stephen Michael Kellat asked me to post this:

Greetings Ohio.

As this is sent, the release announcement for Ubuntu and its many flavors is not up yet. Please take the time to download the 14.04 Long Term Support Release and to liberally seed torrents if you can. So far Xubuntu 14.04 has been wonderful and I am an “apt-get dist-upgrade” away from transitioning off beta to final on my installed base.

Discs for distribution have **not** been pre-ordered. If there is interest in doing a disc distribution campaign, please talk to the three Deputies about making a plan. I will not order discs to just have lay around gathering dust.

Have a great Thursday. Svetlana Belkin, James Gifford, Unit193…I leave the celebrations for you to lead. Svetlana, please post a copy of this message to your blog with such comment as you deem fit. My duties at work plus commute time prevent my celebrating much for this release on release day.

Stephen Michael Kellat
Point of Contact/Leader, Ubuntu Ohio
Member, LoCo Council

As for me, I have Ubuntu 14.04 32 bit on one of my laptops and I will have a review of Ubuntu 14.04 up soon.


on April 17, 2014 09:30 PM
While doing final QA testing of the image, the Mythbuntu team found a few release critical bugs. Despite our best efforts we were unable to resolve these issues in time so today we made the tough decision and decided to pull the ISO that was to be released.

We would like to congratulate the other Ubuntu Flavors on their 14.04 releases and have plans to join them with our 14.04 release in the next week. We would also like to thank all of our users for their patience and their continued support.

Critical Bugs


on April 17, 2014 08:15 PM