Sunday, January 15, 2017

The new Ubuntu SDK, part 3

[Update: Changed links to source code from https://launchpad.net/qtcreator-plugin-ubuntu and https://launchpad.net/ubuntu-sdk-tools to 
https://code.launchpad.net/~ubuntu-sdk-team/.... which is where the current tools probably live.]
Ubuntu SDK IDE offers custom project templates. Either CMake or qmake based.
I wonder how does the C++ compilation with CMake work in the Ubuntu SDK, so let's explore the "QML App with C++ plugin (cmake)" template. The source code for it can be seen in the qtcreator-plugin-ubuntu package. It includes all the parts required for a click package, wrapped in CMake:

Saturday, January 14, 2017

The new Ubuntu SDK, part 2

[Update: Changed links to source code from https://launchpad.net/qtcreator-plugin-ubuntu and https://launchpad.net/ubuntu-sdk-tools to 
https://code.launchpad.net/~ubuntu-sdk-team/.... which is where the current tools probably live.]

Continuing from part 1, which shows how to use the current Ubuntu SDK from the command line, let's have a look at how does the build from the SDK IDE (rebranded Qt Creator) work.
There are two relevant packages:

Friday, January 13, 2017

The new Ubuntu SDK, part 1

[Update: Changed links to source code from https://launchpad.net/qtcreator-plugin-ubuntu and https://launchpad.net/ubuntu-sdk-tools to 
https://code.launchpad.net/~ubuntu-sdk-team/.... which is where the current tools probably live.]

In September of 2016 Canonical released an updated version of the Ubuntu SDK. The main change there was a move from the schroot-based build images (kits) to LXD-based images as can be read in the announcement. Some more details are mentioned in the beta announcement. But that's about all I found about this change.

Luckily, there are some other places where one can see how does the new SDK work and how to use it from the command line:

Thursday, June 9, 2016

Building Ubuntu Click applications - minimal package built manually

Note: This has been obsoleted by the move from schroot to LXD. See this post.

There is some information available on the Ubuntu developer portal on building Click applications. But this mostly covers pure QML applications or QML applications with a C++ shared library, all with the Ubuntu SDK IDE (rebranded Qt Creator).
If you care about what is happening below this level, there is not that much info available, at least not in one place. I found:

Sunday, January 3, 2016

Building an ethernet tap with linux

Say you want to see what's going on an ethernet line. And say the line runs something like PPPoE, i.e. a protocol below the internet layer, where the addressing is done by MAC addresses.

It's not possible to put an ordinary switch in the middle, as the ethernet frames would not get through. What is needed is an ethernet tap or port mirroring. An old-fashioned ethernet hub would work here, mirroring the traffic from either end of the original wire to a third port that could be monitored e.g. by Wireshark. But can this done be without a special device, with plain linux?

Thursday, June 11, 2015

Global proxy with Node.js

It would be nice if applications written in node.js respected system proxy setting (i.e. http_proxy and https_proxy). But this doesn't seem to be the case.
If you make http(s) requests from your node.js application, the system setting is ignored unless you take extra care to do the right thing.
So how does one even use a proxy with http and https modules? It turns out the answer is: use an agent (the same for https). Agents can do many things and they can also implement proxying. The most popular agents for proxying seem to be http-proxy-agent and https-proxy-agent but there's also proxying-agent which can do both HTTP and HTTPS.

QEMU too slow? -enable-kvm!

I've been using QEMU for emulating other architectures on my PC for quite some time. But when I needed to emulate an ordinary PC (x86_64 on x86_64), I had been using VirtualBox most of the time.
When I tried QEMU for such emulation I always felt it's terribly slow. Only once I read the docs more carefully I realized what I had been missing was -enable-kvm. Adding this switch makes a huge difference. Interestingly, when I read other documents about QEMU, I don't see this mentioned more prominently.
KVM only works when the architecture you emulate is the same as the host architecture and the host has KVM support. But that is something I assume all recent PCs have, so KVM should work for you.