Test a stable release update

Ubuntu has a six month cycle for releases. This means that we work for six months updating software, adding new features and making sure that it all works consistently together when it’s integrated into the operating system, and then we release it. Once we make a release, it is considered stable and then we almost exclusively add to that release critical bug fixes and patches for security vulnerabilities. The exceptions are just a few, and are for software that’s important for Ubuntu and that we want to keep up-to-date with the latest features even in stable releases.

These bug fixes, security patches and exceptional new features require a lot of testing, because right after they are published they will reach all the Ubuntu users that are in the stable release. And we want the release to remain stable, never ever introduce a regression that will make those users unhappy.

We call all of them Stable Release Updates, and we test them in the proposed pocket of the Ubuntu archive. This is obviously not enabled by default, so the brave souls that want to help us testing the changes in proposed need to enable it.

Before we go on, I would recommend to test SRUs in a virtual machine. Once you enable proposed following this guide you will get constant and untested updates from many packages, and these updates will break parts of your system every now and then. It’s not likely to be critical, but it can bother you if it happens on the machine you need to do your work, or other stuff. And if somebody makes a mistake, you might need to reinstall the system.

You will also have to find a package that needs testing. Snapcraft is one of the few exceptions allowed to land in a stable release every week. So lets use it as an example. Lets say you want to help us testing the upcoming release of snapcraft in Ubuntu 16.04.

With your machine ready and before enabling proposed, install the version already released of the package you want to test. This way you’ll test later an update to the newer version, just what a normal user would get once the update is approved and lands in the archive. So in a terminal, write:

  $ sudo apt update
  $ sudo apt install snapcraft

Or replace snapcraft with whatever package you are testing. If you are doing it just during the weekend after I am writing this, the released version of snapcraft will be 2.23. You can check it with:

  $ dpkg -s snapcraft | grep Version
  Version: 2.23

Now, to enable proposed, open the Ubuntu Software application, and select Software & Updates from the menu in the top of the window.


From the Software & Updates window, select the Developer Options tab. And check the item that says Pre-released updates.


This will prompt for your password. Enter it, and then click the Close button. You will be asked if you want to reload your sources, so yes, click the Reload button.


Finally try to upgrade. If there is a newer version available in the proposed pocket for the packet you are testing, now you will get it.

  $ sudo apt install snapcraft
  $ dpkg -s snapcraft | grep Version
  Version: 2.24

Every time there is a proposed update, the package will have corresponding SRU bugs with the tag “verification-needed”. In the case of snapcraft this weekend, this is the bug for the 2.24 proposed update: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1650632

The SRU bugs will have instructions about how to test that the fix or the new features released are correct. Follow those steps, and if you are confident that they work as expected, change the tag to “verification-done”. If you find that the fix is not correct, change the tag to “verification-failed”. In case of doubt, you can leave a comment in the bug explaining what you tried and what you found.

You can read more about SRUs in the Stable Release Updates wiki page, and also in the wiki page explaining how to perform verifications. This last page includes a section to find packages and bugs that need verification. If you want to help the Ubuntu community, you can just jump in and start verifying some of the pending bugs. It will be highly appreciated.

If you have questions or find a problem, join us in the Ubuntu Rocket Chat.

Ubuntu Testing Day wrap up - Unity8 (20161209)

For the third session of the Ubuntu Testing Days, Kevin Gunn joined us to talk about the Unity8 snap.

This is a thriving project with lots of things to do and bugs to uncover, so it's the perfect candidate for newcomers eager to help Ubuntu.

If you are interested and didn't attend our meeting on Friday, click the image below to watch the recording.

Alt text

To install Unity 8 in the Ubuntu 16.04 cloned virtual machine that we prepared on the past session, enter the following commands in the terminal:

$ sudo add-apt-repository -u ppa:ci-train-ppa-service/stable-phone-overlay
$ sudo apt install unity8-session-snap
$ unity8-snap-install
$ sudo reboot

After reboot, on the login screen click the Ubuntu icon next to your user name and change the selection to Unity 8.

