07 Dec 2016

feedPlanet Ubuntu

Ubuntu Insights: Jamming with Ubuntu Core

web-banner

We celebrated the launch of Ubuntu Core 16 hackathon, or shall we say Snapathon, that took place in Shenzhen between 26-27th November. The 30+ hour gathering and coding session was attended by developers, makers and anyone that was interested in the Internet of Things and the technology that powers them. Attendees were from different backgrounds, industries and places, but demonstrated the same passion and interest to learn about Ubuntu Core and be part of the evolution of the Internet of Things.

From smart homes to drones, robots and industrial systems, Ubuntu Core provides robust security, app stores and reliable updates. Ubuntu makes development easy…and snap packages make Ubuntu Core secure and reliable for widely distributed devices. This hackathon demonstrated how easy it is to package a snap and work with Ubuntu Core.

We kicked-off with a tech talk on Ubuntu core and then the hacking session took-place…

1、snap: water-iot-service: by Jarvis Chung and Lucas Lu

This project is an application that can help monitor and test water quality and status under different environments, especially when it is difficult or dangerous for direct human access. It utilizes RaspberryPi 3 and a few sensors to gather information data, which will be remotely sent to Qnap's NAS systems for data analysis. Result can be accessed through a web interface.

The team who worked on this project were from QNAP System. More information on QNAP and their solutions can be found here.

qnap

2、Project Cooltools, snap: sensor-gw: by Hao jianlin

This project used TI sensor tag to collect the location's light condition, and accordingly the snap application can auto adjusts smart bulb's lighting to achieve an optimized lighting ambience. The project is powered by Ubuntu Core and running on a QualComm dragonboard. A useful addition to your smart home solution!

The team behind this project is from Shenzhen CoolTools, a startup company focusing on developing smart IoT solutions and applications.

img_0405

3、snap: crazy-app by Crazyou

Crazy-app was developed by Crazyou, a startup robotics company based in Shenzhen. Their crazy-app snap application provides remote monitoring, remote control and admin ability for their robots….as well as remote access to their robot's webcam to capture surrounding images! More information about Crazyou and their robots can be find here.

img_0428

4、snap: Simcaffe by Lao Liang

Running on QualComm DragonBoard 410c, the project is powered by Ubuntu core and comes with an AI developed by using Caffe deep learning framework which can be trained to recognize different images. The project was designed to be utilized in smart surveillance systems. The project code is available on Github.

img_0440

5、snap: Sutop by team PCBA

Sutop is a simple yet handy system admin tool which can monitor and manage your device system remotely.

img_0427

6、My wardrobe by Li Jiancheng

Powered by ubuntu core, and running on Rasberry Pi - it's a simple snap that can store all your clothes images and help to organize all of them to provide matching options when you need some help with getting stylish.

img_0414

7、Project Cellboot by Shen Jianfeng

It is a cluster snap that can utilize all connected ubuntu core devices to performance cluster data computing and analysis tasks.

img_0389

Besides the above projects there were a couple more developed during the hackathon, however with time limitation, they didn't come to life for demo stage - though at some point we're looking forward to seeing them soon in the store!

It was indeed a long night in Shenzhen but the amount of ideas and innovation that came out of it was amazing. Until next time…. !

img_0469

07 Dec 2016 4:42pm GMT

Dustin Kirkland: A Touch of Class at Sir Ludovic, Bucharest, Romania

A few weeks ago, I traveled to Bucharest, Romania for a busy week of work, planning the Ubuntu 17.04 (Zesty) cycle.

I did have a Saturday and Sunday to myself, which I spent mostly walking around the beautiful, old city. After visiting the Romanian Athenaeum, I quite randomly stumbled into one truly unique experience. I passed a window shop for "Sir Ludovic Master Suit Maker" which somehow caught my eye.



I travel quite a bit on business, and you'll typically find me wearing a casual sports coat, a button up shirt, nice jeans, cowboy boots, and sometimes cuff links. But occasionally, I feel a little under-dressed, especially in New York City, where a dashing suit still rules the room.

Frankly, everything I know about style and fashion I learned from Derek Zoolander. Just kidding. Mostly.

Anyway, I owned two suits. One that I bought in 2004, for that post-college streak of weddings, and a seersucker suit (which is dandy in New Orleans and Austin, but a bit irreverent for serious client meetings on Wall Street).

So I stepped into Sir Ludovic, merely as a curiosity, and walked out with the most rewarding experience of my week in Romania. Augustin Ladar, the master tailor and proprietor of the shop, greeted me at the door. We then spent the better part of 3 hours, selecting every detail, from the fabrics, to the buttons, to the stylistic differences in the cut and the fit.





Better yet, I absorbed a wealth of knowledge on style and fashion: when to wear blue and when to wear grey, why some people wear pin stripes and others wear checks, authoritative versus friendly style, European versus American versus Asian cuts, what the heck herringbone is, how to tell if the other guy is also wearing hand tailored attire, and so on...

Augustin measured me for two custom tailored suits and two bespoke shirts, on a Saturday. I picked them up 6 days later on a Friday afternoon (paying a rush service fee).

Wow. Simply, wow. Splendid Italian wool fabric, superb buttons, eye-catching color shifting inner linings, and an impeccably precise fit.









I'm headed to New York for my third trip since, and I've never felt more comfortable and confident in these graceful, classy suits. A belated thanks to Augustin. Fabulous work!



Cheers,
Dustin

07 Dec 2016 4:00pm GMT

Stphane Graber: Running snaps in LXD containers

LXD logo

Introduction

The LXD and AppArmor teams have been working to support loading AppArmor policies inside LXD containers for a while. This support which finally landed in the latest Ubuntu kernels now makes it possible to install snap packages.

Snap packages are a new way of distributing software, directly from the upstream and with a number of security features wrapped around them so that these packages can't interfere with each other or cause harm to your system.

Requirements

There are a lot of moving pieces to get all of this working. The initial enablement was done on Ubuntu 16.10 with Ubuntu 16.10 containers, but all the needed bits are now progressively being pushed as updates to Ubuntu 16.04 LTS.

