Writing snaps together

Working with a new technology often brings you to see things in a new light and re-think previous habits. Especially when it challenges the status quo and expectations of years of traditional use. Snaps are no exception in this regard. As one example twenty years ago we simply didn’t have today’s confinement technologies.

Luckily is using snapcraft a real joy: you write one declarative file, define your snap’s parts, make use of snapcraft‘s many plugins and if really necessary, you write a quick and simple plugin using Python to run your custom build.

Many of the first issues new snaps ran into were solved by improvements and new features in snapd and snapcraft. If you are still seeing a problem with your snap, we want you to get in touch. We are all interested in seeing more software as snaps, so let’s work together on them!

Enter the Sandpit

I mentioned it in my last announcement of the last Snappy Playpen event already, but as we saw many new snaps being added there in the last days, I wanted to mention it again. We started a new initiative called the Sandpit.

It’s a place where you can easily

  • list a snap you are working on and are looking for some help
  • find out at a glance if your favourite piece of software is already being snapped

It’s a very light-weight process: simply edit a wiki and get in touch with whoever’s working on the snap. The list grew quite quickly, so there’s loads of opportunities to find like-minded snap authors and get snaps online together.

You can find many of the people listed on the Sandpit wiki either in #snappy on Freenode or on Gitter. Just ask around and somebody will help.

Happy snapping everyone!

Get your software snapped tomorrow!

For a few weeks we have been running the Snappy Playpen as a pet/research project already. Many great things have happened since then:

  • With the Playpen we now have a repository of great best-practice examples.
  • We brought together a lot of people who are excited about snaps, who worked together, collaborated, wrote plugins together and improved snapcraft and friends.
  • A number of cloud parts were put together by the team as well.
  • We landed quite a few high-quality snaps in the store.
  • We had lots of fun.

Opening the Sandpit

With our next Snappy Playpen event tomorrow, 20th September 2016, we want to extend the scheme. We are opening the Sandpit part of the Playpen!

One thing we realised in the last weeks is that we treated the Playpen more and more like a place where well-working, tested and well-understood snaps go to inspire people who are new to snapping software. What we saw as well was that lots of fellow snappers kept their half-done snaps on their hard-disk instead of sharing them and giving others the chance to finish them or get involved in fixing. Time to change that, time for the Sandpit!

In the Sandpit things can get messy, but you get to explore and play around. It’s fun. Naturally things need to be light-weight, which is why we organise the Sandpit on just a simple wiki page. The way it works is that if you have a half-finished snap, you simply push it to a repo, add your name and the link to the wiki, so others get a chance to take a look and work together with you on it.

Tomorrow, 20th September 2016, we are going to get together again and help each other snapping, clean up old bits, fix things, explain, hang out and have a good time. If you want to join, you’re welcome. We’re on Gitter and on IRC.

  • WHEN: 2016-09-20
  • WHAT: Snappy Playpen event – opening the Sandpit
  • WHERE: Gitter and on IRC

Added bonus

As an added bonus, we are going to invite Michael Vogt, one of the core developers of snapd to the Ubuntu Community Q&A tomorrow. Join us at 15:00 UTC tomorrow on http://ubuntuonair.com and ask all the questions you always had!

See you tomorrow!

Need helping getting started with snapping?

Are you interested in snapping software and need help?

snapcraft-website

There’s a lot of good reasons for snapping software:

  • You get software out to millions of users: Ubuntu (snapd installed by default since Ubuntu 16.04 LTS), snapd available too on Arch, Debian, Gentoo, Fedora, openSUSE, openembedded, yocto and OpenWRT.
  • You get to define the experience: ship the stack the way you tested it. Just one simple test-scenario for you.
  • Building a snap is simple (one piece of YAML controls the build), publishing is instantaneous (one command to run, automatic review).
  • Multiple release channels in the store.

If you’re intrigued but need help to get started, tomorrow is a great time for this, as we’re going to have another Snappy Playpen event.

Tomorrow (13th Sept 2016) we are going to hang out on Gitter and IRC and will be there to answer your questions, work on snaps together and have fun!

In the Snappy Playpen project we are collecting best-practices and work on getting snaps out there together. We’re a friendly bunch and look forward to meeting you!

Snapcraft workshop at Akademy

I’m looking forward to next week, as

Going-To-Akademy-2016On Wednesday I’m going to give this workshop

So if you are interested in learning how to publish software easily and directly to users, this might be just for you.

