Profile

Cover photo
Martin Pitt
Works at Canonical Ltd.
Lives in Augsburg, Deutschland
541,034 views
AboutPostsPhotosYouTube

Stream

Martin Pitt

Shared publicly  - 
 
Little new fatrace release 0.12, fixing a regression in 0.10 (crashes when using -p).
3
Add a comment...

Martin Pitt

Shared publicly  - 
 
Yay, the first production result for an armhf test run on a remote LXD container in a Scalingstack arm64 instance. This seems to work reasonably well.

The controller instance for this is still hand-cobbled, but charming this up is just a SMOP. I now started four workers, which should help to grind through the backlog.

Eventually these will replace the manually maintained Calxeda nodes that use classic LXC, but before that we really need to figure out why these arm64 instances auto-destruct after some time.. (https://launchpad.net/bugs/1531768) It's not nearly as bad as a month ago, though, so let's see how long they hold up. ☺
10
Add a comment...

Martin Pitt

Shared publicly  - 
 
Yay, due to some unknown fix arm64 instances have stopped auto-destructing themselves (https://launchpad.net/bugs/1531768). So I took another attempt at moving armhf autopkgtesting from our manually maintained Calxeda nodes into Scalingstack.

I now have a cloud-init userdata script which sets up a large btrfs partition for LXD (as that's vastly faster than on ext4), configure the LXD bridge, cron job to regularly build autopkgtest images for all supporte releases etc., and it works quite nicely. I've been running a test loop on this over night using autopkgtest's remote lxd runner, without a single hiccup.

This also uses socat to forward the local Unix socket to the TCP port, instead of lxd's builtin SSL web server. autopkgtest sends a lot of "lxc exec" calls, and as each of those would have to go through the whole SSL negotiation, running tests is achingly slow. With that trick (thanks to +Tyler Hicks in https://launchpad.net/bugs/1538174) this now runs very fast and smooth, even though all the operations happen on a remote LXD server!

(Running remotely is necessary due to how our different clouds (Prodstack vs. Scalingstack) are organized and firewalled from each other.)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 ...
5
Add a comment...

Martin Pitt

Shared publicly  - 
 
Advanced British Traffic Control!

(Spotted at Canary Wharf, London)
16
4
Cassidy James Blaede's profile photoColin King's profile photoFabio Massimo Di Nitto's profile photo
3 comments
 
it would explain a lot about UK driving skills.. :P
Add a comment...

Martin Pitt

Shared publicly  - 
 
Upstream pull requests for systemd on GitHub are now running full system integration tests. Click on "Show all checks" on e. g. https://github.com/systemd/systemd/pull/2662, there is an "ubuntu-ci" test.

These check out the pure code of that PR (no Debian/Ubuntu patches), build .debs out of those, install them into the testbed (Ubuntu 16.04 ATM), and run the autopkgtests in "TEST_UPSTREAM=1" mode, which skips/adjusts some Debian specific tests.

This will hopefully avoid introducing regressions that we can detect automatically before the damage is done and things land in master. Indeed these tests detected a fair number of regressions last year already, but it was always an exercise in bisecting and manual investigation after the fact. Like this it should be much cheaper.

So, say it with Mr. T and a bad pun! (The "ubuntu-ci" test has my logo due to how GitHub works)
38
2
Bjoern Michaelsen's profile photoDavid Morley's profile photo
2 comments
 
But you are a Pitti, fool! ;)  Awesome news well done :)
Add a comment...

Martin Pitt

Shared publicly  - 
 
autopkgtests on s390x is back, I revived the lxc hosts. I also re-enabled it for proposed-migration, now it has some catching up to do.
3
Add a comment...

Martin Pitt

Shared publicly  - 
 
Now that the pageful of upgrade fixes for xenial can be dropped, the remaining Ubuntu changes to systemd shrinked down to one patch. \o/

I'm trying to think of a way to put that into Debian as well, and only apply the patch when building on Ubuntu. I just wish debian/patches/{debian,ubuntu}.series would be applied in addition to debian/patches/series, not replace it entirely. Nobody wants to maintain two almost identical series files..
Format: 1.8 Date: Mon, 25 Apr 2016 13:18:04 +0200 Source: systemd Binary: systemd systemd-sysv systemd-container systemd-journal-remote systemd-coredump libpam-systemd libnss-myhostname libnss-mymachines libnss-resolve libsystemd0 libsystemd-dev udev libudev1 libudev-dev udev-udeb libudev1-udeb ...
13
1
Martin Pitt's profile photoPhilipp Kern's profile photo
3 comments
 
+Martin Pitt​ Thanks!
Add a comment...

Martin Pitt

Shared publicly  - 
 
Thanks Adele, this was a fantastic concert!

This woman just has a goddess-like voice, and we really enjoyed the show: not too pretentious, but just great for the O2 arena.

Greetings from London!
15
Jorge Castro's profile photo
 
Saw her a few years ago before she got insanely popular, she's an incredible performer, glad you liked it!
Add a comment...

Martin Pitt

commented on a post on Blogger.
Shared publicly  - 
 
To be fair, this is rather unrelated to the concept of "containers" in the sense/meaning of a virtualization technology. I suppose that when you say "container" you really mean "docker image"?

What's really going wrong these days is the tendency towards bundling all your dependencies in your app (regardless of how you deploy them, on bare metal, VMs, containers, etc.). I have a feeling that developers think that they want full control over the entire software stack, without realizing how much of a maintenance burden this is in the long run -- they essentially have to maintain a full OS instead of just their app, and it's being demonstrated over and over again that this is just doomed to fail.

IMNSHO, app developers do not get to say how to ship and run their application, as it's not their responsibility to do so. They get to say "there is my code, my build system, and my test suite", but building/updating/deploying is the task of a classic Linux distribution, an app store, a site that automatically rebuilds your apps/docker images, the operators at your company, or similar -- i. e. the people who are the responsible operators.
6
2
Jussi Pakkanen's profile photoJasper St. Pierre's profile photoVincent De Smet's profile photoFlorian Haas's profile photo
10 comments
 
+Jasper St. Pierre Okay, so who do you expect to patch your containers for the next libc/OpenSSL/Apache vulnerability? Will you do it yourself? Will you do it in a matter of minutes after the vulnerability becomes public knowledge?
Add a comment...

Martin Pitt

Shared publicly  - 
 
Try that with SSDs and e-Readers!
1
Add a comment...
Work
Employment
  • Canonical Ltd.
    2004 - present
Basic Information
Gender
Male
Story
Tagline
Does it have a test case?
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
Augsburg, Deutschland
Previously
Dresden, Deutschland
Links
Other profiles
Contributor to