The easiest way to get this to work is with:

Installing the nextcloud snap

First, lets get ourselves an Ubuntu 16.10 container with "squashfuse" installed inside it.

lxc launch ubuntu:16.10 nextcloud
lxc exec nextcloud -- apt update
lxc exec nextcloud -- apt dist-upgrade -y
lxc exec nextcloud -- apt install squashfuse -y

And then, lets install that "nextcloud" snap with:

lxc exec nextcloud -- snap install nextcloud

Finally, grab the container's IP and access "http://<IP>" with your web browser:

stgraber@castiana:~$ lxc list nextcloud
+-----------+---------+----------------------+----------------------------------------------+
|    NAME   |  STATE  |         IPV4         |                     IPV6                     |
+-----------+---------+----------------------+----------------------------------------------+
| nextcloud | RUNNING | 10.148.195.47 (eth0) | fd42:ee2:5d34:25c6:216:3eff:fe86:4a49 (eth0) |
+-----------+---------+----------------------+----------------------------------------------+

Nextcloud Login screen

Installing the LXD snap in a LXD container

First, lets get ourselves an Ubuntu 16.10 container with "squashfuse" installed inside it.
This time with support for nested containers.

lxc launch ubuntu:16.10 lxd -c security.nesting=true
lxc exec lxd -- apt update
lxc exec lxd -- apt dist-upgrade -y
lxc exec lxd -- apt install squashfuse -y

Now lets clear the LXD that came pre-installed with the container so we can replace it by the snap.

lxc exec lxd -- apt remove --purge lxd lxd-client -y

Because we already have a stable LXD on the host, we'll make things a bit more interesting by installing the latest build from git master rather than the latest stable release:

lxc exec lxd -- snap install lxd --edge

The rest is business as usual for a LXD user:

stgraber@castiana:~$ lxc exec lxd bash
root@lxd:~# lxd init
Name of the storage backend to use (dir or zfs) [default=dir]:

We detected that you are running inside an unprivileged container.
This means that unless you manually configured your host otherwise,
you will not have enough uid and gid to allocate to your containers.

LXD can re-use your container's own allocation to avoid the problem.
Doing so makes your nested containers slightly less safe as they could
in theory attack their parent container and gain more privileges than
they otherwise would.

Would you like to have your containers share their parent's allocation (yes/no) [default=yes]?
Would you like LXD to be available over the network (yes/no) [default=no]?
Would you like stale cached images to be updated automatically (yes/no) [default=yes]?
Would you like to create a new network bridge (yes/no) [default=yes]?
What should the new bridge be called [default=lxdbr0]?
What IPv4 subnet should be used (CIDR notation, "auto" or "none") [default=auto]?
What IPv6 subnet should be used (CIDR notation, "auto" or "none") [default=auto]?
LXD has been successfully configured.

root@lxd:~# lxd.lxc launch images:archlinux arch
If this is your first time using LXD, you should also run: sudo lxd init
To start your first container, try: lxc launch ubuntu:16.04

Creating arch
Starting arch

root@lxd:~# lxd.lxc list
+------+---------+----------------------+-----------------------------------------------+------------+-----------+
| NAME |  STATE  |         IPV4         |                      IPV6                     |    TYPE    | SNAPSHOTS |
+------+---------+----------------------+-----------------------------------------------+------------+-----------+
| arch | RUNNING | 10.106.137.64 (eth0) | fd42:2fcd:964b:eba8:216:3eff:fe8f:49ab (eth0) | PERSISTENT | 0         |
+------+---------+----------------------+-----------------------------------------------+------------+-----------+

And that's it, you now have the latest LXD build installed inside a LXD container and running an archlinux container for you. That LXD build will update very frequently as we publish new builds to the edge channel several times a day.

Conclusion

It's great to have snaps now install properly inside LXD containers. Production users can now setup hundreds of different containers, network them the way they want, setup their storage and resource limits through LXD and then install snap packages inside them to get the latest upstream releases of the software they want to run.

That's not to say that everything is perfect yet. This is all built on some really recent kernel work, using unprivileged FUSE filesystem mounts and unprivileged AppArmor profile stacking and namespacing. There very likely still are some issues that need to get resolved in order to get most snaps to work identically to when they're installed directly on the host.

If you notice discrepancies between a snap running directly on the host and a snap running inside a LXD container, you'll want to look at the "dmesg" output, looking for any DENIED entry in there which would indicate AppArmor rejecting some request from the snap.

This typically indicates either a bug in AppArmor itself or in the way the AppArmor profiles are generated by snapd. If you find one of those issues, you can report it in #snappy on irc.freenode.net or file a bug at https://launchpad.net/snappy/+filebug so it can be investigated.

Extra information

More information on snap packages can be found at: http://snapcraft.io

The main LXD website is at: https://linuxcontainers.org/lxd
Development happens on Github at: https://github.com/lxc/lxd
Mailing-list support happens on: https://lists.linuxcontainers.org
IRC support happens in: #lxcontainers on irc.freenode.net
Try LXD online: https://linuxcontainers.org/lxd/try-it

07 Dec 2016 2:37pm GMT

Ubuntu Insights: LXD 2.0: LXD and OpenStack [11/12]

This is the eleventh blog post in this series about LXD 2.0.

LXD logo

Introduction

First of all, sorry for the delay. It took quite a long time before I finally managed to get all of this going. My first attempts were using devstack which ran into a number of issues that had to be resolved. Yet even after all that, I still wasn't be able to get networking going properly.

I finally gave up on devstack and tried "conjure-up" to deploy a full Ubuntu OpenStack using Juju in a pretty user friendly way. And it finally worked!

So below is how to run a full OpenStack, using LXD containers instead of VMs and running all of this inside a LXD container (nesting!).

Requirements

This post assumes you've got a working LXD setup, providing containers with network access and that you have a pretty beefy CPU, around 50GB of space for the container to use and at least 16GB of RAM.

Remember, we're running a full OpenStack here, this thing isn't exactly light!

