FOSDEM 2016 is over

I went to FOSDEM 2016 this year with 8 other colleagues of mine and had a really really good time. A lot of good speeches and stuff to talk about and I feel very motivated for some new projects. Some of the stuff going on right now is incredibly exciting, especially with regards to containerization etc which is something I have a lot of personal and work related interest in. I will be looking into more details in that for the future…

What I did miss was a more “general networking” track with low level stuff like iptables, netfilter, iproute, wireshark, snort, etc. I’m just not sure if this is the right conference for that though. Gathering my thoughts and working out some of the project details in the upcoming week if I get time.

Using AWS EC2 instances for large builds

I experimented a few years ago with using EC2 spot instances (virtual server on the internet, but using unused server capacity). It was fairly successful, being able to run large calculations that should have taken weeks in a matter of days.

Since I started at my current job I’ve been running into building increasingly complex yocto images which keeps growing in size, at this point most images I build can take up to 6-7 hours to build on my laptop. This is an i7-4558U 2.8GHz cpu and 8 gigs of RAM so it’s not bad really, just not enough for these types of builds.

Again I started experimenting and I am really happy and impressed. So far all experiments are for open source projects etc, so nothing that has any non-disclosure agreements or corporate etc etc, I’d like to but this isn’t up to me really. I’ve setup an AMI on EC2 which I can instantiate and have up and running in 2-3 minutes, and then mount a 100 gig EBS volume where I store the sources and build data.

The same build that generally takes up to 6 hours on my laptop takes approximately 30-40 minutes on an EC2 c4.4xlarge machine (16 cores and 32 gigs ram).

My key findings so far is:

  1. Keep an AMI with all the build tools necessary/or script the setup.
  2. Keep an EBS volume with the long term stored data, gits etc for building and mount somewhere suitable in the AMI.
  3. Keep a micro instance (these are free/very cheap) around for mounting the EBS volume when you just want to check stuff out, mess around etc but not make builds.

Build ppa package

November 26, 2014 by · Leave a Comment
Filed under: Debian, Development, Linux, Ubuntu 

To build a package for ppa distribution, you need some tools. To “cross compile” for releases, for example i386 and amd64 packages on the same machine, takes some more work with schroot, dchroot etc. I’ll start with explaining how to create a “local” package for your own host, I’ll add another entry on how to do an i386 package from amd64. Everything is done on ubuntu 14.04 amd64 machine in this case, and I’m rebuilding dbus.

In short you need:

  1. apt-get install build-essentials dpkg-buildroot schroot gpg
  2. gpg –gen-key
  3. apt-get build-dep dbus
  4. mkdir dbus-amd64 && cd dbus-amd64
  5. apt-get source dbus
  6. export DEB_SIGN_KEYID=
  7. cd dbus-directory
  8. make changes.
  9. dch -i
  10. dpkg-source –commit
  11. dpkg-buildroot -i -I

If you plan on publishing your deb packages to launchpad or some such, you need to create an account and add a ppa. This is simple and done via the http://www.launchpad.net webpage. The webpage also gives you good upload information. Note that they require signed files, so signing must work for you first.

8. Create account on launchpad.
9. Export the gpg generated key to hkp://keyserver.ubuntu.com:11371 (easiest to do via Passwords and Keys tool
10. Import the key to launchpad using the key fingerprint.
11. Create a new PPA from the launchpad dashboard
12. dput ppa: dbus_1.6.18-0ubuntu4.4_source.changes

The package will be built by launchpad on its own, this may take some time..