Kevin and his team have a google doc with the instructions to build and install the snap, and the current status. If you find a bug, you can talk to the developers joining the #ubuntu-touch IRC channel on freenode

While preparing the testing environment on this session we had a crash, and explained how easy it is to send the report to the Ubuntu developers by just clicking the Report problem... button. The reports from all our users are in the error tracker, along with a frequency graph and the links to bug reports where those crashes are being fixed.

We also showed two tricks to make faster and more pleasant the testing session in a virtual machine:

Thanks to Julia, Kyle and Kevin for the nice session.

Join us again next Friday at Ubuntu On-Air.

Set up a cache for deb packages

All Linux distributions are constantly updating the versions of the packages in their archives. That’s what makes them great, lots of people working in a distributed way to let you easily update your software and get the latest features or critical bug fixes.

And you should constatly update your operating system. Otherwise you’ll become an easy target for criminals exploiting known vulnerabilities.

The problem, at least for me, is that I have many many Ubuntu machines in the house and my badwidth is really bad. So keeping all my real machines, virtual machines and various devices up-to-date every day has become a slow problem.

The solution is to cache the downloaded deb packages. So only one machine has to make the downloads from the internet, and they will be kept in my local network to make much faster to get the packages in the other machines.

So let me introduce you to Apt-Cacher NG.

Setting it up is simple. First, choose a machine to run the cacher and store the packages. Ideally, this machine should be running all the time, and should have a good amount of storage space. I’m using my desktop as the cacher; but as soon as I update my router to one that runs Ubuntu, I will make that one the cacher.

On that machine, install apt-cacher-ng:

  sudo apt install apt-cacher-ng

And that’s it. The cacher is installed and configured. Now we need the name of this machine to use it on the other ones:

  $ hostname

In this example, calchas is the name of the machine I’m using as the cacher. Take note of the name of your machine, and now, in all the other machines:

  $ sudo gedit /etc/apt/apt.conf.d/02proxy

That will create a new empty configuration file for apt, and open it to be edited with gedit, the default graphical editor in Ubuntu. In the editor, write this:

  Acquire::http::proxy "http://calchas.lan:3142";

replacing calchas with the name of your cacher machine, collected above. The .lan part is really only needed when you are setting it up in a virtual machine and the host is the same as the cacher, but it doesn’t hurt to add it on real machines. That number, 3142, is the network port where the caching service is running, leave it unchanged.

After that, the first time you update a package in your network it will be slow just as before. But all the other machines updating the same package will be very fast. I have to thank apt-cacher-ng for saving me many hours during my updates of the past years.

Ubuntu Testing Day wrap up - 20161202

We have survived two testing days, and now we can safely say that it will become a Friday tradition :)

Last Friday our nice guest was Aaron Ogle, from Rocket Chat. He gave us a tour on the Rocket Chat UI and we discussed about how they packaged it as a snap.

If you missed it, click the image below to watch it.

Alt text

Building from what we saw on the first session, we tested the snap using a virtual machine again. But this time, we cloned it to keep a pristine machine and make following testing sessions faster. If you want to help the Ubuntu and Rocket Chat communities, this is an easy way to prepare your environment:

Once you have your clone ready, install the most recent and bleeding edge version of rocket chat with:

$ sudo snap install rocketchat-server --edge

Then you can follow this gist with the initial steps to start testing the Rocket Chat snap

Also you can test a real installation of Rocket Chat, joining our community channel, where we are available all day, every day. If you have a question, just ask. I am elopio in there.

During the session we took a look at the GitHub website, where many free software communities do their development in the open. They have a great guide to start contributing to open source projects. Go on and spread your love for free software in the form of bug reports :)

The gratitude this week goes to our newly acquired staff members Julia and Kyle, and of course to Aaron for letting us have a funny Friday evening. Make sure to take a look at the cool things he and his teammates are doing; and if you have some free time and want to join an exciting, open and nice community, give them a hand. Also try the Jitsi integration for video conference, it's mind-blowing that there are no closed components anywhere.

See you next Friday at Ubuntu On-Air.