Setting up the container

OpenStack is made of a lof of different components, doing a lot of different things. Some require some additional privileges so to make our live easier, we'll use a privileged container.

We'll configure that container to support nesting, pre-load all the required kernel modules and allow it access to /dev/mem (as is apparently needed).

Please note that this means that most of the security benefit of LXD containers are effectively disabled for that container. However the containers that will be spawned by OpenStack itself will be unprivileged and use all the normal LXD security features.

lxc launch ubuntu:16.04 openstack -c security.privileged=true -c security.nesting=true -c "linux.kernel_modules=iptable_nat, ip6table_nat, ebtables, openvswitch"
lxc config device add openstack mem unix-char path=/dev/mem

There is a small bug in LXD where it would attempt to load kernel modules that have already been loaded on the host. This has been fixed in LXD 2.5 and will be fixed in LXD 2.0.6 but until then, this can be worked around with:

lxc exec openstack - ln -s /bin/true /usr/local/bin/modprobe
Then we need to add a couple of PPAs and install conjure-up, the deployment tool we'll use to get OpenStack going.

lxc exec openstack -- apt-add-repository ppa:conjure-up/next -y
lxc exec openstack -- apt-add-repository ppa:juju/stable -y
lxc exec openstack -- apt update
lxc exec openstack -- apt dist-upgrade -y
lxc exec openstack -- apt install conjure-up -y

And the last setup step is to configure LXD networking inside the container.
Answer with the default for all questions, except for:

lxc exec openstack -- lxd init

And that's it for the container configuration itself, now we can deploy OpenStack!

Deploying OpenStack with conjure-up

As mentioned earlier, we'll be using conjure-up to deploy OpenStack.
This is a nice, user friendly, tool that interfaces with Juju to deploy complex services.

Start it with:

lxc exec openstack -- sudo -u ubuntu -i conjure-up

This will now deploy OpenStack. The whole process can take well over an hour depending on what kind of machine you're running this on. You'll see all services getting a container allocated, then getting deployed and finally interconnected.

conjure-up

Conjure-Up deploying OpenStack

Once the deployment is done, a few post-install steps will appear. This will import some initial images, setup SSH authentication, configure networking and finally giving you the IP address of the dashboard.

Access the dashboard and spawn a container

The dashboard runs inside a container, so you can't just hit it from your web browser.

The easiest way around this is to setup a NAT rule with:

lxc exec openstack -- iptables -t nat -A PREROUTING -p tcp --dport 80 -j --to <IP>

Where "<ip>" is the dashboard IP address conjure-up gave you at the end of the installation.

You can now grab the IP address of the "openstack" container (from "lxc info openstack") and point your web browser to: http://<container ip>/horizon

This can take a few minutes to load the first time around. Once the login screen is loaded, enter the default login and password (admin/openstack) and you'll be greeted by the OpenStack dashboard!

oslxd-dashboard

You can now head to the "Project" tab on the left and the "Instances" page. To start a new instance using nova-lxd, click on "Launch instance", select what image you want, network, … and your instance will get spawned.

Once it's running, you can assign it a floating IP which will let you reach your instance from within your "openstack" container.

Conclusion

OpenStack is a pretty complex piece of software, it's also not something you really want to run at home or on a single server. But it's certainly interesting to be able to do it anyway, keeping everything contained to a single container on your machine.

Conjure-Up is a great tool to deploy such complex software, using Juju behind the scene to drive the deployment, using LXD containers for every individual service and finally for the instances themselves.

It's also one of the very few cases where multiple level of container nesting actually makes sense!

Extra information

The conjure-up website can be found at: http://conjure-up.io
The Juju website can be found at: http://www.ubuntu.com/cloud/juju

The main LXD website is at: https://linuxcontainers.org/lxd
Development happens on Github at: https://github.com/lxc/lxd
Mailing-list support happens on: https://lists.linuxcontainers.org
IRC support happens in: #lxcontainers on irc.freenode.net
Try LXD online: https://linuxcontainers.org/lxd/try-it

Original article

<-- Previous blog

07 Dec 2016 10:00am GMT

06 Dec 2016

feedPlanet Ubuntu

The Fridge: Ubuntu Weekly Newsletter Issue 490

Welcome to the Ubuntu Weekly Newsletter. This is issue #490 for the week November 28 - December 4, 2016, and the full version is available here.

In this issue we cover:

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

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

06 Dec 2016 4:17am GMT

05 Dec 2016

feedPlanet Ubuntu

Seif Lotfy: Playing with .NET (dotnet) and IronFunctions

Again if you missed it, IronFunctions is open-source, lambda compatible, on-premise, language agnostic, server-less compute service.

While AWS Lambda only supports Java, Python and Node.js, Iron Functions allows you to use any language you desire by running your code in containers.

With Microsoft being one of the biggest players in open source and .NET going cross-platform it was only right to add support for it in the IronFunctions's fn tool.

TL;DR:

The following demos a .NET function that takes in a URL for an image and generates a MD5 checksum hash for it:

Using dotnet with functions

Make sure you downloaded and installed dotnet. Now create an empty dotnet project in the directory of your function:

dotnet new  

By default dotnet creates a Program.cs file with a main method. To make it work with IronFunction's fn tool please rename it to func.cs.

mv Program.cs func.cs  

Now change the code as you desire to do whatever magic you need it to do. In our case the code takes in a URL for an image and generates a MD5 checksum hash for it. The code is the following:

using System;  
using System.Text;  
using System.Security.Cryptography;  
using System.IO;

namespace ConsoleApplication  
{
    public class Program
    {
        public static void Main(string[] args)
        {
            // if nothing is being piped in, then exit
            if (!IsPipedInput())
                return;

            var input = Console.In.ReadToEnd();
            var stream = DownloadRemoteImageFile(input);
            var hash = CreateChecksum(stream);
            Console.WriteLine(hash);
        }