Snaps are self-contained, confined apps, which run across a variety of Linux systems. The process of snapping software is very straight-forward and publishing them is very quick as well. The whole process offers many things upstreams and app publishers have been asking for years.

The workshop is interactive, all that’s required is that you either have VirtualBox or qemu installed or run any flavour of Ubuntu 16.04 or later. I’m going to bring USB sticks with images.

The workshop will consist of three very straight-forward parts:

  • Using the snap command to find, install, remove, update and revert software installations.
  • Using snapcraft to build and publish software.
  • Taking a look at KDE/Qt software and see how it’s snapped.

A few words about your host of the session: I’m Daniel Holbach, I have been part of the Ubuntu community since its very early days and work for Canonical on the Community team. Right now I’m working closely with the Snappy team on making publishing software as much fun as it should be.

See you next Wednesday!

Daunted

… was probably written across my face when I first got involved in Ubuntu and contributed my first patch. I wasn’t quite sure if I had followed the right procedure or if anything else was wrong, but luckily I found a lot of very friendly people who helped me out and got my contribution in.

That was almost 8 years ago. Today it’s a lot easier. There is good documentation, there are more consistent processes and better tools.

If you have pondered getting involved for a while, I’d like to invite you to check out our Bug fixing initiative. We singled out a number of issues in Ubuntu which we feel are appropriate to whetting your appetite and sorted them, so the most easy tasks are at the top.

Let us know how this works for you and ask all the questions you might run into on #ubuntu-motu on irc.freenode.net.

If only I had known what needs to be done…

I just went over the soon-to-be-released report of the Developer Advisory Team, where we sum up feedback from first-time contributors to Ubuntu Development and many noted that they found developer documentation easily and things generally worked out for them, but they struggled finding stuff to work on.

The Ubuntu Development team has always been good at creating new TODO lists (merges, Debian RC bugs, build failures, heaps of different bug lists and much much more), but you need to know what you are looking for.

Enter Harvest. We created it so it merely aggregates opportunities for Ubuntu developers in a simple web interface. You can select opportunity types and specific sets of packages to narrow down opportunities based on your interests.

If you got some spare time, are interested in Ubuntu development and would like to help, you would do the Ubuntu world a great favour by doing one of the following:

If you are an Ubuntu developer or would like to become one: trying it out and commenting below with your experience. (Bugs can be filed here.)

If you have a great idea on how it could be further simplified, extended or improved, write up your idea and link to it in the comments.

If you are a web developer: please get in touch. Harvest is written using Django and Python and it’s super-easy to extend, improve and fix it – so if you are looking for something to help out with, this might be a great opportunity for you.

Please consider helping out, your contributions will not only help you make better use of Harvest, but many other developers and new contributors as well. 🙂

(If you tried it out and it works perfectly for you, let us know too. :-))

DJing

I’ve been slacking a bit when it comes to DJing land picked it up this year again. Some of my mixtapes are on a part of my blog that’s not syndicated, but I set up a page with all the posts. I just posted a new one today.

If you have no plans tonight and you’re in Berlin, come to the GNOME3 Launch Lounge (Facebook event page) in c-base tonight. I’ll be playing there as well. 🙂

Daily Build awesomeness

One of my favourite applications in the Ubuntu and general Open Source world is xwax. It allows me to hook up my turntables using a Native Instruments Audio4DJ device. This way I can use music I bought on the Ubuntu One Music store using my turntables (as a controller). It’s absolutely fantastic.

Because I love xwax so much, I just set up an automatic daily build in Launchpad. The process is pretty straight-forward:

  • set up a Launchpad code import of upstream trunk
  • write a very short build recipe (mine basically just says: branch upstream trunk from LP and nest a branch with the packaging into the ./debian directory)
  • test the build recipe
  • and request build for the Ubuntu releases you’re interested in
  • done.

This is seriously good work by the Launchpad and Bazaar people. I hope this will help us figure out problems in specific pieces of upstream software much earlier in the future.

SWEET!

Christmas video cast

As I mentioned earlier, today I’m working with Ara, Matthias, Michael and Yaiza at Büro 2.0 and we just finished a very funny video cast together.

Matthias ‘doko’ Klose made sure to arrive AFTER the video cast was done, but rest assured he can not evade. In recompensation he brought Father Christmas hats, so to you here’s from the Canonical Berlin team:

Merry Christmas and Happy New Year
Merry Christmas and Happy New Year