        private static bool IsPipedInput()
        {
            try
            {
                bool isKey = Console.KeyAvailable;
                return false;
            }
            catch
            {
                return true;
            }
        }
        private static byte[] DownloadRemoteImageFile(string uri)
        {

            var request = System.Net.WebRequest.CreateHttp(uri);
            var response = request.GetResponseAsync().Result;
            var stream = response.GetResponseStream();
            using (MemoryStream ms = new MemoryStream())
            {
                stream.CopyTo(ms);
                return ms.ToArray();
            }
        }
        private static string CreateChecksum(byte[] stream)
        {
            using (var md5 = MD5.Create())
            {
                var hash = md5.ComputeHash(stream);
                var sBuilder = new StringBuilder();

                // Loop through each byte of the hashed data
                // and format each one as a hexadecimal string.
                for (int i = 0; i < hash.Length; i++)
                {
                    sBuilder.Append(hash[i].ToString("x2"));
                }

                // Return the hexadecimal string.
                return sBuilder.ToString();
            }
        }
    }
}

Note: IO with an IronFunction is done via stdin and stdout. This code

Using with IronFunctions

Let's first init our code to become IronFunctions deployable:

fn init <username>/<funcname>  

Since IronFunctions relies on Docker to work (we will add rkt support soon) the <username> is required to publish to docker hub. The <funcname> is the identifier of the function.

In our case we will use dotnethash as the <funcname>, so the command will look like:

fn init seiflotfy/dotnethash  

When running the command it will create the func.yaml file required by functions, which can be built by running:

Push to docker

fn push  

This will create a docker image and push the image to docker.

Publishing to IronFunctions

To publish to IronFunctions run ...

fn routes create <app_name>  

where <app_name> is (no surprise here) the name of the app, which can encompass many functions.

This creates a full path in the form of http://<host>:<port>/r/<app_name>/<function>

In my case, I will call the app myapp:

fn routes create myapp  

Calling

Now you can

fn call <app_name> <funcname>  

or

curl http://<host>:<port>/r/<app_name>/<function>  

So in my case

echo http://lorempixel.com/1920/1920/ | fn call myapp /dotnethash  

or

curl -X POST -d 'http://lorempixel.com/1920/1920/'  http://localhost:8080/r/myapp/dotnethash  

What now?

You can find the whole code in the examples on GitHub. Feel free to join the Iron.io Team on Slack.
Feel free to write your own examples in any of your favourite programming languages such as Lua or Elixir and create a PR :)

05 Dec 2016 10:15pm GMT

Harald Sitter: KDE Framworks 5 Content Snap Techno

In the previous post on Snapping KDE Applications we looked at the high-level implication and use of the KDE Frameworks 5 content snap to snapcraft snap bundles for binary distribution. Today I want to get a bit more technical and look at the actual building and inner workings of the content snap itself.

The KDE Frameworks 5 snap is a content snap. Content snaps are really just ordinary snaps that define a content interface. Namely, they expose part or all of their file tree for use by another snap but otherwise can be regular snaps and have their own applications etc.

KDE Frameworks 5's snap is special in terms of size and scope. The whole set of KDE Frameworks 5, combined with Qt 5, combined with a large chunk of the graphic stack that is not part of the ubuntu-core snap. All in all just for the Qt5 and KF5 parts we are talking about close to 100 distinct source tarballs that need building to compose the full frameworks stack. KDE is in the fortunate position of already having builds of all these available through KDE neon. This allows us to simply repack existing work into the content snap. This is for the most part just as good as doing everything from scratch, but has the advantage of saving both maintenance effort and build resources.

I do love automation, so the content snap is built by some rather stringy proof of concept code that automatically translates the needed sources into a working snapcraft.yaml that repacks the relevant KDE neon debs into the content snap.

Looking at this snapcraft.yaml we'll find some fancy stuff.

After the regular snap attributes the actual content-interface is defined. It's fairly straight forward and simply exposes the entire snap tree as kde-frameworks-5-all content. This is then used on the application snap side to find a suitable content snap so it can access the exposed content (i.e. in our case the entire file tree).

slots:
    kde-frameworks-5-slot:
        content: kde-frameworks-5-all
        interface: content
        read:
        - "."

The parts of the snap itself are where the most interesting things happen. To make things easier to read and follow I'll only show the relevant excerpts.

The content snap consists of the following parts: kf5, kf5-dev, breeze, plasma-integration.

The kf5 part is the meat of the snap. It tells snapcraft to stage the binary runtime packages of KDE Frameworks 5 and Qt 5. This effectively makes snapcraft pack the named debs along with necessary dependencies into our snap.

    kf5:
        plugin: nil
        stage-packages:
          - libkf5coreaddons5
        ...

The kf5-dev part looks almost like the kf5 part but has entirely different functionality. Instead of staging the runtime packages it stages the buildtime packages (i.e. the -dev packages). It additionally has a tricky snap rule which excludes everything from actually ending up in the snap. This is a very cool tricky, this effectively means that the buildtime packages will be in the stage and we can build other parts against them, but we won't have any of them end up in the final snap. After all, they would be entirely useless there.

    kf5-dev:
        after:
          - kf5
        plugin: nil
        stage-packages:
          - libkf5coreaddons-dev
        ....
        snap:
          - "-*"

Besides those two we also build two runtime integration parts entirely from scratch breeze and plasma-integration. They aren't actually needed, but ensure sane functionality in terms of icon theme selection etc. These are ordinary build parts that simply rely on the kf5 and kf5-dev parts to provide the necessary dependencies.

An important question to ask here is how one is meant to build against this now. There is this kf5-dev part, but it does not end up in the final snap where it would be entirely useless anyway as snaps are not used at buildtime. The answer lies in one of the rigging scripts around this. In the snapcraft.yaml we configured the kf5-dev part to stage packages but then excluded everything from being snapped. However, knowing how snapcraft actually goes about its business we can "abuse" its inner workings to make use of the part after all. Before the actual snap is created snapcraft "primes" the snap, this effectively means that all installed trees (i.e. the stages) are combined into one tree (i.e. the primed tree), the exclusion rule of the kf5-dev part is then applied on this tree. Or in other words: the primed tree is the snap before exclusion was applied. Meaning the primed tree is everything from all parts, including the development headers and CMake configs. We pack this tree in a development tarball which we then use on the application side to stage a development environment for the KDE Frameworks 5 snap.

Specifically on the application-side we use a boilerplate part that employs the same trick of stage-everything but snap-nothing to provide the build dependencies while not having anything end up in the final snap.

  kde-frameworks-5-dev:
    plugin: dump
    snap: [-*]
    source: http://build.neon.kde.org/job/kde-frameworks-5-release_amd64.snap/lastSuccessfulBuild/artifact/kde-frameworks-5-dev_amd64.tar.xz

Using the KDE Framworks 5 content snap KDE can create application snaps that are a fraction of the size they would be if they contained all dependencies themselves. While this does give up optimization potential by aggregating requirements in a more central fashion it quickly starts paying off given we are saving upwards of 70 MiB per snap.

Application snaps can of course still add more stuff on top or even override things if needed.

Finally, as we approach the end of the year, we begin the season of giving. What would suit the holidays better than giving to the entire world by supporting KDE with a small donation?
postcard02

05 Dec 2016 4:10pm GMT

Rafael Carreras: Yakkety Yak release parties

Catalan LoCo Team celebrated on November 5th a release party of the next Ubuntu version, in that case, 16.10 Xenial Xerus, in Ripoll, such a historical place. As always, we started explaining what Ubuntu is and how it adapts to new times and devices.

FreeCad 3D design and Games were both present at the party.

A few weeks later, in December 3rd, we did another release party, this time in Barcelona.

We went to Soko, previously a chocolate factory, that nowadays is a kind of Makers Lab, very excited about free software. First, Josep explained the current developments in Ubuntu and we carried some installations on laptops.

We ate some pizza and had discussions about free software on public administrations. Apart from the usual users who came to install Ubuntu on their computers, the responsible from Soko gave us 10 laptops for Ubuntu installation too. We ended the tasks installing Wine for some Lego to run.

That's some art that is being made at Soko.

I'm releasing that post because we need some documentation on release parties. If you need some advice on how to manage a release party, you can contact me or anyone in Ubuntu community.

05 Dec 2016 1:44pm GMT

04 Dec 2016

feedPlanet Ubuntu

Svetlana Belkin: Community Service Learning Within Open * Communities

As the name implies, "service-learning is an educational approach that combines learning objectives with community service in order to provide a pragmatic, progressive learning experience while meeting societal needs" (Wikipedia). When you add the "community" part to that definition it changes to, "about leadership development as well as traditional information and skill acquisition" (Janet 1999).

How does this apply to Open * communities?

Simple! Community service learning is an ideal way to get middle/high school/college students to get involved within the various communities and understand the power of Open *. And also to stay active after their term of community service learning.

This idea came to me just today (as of writing, Nov. 30th) as a thought on what is really Open *. Not the straightforward definition of it but the the affect Open * creates. As I stated on my home page of my site, Open * creates a sense of empowerment. One way is through the actions that create skills and improvements to those skills. Which skills are those? Mozilla Learning made a map and description to these skills on their Web Literacy pages. They are show below also:

screenshot-from-2016-11-30-19-07-22Most of these skills along with the ways to gain these skills (read, write, participate) can be used as skills to worked on for community service learning.

As stated above, community service learning is really the focus of gaining skills and leadership skills while (in the Open * sense) contribute to projects that impacts the society of the world. This is really needed now as there are many local and world issues that Open * can provide solutions too.

I see this as an outreach program for schools and the various organizations/groups such as Ubuntu, System76, Mozilla, and even Linux Padawan. Unlike Google Summer of Code (GSoC), no one receives a stipend but the idea of having a mentor could be taken from GSoC. No, not could but should. Because the student needs someone to guide them, hence Linux Padawan could benefit from this idea.

Having that said, I will try to work out a sample program that could be used and maybe test it with Linux Padawan. Maybe I could have this ready by spring semester.

Random Fact #1: Simon Quigley, through his middle school, is in a way already doing this type of learning.

Random Fact #2: At one point of time, I wanted to translate that Web Literacy map into one that can be applied to Open *, not just one topic.

04 Dec 2016 9:35pm GMT

Jo Shields: A quick introduction to Flatpak

Releasing ISV applications on Linux is often hard. The ABI of all the libraries you need changes seemingly weekly. Hence you have the option of bundling the world, or building a thousand releases to cover a thousand distribution versions. As a case in point, when MonoDevelop started bundling a C Git library instead of using a C# git implementation, it gained dependencies on all sorts of fairly weak ABI libraries whose exact ABI mix was not consistent across any given pair of distro releases. This broke our policy of releasing "works on anything" .deb and .rpm packages. As a result, I pretty much gave up on packaging MonoDevelop upstream with version 5.10.

Around the 6.1 release window, I decided to take re-evaluate question. I took a closer look at some of the fancy-pants new distribution methods that get a lot of coverage in the Linux press: Snap, AppImage, and Flatpak.

I started with AppImage. It's very good and appealing for its specialist areas (no external requirements for end users), but it's kinda useless at solving some of our big areas (the ABI-vs-bundling problem, updating in general).

Next, I looked at Flatpak (once xdg-app). I liked the concept a whole lot. There's a simple 3-tier dependency hierarchy: Applications, Runtimes, and Extensions. An application depends on exactly one runtime. Runtimes are root-level images with no dependencies of their own. Extensions are optional add-ons for applications. Anything not provided in your target runtime, you bundle. And an integrated updates mechanism allows for multiple branches and multiple releases parallel-installed (e.g. alpha & stable, easily switched).

There's also security-related sandboxing features, but my main concerns on a first examination were with the dependency and distribution questions. That said, some users might be happier running Microsoft software on their Linux desktop if that software is locked up inside a sandbox, so I've decided to embrace that functionality rather than seek to avoid it.

I basically stopped looking at this point (sorry Snap!). Flatpak provided me with all the functionality I wanted, with an extremely helpful and responsive upstream. I got to work on trying to package up MonoDevelop.

Flatpak (optionally!) uses a JSON manifest for building stuff. Because Mono is still largely stuck in a Gtk+2 world, I opted for the simplest runtime, org.freedesktop.Runtime, and bundled stuff like Gtk+ into the application itself.

Some gentle patching here & there resulted in this repository. Every time I came up with an exciting new edge case, upstream would suggest a workaround within hours - or failing that, added new features to Flatpak just to support my needs (e.g. allowing /dev/kvm to optionally pass through the sandbox).

The end result is, as of the upcoming 0.8.0 release of Flatpak, from a clean install of the flatpak package to having a working MonoDevelop is a single command: flatpak install --user --from https://download.mono-project.com/repo/monodevelop.flatpakref

For the current 0.6.x versions of Flatpak, the user also needs to flatpak remote-add --user --from gnome https://sdk.gnome.org/gnome.flatpakrepo first - this step will be automated in 0.8.0. This will download org.freedesktop.Runtime, then com.xamarin.MonoDevelop; export icons 'n' stuff into your user environment so you can just click to start.

There's some lingering experience issues due the sandbox which are on my radar. "Run on external console" doesn't work, for example, or "open containing folder". There are people working on that (a missing DBus# feature to allow breaking out of the sandbox). But overall, I'm pretty happy. I won't be entirely satisfied until I have something approximating feature equivalence to the old .debs. I don't think that will ever quite be there, since there's just no rational way to allow arbitrary /usr stuff into the sandbox, but it should provide a decent basis for a QA-able, supportable Linux MonoDevelop. And we can use this work as a starting point for any further fancy features on Linux.

Gtk# app development in Flatpak MonoDevelop

Editing MonoDevelop in MonoDevelop. *Inception noise*

04 Dec 2016 10:44am GMT

03 Dec 2016

feedPlanet Ubuntu

Ross Gammon: My Open Source Contributions June – November 2016

So much for my monthly blogging! Here's what I have been up to in the Open Source world over the last 6 months.

Debian

Ubuntu

Other

Plan for December

Debian

Before the 5th January 2017 Debian Stretch soft freeze I hope to:

Ubuntu

Other


03 Dec 2016 11:52am GMT

02 Dec 2016

feedPlanet Ubuntu

Timo Aaltonen: Mesa 12.0.4 backport available for testing

Hi!

I've uploaded Mesa 12.0.4 for xenial and yakkety to my testing PPA for you to try out. 16.04 shipped with 11.2.0 so it's a slightly bigger update there, while yakkety is already on 12.0.3 but the new version should give radeon users a 15% performance boost in certain games with complex shaders.

Please give it a spin and report to the (yakkety) SRU bug if it works or not, and mention the GPU you tested with. At least Intel Skylake seems to still work fine here.


02 Dec 2016 10:28pm GMT

Costales: Fairphone 2 & Ubuntu

En la Ubucon Europe pude conocer de primera mano los avances de Ubuntu Touch en el Fairphone 2.

Ubuntu Touch & Fairphone 2

El Fairphone 2 es un móvil único. Como su propio nombre indica, es un móvil ético con el mundo. No usa mano de obra infantil, construido con minerales por los que no corrió la sangre y que incluso se preocupa por los residuos que genera.

Delantera y trasera

En el apartado de software ejecuta varios sistemas operativos, y por fin, Ubuntu es uno de ellos.


Tu elección

El port de Ubuntu está implementado por el proyecto UBPorts, que está avanzando a pasos de gigante cada semana.

Cuando yo probé el móvil, me sorprendió la velocidad de Unity, similar a la de mi BQ E4.5.
La cámara es suficientemente buena. Y la duración de la batería es aceptable.
Me encantó especialmente la calidad de la pantalla, con sólo mirarla se nota su nitidez.
Respecto a las aplicaciones, probé varias de la Store sin problema.

Carcasa

En resumen, un gran sistema operativo, para un gran móvil :) Un win:win

Si te interesa colaborar como desarrollador de este port, te recomiendo este grupo de Telegram: https://telegram.me/joinchat/AI_ukwlaB6KCsteHcXD0jw

All images are CC BY-SA 2.0.

02 Dec 2016 5:54pm GMT

Harald Sitter: Snapping KDE Applications

This is largely based on a presentation I gave a couple of weeks ago. If you are too lazy to read, go watch it instead😉

For 20 years KDE has been building free software for the world. As part of this endeavor, we created a collection of libraries to assist in high-quality C++ software development as well as building highly integrated graphic applications on any operating system. We call them the KDE Frameworks.

With the recent advance of software bundling systems such as Snapcraft and Flatpak, KDE software maintainers are however a bit on the spot. As our software is building on such a vast collection of frameworks and supporting technology, the individual size of a distributable application can be quite abysmal.

When we tried to package our calculator KCalc as a snap bundle, we found that even a relatively simple application like this, makes for a good 70 MiB snap to be in a working state (most of this is the graphical stack required by our underlying C++ framework, Qt).
Since then a lot of effort was put into devising a system that would allow us to more efficiently deal with this. We now have a reasonably suitable solution on the table.

The KDE Frameworks 5 content snap.

A content snap is a special bundle meant to be mounted into other bundles for the purpose of sharing its content. This allows us to share a common core of libraries and other content across all applications, making the individual applications just as big as they need to be. KCalc is only 312 KiB without translations.

The best thing is that beside some boilerplate definitions, the snapcraft.yaml file defining how to snap the application is like a regular snapcraft file.

Let's look at how this works by example of KAlgebra, a calculator and mathematical function plotter:

Any snapcraft.yaml has some global attributes we'll want to set for the snap

name: kalgebra
version: 16.08.2
summary: ((TBD))
description: ((TBD))
confinement: strict
grade: devel

We'll want to define an application as well. This essentially allows snapd to expose and invoke our application properly. For the purpose of content sharing we will use a special start wrapper called kf5-launch that allows us to use the content shared Qt and KDE Frameworks. Except for the actual application/binary name this is fairly boilerplate stuff you can use for pretty much all KDE applications.

apps:
  kalgebra:
    command: kf5-launch kalgebra
    plugs:
      - kde-frameworks-5-plug # content share itself
      - home # give us a dir in the user home
      - x11 # we run with xcb Qt platform for now
      - opengl # Qt/QML uses opengl
      - network # gethotnewstuff needs network IO
      - network-bind # gethotnewstuff needs network IO
      - unity7 # notifications
      - pulseaudio # sound notifications

To access the KDE Frameworks 5 content share we'll then want to define a plug our application can use to access the content. This is always the same for all applications.

plugs:
  kde-frameworks-5-plug:
    interface: content
    content: kde-frameworks-5-all
    default-provider: kde-frameworks-5
    target: kf5

Once we got all that out of the way we can move on to actually defining the parts that make up our snap. For the most part parts are build instructions for the application and its dependencies. With content shares there are two boilerplate parts you want to define.

The development tarball is essentially a fully built kde frameworks tree including development headers and cmake configs. The tarball is packed by the same tech that builds the actual content share, so this allows you to build against the correct versions of the latest share.

  kde-frameworks-5-dev:
    plugin: dump
    snap: [-*]
    source: http://build.neon.kde.org/job/kde-frameworks-5-release_amd64.snap/lastSuccessfulBuild/artifact/kde-frameworks-5-dev_amd64.tar.xz

The environment rigging provide the kf5-launch script we previously saw in the application's definition, we'll use it to execute the application within a suitable environment. It also gives us the directory for the content share mount point.

  kde-frameworks-5-env:
    plugin: dump
    snap: [kf5-launch, kf5]
    source: http://github.com/apachelogger/kf5-snap-env.git

Lastly, we'll need the actual application part, which simply instructs that it will need the dev part to be staged first and then builds the tarball with boilerplate cmake config flags.

  kalgebra:
    after: [kde-frameworks-5-dev]
    plugin: cmake
    source: http://download.kde.org/stable/applications/16.08.2/src/kalgebra-16.08.2.tar.xz
    configflags:
      - "-DKDE_INSTALL_USE_QT_SYS_PATHS=ON"
      - "-DCMAKE_INSTALL_PREFIX=/usr"
      - "-DCMAKE_BUILD_TYPE=Release"
      - "-DENABLE_TESTING=OFF"
      - "-DBUILD_TESTING=OFF"
      - "-DKDE_SKIP_TEST_SETTINGS=ON"

Putting it all together we get a fairly standard snapcraft.yaml with some additional boilerplate definitions to wire it up with the content share. Please note that the content share is using KDE neon's Qt and KDE Frameworks builds, so, if you want to try this and need additional build-packages or stage-packages to build a part you'll want to make sure that KDE neon's User Edition archive is present in the build environments sources.list deb http://archive.neon.kde.org/user xenial main. This is going to get a more accessible centralized solution for all of KDE soon™.

name: kalgebra
version: 16.08.2
summary: ((TBD))
description: ((TBD))
confinement: strict
grade: devel

apps:
  kalgebra:
    command: kf5-launch kalgebra
    plugs:
      - kde-frameworks-5-plug # content share itself
      - home # give us a dir in the user home
      - x11 # we run with xcb Qt platform for now
      - opengl # Qt/QML uses opengl
      - network # gethotnewstuff needs network IO
      - network-bind # gethotnewstuff needs network IO
      - unity7 # notifications
      - pulseaudio # sound notifications

plugs:
  kde-frameworks-5-plug:
    interface: content
    content: kde-frameworks-5-all
    default-provider: kde-frameworks-5
    target: kf5

parts:
  kde-frameworks-5-dev:
    plugin: dump
    snap: [-*]
    source: http://build.neon.kde.org/job/kde-frameworks-5-release_amd64.snap/lastSuccessfulBuild/artifact/kde-frameworks-5-dev_amd64.tar.xz
  kde-frameworks-5-env:
    plugin: dump
    snap: [kf5-launch, kf5]
    source: http://github.com/apachelogger/kf5-snap-env.git
  kalgebra:
    after: [kde-frameworks-5-dev]
    plugin: cmake
    source: http://download.kde.org/stable/applications/16.08.2/src/kalgebra-16.08.2.tar.xz
    configflags:
      - "-DKDE_INSTALL_USE_QT_SYS_PATHS=ON"
      - "-DCMAKE_INSTALL_PREFIX=/usr"
      - "-DCMAKE_BUILD_TYPE=Release"
      - "-DENABLE_TESTING=OFF"
      - "-DBUILD_TESTING=OFF"
      - "-DKDE_SKIP_TEST_SETTINGS=ON"

Now to install this we'll need the content snap itself. Here is the content snap. To install it a command like sudo snap install --force-dangerous kde-frameworks-5_*_amd64.snap should get you going. Once that is done one can install the kalgebra snap. If you are a KDE developer and want to publish your snap on the store get in touch with me so we can get you set up.

The kde-frameworks-5 content snap is also available in the edge channel of the Ubuntu store. You can try the games kblocks and ktuberling like so:

sudo snap install --edge kde-frameworks-5
sudo snap install --edge --devmode kblocks
sudo snap install --edge --devmode ktuberling

If you want to be part of making the world a better place, or would like a KDE-themed postcard, please consider donating a penny or two to KDE

postcard04

02 Dec 2016 2:44pm GMT

Raphaël Hertzog: My Free Software Activities in November 2016

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donors (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it's one of the best ways to find volunteers to work with me on projects that matter to me.

Debian LTS

In the 11 hours of (paid) work I had to do, I managed to release DLA-716-1 aka tiff 4.0.2-6+deb7u8 fixing CVE-2016-9273, CVE-2016-9297 and CVE-2016-9532. It looks like this package is currently getting new CVE every month.

Then I spent quite some time to review all the entries in dla-needed.txt. I wanted to get rid of some misleading/no longer applicable comments and at the same time help Olaf who was doing LTS frontdesk work for the first time. I ended up tagging quite a few issues as no-dsa (meaning that we will do nothing for them as they are not serious enough) such as those affecting dwarfutils, dokuwiki, irssi. I dropped libass since the open CVE is disputed and was triaged as unimportant. While doing this, I fixed a bug in the bin/review-update-needed script that we use to identify entries that have not made any progress lately.

Then I claimed libgc and and released DLA-721-1 aka libgc 1:7.1-9.1+deb7u1 fixing CVE-2016-9427. The patch was large and had to be manually backported as it was not applying cleanly.

The last thing I did was to test a new imagemagick and review the update prepared by Roberto.

pkg-security work

The pkg-security team is continuing its good work: I sponsored patator to get rid of a useless dependency on pycryptopp which was going to be removed from testing due to #841581. After looking at that bug, it turns out the bug was fixed in libcrypto++ 5.6.4-3 and I thus closed it.

I sponsored many uploads: polenum, acccheck, sucrack (minor updates), bbqsql (new package imported from Kali). A bit later I fixed some issues in the bbsql package that had been rejected from NEW.

I managed a few RC bugs related to the openssl 1.1 transition: I adopted sslsniff in the team and fixed #828557 by build-depending on libssl1.0-dev after having opened the proper upstream ticket. I did the same for ncrack and #844303 (upstream ticket here). Someone else took care of samdump2 but I still adopted the package in the pkg-security team as it is a security relevant package. I also made an NMU for axel and #829452 (it's not pkg-security related but we still use it in Kali).

Misc Debian work

Django. I participated in the discussion about a change letting Django count the number of developers that use it. Such a change has privacy implications and the discussion sparked quite some interest both in Debian mailing lists and up to LWN.

On a more technical level, I uploaded version 1.8.16-1~bpo8+1 to jessie-backports (security release) and I fixed RC bug #844139 by backporting two upstream commits. This led to the 1.10.3-2 upload. I ensured that this was fixed in the 1.10.x upstream branch too.

dpkg and merged /usr. While reading debian-devel, I discovered dpkg bug #843073 that was threatening the merged-/usr feature. Since the bug was in code that I wrote a few years ago, and since Guillem was not interested in fixing it, I spent an hour to craft a relatively clean patch that Guillem could apply. Unfortunately, Guillem did not yet manage to pull out a new dpkg release with the patches applied. Hopefully it won't be too long until this happens.

Debian Live. I closed #844332 which was a request to remove live-build from Debian. While it was marked as orphaned, I was always keeping an eye on it and have been pushing small fixes to git. This time I decided to officially adopt the package within the debian-live team and work a bit more on it. I reviewed all pending patches in the BTS and pushed many changes to git. I still have some pending changes to finish to prettify the Grub menu but I plan to upload a new version really soon now.

Misc bugs filed. I filed two upstream tickets on uwsgi to help fix currently open RC bugs on the package. I filed #844583 on sbuild to support arbitrary version suffix for binary rebuild (binNMU). And I filed #845741 on xserver-xorg-video-qxl to get it fixed for the xorg 1.19 transition.

Zim. While trying to fix #834405 and update the required dependencies, I discovered that I had to update pygtkspellcheck first. Unfortunately, its package maintainer was MIA (missing in action) so I adopted it first as part of the python-modules team.

Distro Tracker. I fixed a small bug that resulted in an ugly traceback when we got queries with a non-ASCII HTTP_REFERER.

Thanks

See you next month for a new summary of my activities.

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

02 Dec 2016 11:45am GMT

01 Dec 2016

feedPlanet Ubuntu

Ubuntu Podcast from the UK LoCo: S09E40 – Dirty Dan’s Dark Delight - Ubuntu Podcast

It's Season Nine Episode Forty of the Ubuntu Podcast! Alan Pope, Mark Johnson, Martin Wimpress and Dan Kermac are connected and speaking to your brain.

The same line up as last week are here again for another episode.

In this week's show:

sudo apt install netdiscover
sudo netdiscover

The output looks something like this:

_____________________________________________________________________________
  IP            At MAC Address     Count     Len  MAC Vendor / Hostname
-----------------------------------------------------------------------------
192.168.2.2     fe:ed:de:ad:be:ef      1      42  Unknown vendor
192.168.2.1     da:d5:ba:be:fe:ed      1      60  TP-LINK TECHNOLOGIES CO.,LTD.
192.168.2.11    ba:da:55:c0:ff:ee      1      60  BROTHER INDUSTRIES, LTD.
192.168.2.30    02:02:de:ad:be:ef      1      60  Elitegroup Computer Systems Co., Ltd.
192.168.2.31    de:fa:ce:dc:af:e5      1      60  GIGA-BYTE TECHNOLOGY CO.,LTD.
192.168.2.107   da:be:ef:15:de:af      1      42  16)
192.168.2.109   b1:gb:00:bd:ba:be      1      60  Denon, Ltd.
192.168.2.127   da:be:ef:15:de:ad      1      60  ASUSTek COMPUTER INC.
192.168.2.128   ba:df:ee:d5:4f:cc      1      60  ASUSTek COMPUTER INC.
192.168.2.101   ba:be:4d:ec:ad:e5      1      42  Roku, Inc
192.168.2.106   ba:da:55:0f:f1:ce      1      42  LG Electronics
192.168.2.247   f3:3d:de:ad:be:ef      1      60  Roku, Inc
192.168.3.2     ba:da:55:c0:ff:33      1      60  Raspberry Pi Foundation
192.168.3.1     da:d5:ba:be:f3:3d      1      60  TP-LINK TECHNOLOGIES CO.,LTD.
192.168.2.103   da:be:ef:15:d3:ad      1      60  Unknown vendor
192.168.2.104   b1:gb:00:bd:ba:b3      1      42  Unknown vendor

That's all for this week! If there's a topic you'd like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to show@ubuntupodcast.org or Tweet us or Comment on our Facebook page or comment on our Google+ page or comment on our sub-Reddit.

01 Dec 2016 3:00pm GMT