Like each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In September, 85.50 work hours have been dispatched among 8 paid contributors. Their reports are available:

• Ben Hutchings did 14 hours (13.5h allocated, thus only catching up 0.5 hours out of the 5.5 extra hours he had left from former month).
• Chris Lamb did 11 hours (12h allocated, he will catch up later).
• Guido G nther did 4 hours (out of 8 hours allocated, thus keeping 4 extra hours for November).
• Mike Gabriel did nothing (out of 8 hours allocated, he will catch up in November).
• Rapha l Hertzog did 13.25 hours.
• Santiago Ruano Rinc n did 13.5 hours.
• Scott Kitterman did 8 hours (4 hours allocated and 4 hours remaining from September)
• Thorsten Alteholz did 13.25 hours.

Evolution of the situation November crossed a new record with 114.5 hours funded. This is mainly thanks to our first Platinum sponsor: TOSHIBA (through Toshiba Software Development Vietnam). They don t know yet if they can sponsor us in the long term (they hope so), but it s still a nice news as we jumped from 50% to 65% of the objective of the equivalent of a full-time position with a single new sponsor. Currently no change is expected for next month as we don t have any other new sponsor in the process of joining us. We still need more support to be able to support all the packages we could not afford to support during the squeeze cycle. We are currently discussing which package we can or cannot support on the LTS list, see the thread Unsupported packages for Wheezy LTS for the current situation. In terms of security updates waiting to be handled, the situation is close to last month: the dla-needed.txt file lists 21 packages awaiting an update (6 more than last month), the list of open vulnerabilities in Squeeze shows about 23 affected packages in total (exactly like last month). Thanks to our sponsors The new sponsors are in bold.

• Platinum sponsors:
• TOSHIBA
• Gold sponsors:
• The Positive Internet (for 17 months already)
• Blablacar (for 16 months already)
• Linode LLC (for 6 months already)
• Silver sponsors:
• David Ayers IntarS Austria (for 17 months already)
• Domeneshop AS (for 16 months already)
• Universit Lille 3 (for 16 months already)
• Trollweb Solutions (for 14 months already)
• Gandi SAS (for 11 months already)
• University of Luxembourg (for 8 months already)
• Rentabiliweb Group (for 6 months already)
• Univention GmbH
• Universit Jean Monnet de St Etienne
• Bronze sponsors:
• Offensive Security (for 17 months already)
• Seznam.cz, a.s. (for 17 months already)
• Evolix (for 16 months already)
• Freeside Internet Service (for 16 months already)
• MyTux (for 16 months already)
• Linuxhotel GmbH (for 14 months already)
• Intevation GmbH (for 13 months already)
• Daevel SARL (for 12 months already)
• Bitfolk LTD (for 11 months already)
• Megaspace Internet Services GmbH (for 11 months already)
• Gree, Inc. (for 10 months already)
• Greenbone Networks GmbH (for 10 months already)
• NUMLOG (for 10 months already)
• WinGo AG (for 9 months already)
• Ecole Centrale de Nantes LHEEA (for 5 months already)
• Sig-I/O (for 3 months already)
• Entr ouvert

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

db2twitter 0.2 was just released! If you missed my last post about it, db2twitter automatically extracts fields from your database, use them to feed a template of tweet and send the tweet. db2twitter is developed by and run for LinuxJobs.fr, the job board of th french-speaking Free Software and Opensource community.

• Github of db2twitter (star it if you like ;)
• Official documentation on readthedocs

The main new feature allows to send tweets only during authorized days/hours with the following content in your db2twitter.ini file :

[timer]
days=mon-fri,
hours=0-11,14-17,

• The line days=mon-fri specifies db2twitter can send tweets only from monday to friday.
• The line hours=0-11,14-17 specifies db2twitter can send tweets from midnight to 11AM (included) and from 2PM to 17PM (included)

Given the fact db2twitter will mostly be launched via cron, it allows sending tweets detected since the last db2twitter run during user-defined hours. And that s cool! db2twitter is coded in Python 3.4, uses SQlAlchemy (see supported database types) and Tweepy. The official documentation is available on readthedocs.

On the 13th of May this year, I legally became Lucy Wayland. I d been living as a woman full time a couple of months before that, but that is when two dear friends witnessed my name change. I am going to post about the whole experience when it is finally into the completion zone. However, this last weekend just gone, I was helping out with the Cambridge (UK) MiniDebConf. I was mostly gophering and front-desk-helpering, with side orders of beverages, so I missed most of the talks. Which is not the point. I met nearly everybody at the conference. Many of them knew me as Jon, a goateed man. I was there as Lucy, a woman. And nobody batted an eyelid.

• Not a single person used my old name
• Not a single person mis-gendered me
• Not a single person referred to my transition

The only time I had to produce my Deed Poll out was for keysigning, as I still do not have photo ID with my new name on. I proffered it along with my passport, so there was no embarrassment. I know other people within Debian have gone through the same process. However, I just have to say how wonderful it is, to be accepted just that way. And hence the title of my article. Our differences bring us together. So many different people from so many different cultures came together, wanted to create, and my change of gender was just irrelevant. And that s how it should be.

I m excited to see other people thinking about userspace-to-kernel attack surface reduction ideas. Theo de Raadt recently published slides describing Pledge. This uses the same ideas that seccomp implements, but with less granularity. While seccomp works at the individual syscall level and in addition to killing processes, it allows for signaling, tracing, and errno spoofing. As de Raadt mentions, Pledge could be implemented with seccomp very easily: libseccomp would just categorize syscalls. I don t really understand the presentation s mention of Optional Security , though. Pledge, like seccomp, is an opt-in feature. Nothing in the kernel refuses to run unpledged programs. I assume his point was that when it gets ubiquitously built into programs (like stack protector), it s effectively not optional (which is alluded to later as comprehensive applicability ~= mandatory mitigation ). Regardless, this sensible (though optional) design gets me back to his slide on seccomp, which seems to have a number of misunderstandings:

• A Turing complete eBPF program watches your program Strictly speaking, seccomp is implemented using a subset of BPF, not eBPF. And since BPF (and eBPF) programs are guaranteed to halt, it makes seccomp filters not Turing complete.
• Who watches the watcher? I don t even understand this. It s in the kernel. The kernel watches your program. Just like always. If this is a question of BPF program verification, there is literally a program verifier that checks various properties of the BPF program.
• seccomp program is stored elsewhere This, with the next statement, is just totally misunderstood. Programs using seccomp define their program in their own code. It s used the same way as the Pledge examples are shown doing.
• Easy to get desyncronized either program is updated As above, this just isn t the case. The only place where this might be true is when using seccomp on programs that were not written natively with seccomp. In that case, yes, desync is possible. But that s one of the advantages of seccomp s design: a program launcher (like minijail or systemd) can declare a seccomp filter for a program that hasn t yet been ported to use one natively.
• eBPF watcher has no real idea what the program under observation is doing I don t understand this statement. I don t see how Pledge would have a real idea either: they re both doing filtering. If we get AI out of our syscall filters, we re in serious trouble. :)

OpenBSD has some interesting advantages in the syscall filtering department, especially around sockets. Right now, it s hard for Linux syscall filtering to understand why a given socket is being used. Something like SOCK_DNS seems like it could be quite handy. Another nice feature of Pledge is the path whitelist feature. As it s still under development, I hope they expand this to include more things than just paths. Argument inspection is a weak point for seccomp, but under Linux, most of the arguments are ultimately exposed to the LSM layer. Last year I experimented with creating a seccomp LSM for path matching where programs could declare whitelists, similar to standard LSMs. So, yes, Linux could match this API on seccomp . It d just take some extensions to libseccomp to implement pledge(), as I described at the top. With OpenBSD doing a bunch of analysis work on common programs, it d be excellent to see this usable on Linux too. So far on Linux, only a few programs (e.g. Chrome, vsftpd) have bothered to do this using seccomp, and it could be argued that this is ultimately due to how fine grained it is.

2015, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

October 2015 has been mainly dedicated to contracted/payed work. Only a few issues I could address during the last month:

• Fix FTBFS of Arctica Greeter on non-Ubuntu systems
• Co-working on renewed Xinerama support in nx-libs
• Development of GOsa Password Management Add-on
• Improving Debian Edu main server upgrade documentation (from Debian Edu squeeze to Debian Edu jessie)
• Fixing my personal Horde Groupware installation for access via mobile devices
• Learning Dovecot et al.

Arctica Project While having a week off from work, I managed to get Arctica Greeter to build on non-Ubuntu systems. The issue was very simple. The build crashed during the test suite run and it was caused by the XDG_DATA_DIRS variable not being set in my clean build environment. Furthermore, I added various more session type icons to Arctica Greeter (XFCE, LXDE, MATE, OpenBox, TWM, Default X11 Session, etc.) and also rebased the Arctica Greeter code base against all recent commits found in Unity Greeter for Ubuntu 15.10 / upcoming 16.04. Together with Ulrich Sibiller, I continued our work on the new Xinerama implementation for the remote X11 server nxagent (used as x2goagent in X2Go). However, this is unfortunately still work in progress, because various theoretical monitor layout issues became evident that require being handled in the new code before it can get merged into nx-libs's current 3.6.x branch. Also, I managed to do some little work on https://arctica-project.org, the still too rudimentary project homepage. read more

Wishing you all a happy Diwali and Gujarati New Year (V.S. 2072 called Plavanga.)Instead of being something sane like a flat disk supported by four elephants standing on a tortoise, the Earth is an oblate spheroid in heliocentric orbit. The Moon too offends by maintaining an unreasonably non-epicyclic orbit. Combined this means that the Americas (plus Iceland if there any Hindus there) observe Diwali today whereas in India and the rest of the world it is tomorrow. Technically in these longitudes the Ashvayuja amavasya tithi pervades both Tuesday and Wednesday but as Lakshmi Puja takes place at the pradosha kala it means it should be celebrated today though no doubt most of the non-astronomically minded people will just follow India any way. The New Year is on Thursday all over the world.Regardless of when you celebrate, may your year be full of happiness, good fortune and prosperity.

If you have a HTTPS-enabling proxy in front of your gitweb, so that it tries to do <base href="http://..."> (because it doesn't know that the user is actually using HTTPS), here's the Apache configuration variable to tell it otherwise:

SetEnv HTTPS ON

So now git.sesse.net works with HTTPS after Let's Encrypt, without the CSS being broken. Woo. (Well, the clone URL still says http. So, halfway there, at least.)

Ok, I have been an iPhone user since I moved to Japan and got my first smart-phone ever. First a 3s, then a 4s, then a 5s that I dropped into the toilet, so I switched the SIM back into the 4s to have a working phone. Furthermore, I am a heavy music listener and used iTunes Radio for 3 months. Since I am planning to change phones to an Android phone (being fed up with Apple s super-closed environment), I tried out Google Music Plus for about 3 months, too. Here is my verict Google Music is a big pain, far from iTunes in comfort and user friendliness. My move to Android is not very much in danger. General description of the service In principle, iTunes Radio and Google Music Subscription do the same things:

• allow you to have your own music in the cloud
• stream any music from the respective market place to your device
• provide radio stations, pre-curated or based on artist/genre/etc

There are slight differences, that often create confusion, especially with Apple s services: If you are only signed in, you can listen to music stations and can skip some music (limited), but you cannot listen to arbitrary songs from the whole Apple Music library. Then there is another service from Apple, called iTunes Match, that only allows you to upload your music library to the cloud, but other than that again only listening to normal radio stations. Google Music is much simpler, there are only two options: By default it is free to have your music (up to 25000 songs) in the cloud, but if you want to listen to radio stations or any other music in the Google music store, you need a subscription. Prizes and features overview:

	Apple			Google
	No subscription	iTunes Match	iTunes Radio	No subscription	With subscription
Prize	0	25$/year	10$/month	0	10$/month (early access 8$)
Cloud space	0	100000		25000
Extra service	Radio stations	Radio stations	Radio/all music	Nothing	Radio/all music

Music on the go the application Let us first consider the applications provided to listen to music on your smart phone: Apple Music can of course only be used on Apple devices, and uses the built-in Music application. Start up time is about a few seconds after a cold boot (all on my 4s), and music streaming starts with hardly any delay. Responsiveness is good, and the user interface is clear and easy. Google s application is available on iOS and Android. I have tested the latest version on iOS, but it is a pain in the butt:

• Starting the application, even after cold boot, is successful at a rate of 1/10. Most of the time the application crashes right away. This might be a problem due to my low end device (iPhone 4s with 64Gb), but not due to space problems (half empty) nor internet connectivity (wlan).
• Responsiveness is abysmal
• Access to additional content (radio, songs) and your own library is well done, similar to iMusic.

Managing your library Here iTunes is the way to go, bit of a pain when using Linux, but there are other reasons I have a Windows installation in parallel, so I don t mind to boot now and then into Windows. iTunes gives you very powerful tools to change all kind of data. Google gives you a few options: Use your iTunes library in this case all your playlists and ratings (but see later) are also uploaded. I am not sure what happens if I retag a song in iTunes, or change anything else in there. I guess the song will not be re-uploaded, but who knows for sure. Furthermore, you can edit your library via the web interface, but this is rather poor. Searching your library Over times your library grows and there are hundreds if not thousands of artists. So you want to search them. The natural way would be to scroll to the first letter of the artist you are searching, and then look it up. Well, that works perfectly in both Apple s and Google s application unless you are having artists written in some strange script like Japanese or Korean. iTunes allows you to set a field called something like Artist name for sorting , which allows me to put for example or into the artist field, and into the sort field Tomokawa Kazuki and Kim Doo Soo . This way I find the artists in the correct place. Google on the other hand uses simple Unicode order sorting how could you do that? This is simply plain wrong, and everyone should know that by now. Japanese people will never be able to find anything in their list. And in contrast to Goole Contacts Google Music does not support phonetic name fields (similar to the order sort artist) for artists. What I had to do now is to rename all the artists to include first the phonetic name, followed by the proper name, like in Tomokawa Kazuki ( ) . Something I strongly detest! Radio stations I might have a slightly peculiar music taste, but the radio stations mixed by Google are simply a pain. The reason is easy to explain: I live in Japan, and so what Google does is mixing about 80% of J-Pop into the radio, all those happy yodeling girlies I really dislike (see my Anti J-Pop campaign for alternatives yes, they do exist also in Japan!). iTunes radio is here more relaxed it seems. I appreciate Google s trial to cater to local (dis)taste, but besides voting down each and every song I hear I don t see any other option. And honestly, I cannot go through all this voting down without dying from pain inflicted by J-Pop. Other than this, the two radio stations are probably more or less the same but as I said, due to the local colorit it is hard to compare. Rating Ohhh, what a dire point. So there you have you well curated iTunes library with 5-star ratings. I used the ratings in a way that those songs I like get 1 star, those I even like more get 2 stars, and my absolute favorites got 5 stars. I didn t do any negative ratings. iTunes/iOS Music app allows you to easily adjust rating, and they are synced between devices. All as you would expect. Now for Google they did have a 5-star rating system at some time, but:

Thank you for your feedback. We ve decided to remove the 5-star Rating lab. This decision wasn t made lightly, but Thumbs Up/Down is integral for the future vision for Play Music and will be a central design point for our future releases. Please note that we ll continue to store your ratings that you ve set via the star lab or via iTunes, and we ll translate them to thumbs up/down (1-2 stars = thumbs down, 4-5 stars = thumbs up).

Here we go with the move to a new design they threw away the 5-star system, without any reason but integral for future vision rubbish sales speak. Besides being a very very poor rating system to have only an up and down (good-bad-don t care), the translation from my rating system to the thumbs up-down is just plain wrong. <rant>
Why on earth is the current movement to reduce functionality and rob users of control? Gnome 3 is the prime example of how we stupiditize users by taken any freedom from them in the name of simple design. Google now does the same. I am so sick of getting patronized this way, so Gnome3 was completely banished from my computer and replaced by Cinnamon, which uses the same (good) underlying technique, but takes users seriously!
</rant> Overall verdict As much as I would like to see Google Music a valid alternative to iTunes, by now it makes the impression of a quickly hacked together rotten piece of code that tries to get a share of the market without providing equivalent service. Google is using its market presence and convenience to convert people, not features and quality. I can only hope that this changes in the future. That still leaves me with the question move to Android or remain with iOS

Debian Live has passed on. And it has done so in not happy circumstances. (You can search the list archives for more if you are confused.) I have reposted here my response to this one thread because it s all I really want to say, after all of the years of working with the team. I d like to add as a postscript, that while the focus of this article was to remain positive in the face of Daniel s announcement of the closure of his project, that event has left a lot of users confused about the status of live support in Debian going forward. Read my posts here and here addressing that confusion.

On 09/11/15 12:47 PM, Daniel Baumann wrote:
> So long, and thanks for all the fish[7].
>
> Daniel
>
> [7] http://live.debian.net/project/downstream/ Enough bitter words have been said. I don t want to add any more. So: I m proud. Indeed, that long list of downstreams does speak to the impact you ve had in inspiring and equipping people to make their own live images. I m proud to have been a small part of this project. I m thankful. I m thankful that I was able to, through this project, contribute to something for a while that had a positive impact on many people, and made Debian more awesome. I remember the good times. I remember fondly the good times we had in the project s heyday. I certainly found your enthusiasm and vision for the project, Daniel, personally inspiring. It motivated me to contribute. Debconf10 was a highlight among those experiences, but also I had many good times and made many friendships online, too. I m sad. I m sad, because although I made some attempts to liaise between Debian Live and the CD and Installer teams, I don t feel I did an effective job there, and that contributed to the situation we now find ourselves in. If I did you or the project injury in trying to fulfill that role, please forgive me. I m hopeful. I m hopeful that whichever way we all go from here, that the bitterness will not be forever. That we ll heal. That we ll have learned. That we ll move on to accomplish new things, bigger and better things. Thank you, Daniel. Thank you, Debian Live team. Ben

What happened in the reproducible builds effort this week: Toolchain fixes

• Colin Watson uploaded groff/1.22.3-2 which implements support for SOURCE_DATE_EPOCH.
• Colin Watson uploaded halibut/1.1-2 which implements support for SOURCE_DATE_EPOCH.

Chris Lamb filled a bug on python-setuptools with a patch to make the generated requires.txt files reproducible. The patch has been forwarded upstream. Chris also understood why the she-bang in some Python scripts kept being undeterministic: setuptools as called by dh-python could skip re-installing the scripts if the build had been too fast (under one second). #804339 offers a patch fixing the issue by passing --force to setup.py install. #804141 reported on gettext asks for support of SOURCE_DATE_EPOCH in gettextize. Santiago Vila pointed out that it doesn't felt appropriate as gettextize is supposed to be an interactive tool. The problem reported seems to be in avahi build system instead. Packages fixed The following packages became reproducible due to changes in their build dependencies: celestia, dsdo, fonts-taml-tscu, fte, hkgerman, ifrench-gut, ispell-czech, maven-assembly-plugin, maven-project-info-reports-plugin, python-avro, ruby-compass, signond, thepeg, wagon2, xjdic. The following packages became reproducible after getting fixed:

• 4ti2/1.6.6+ds-1 uploaded by Jerome Benoit, fixed upstream.
• allegro4.4/2:4.4.2-7 uploaded by Andreas R nnquist, original patch by Reiner Herrmann.
• axel/2.5-2 by Joao Eriberto Mota Filho.
• bastet/0.43-4 by Markus Koschany.
• bbswitch/0.8-3 uploaded by Luca Boccassi, original patch by Reiner Herrmann.
• commons-math/2.2-5 by Emmanuel Bourg.
• fatresize/1.0.2-8 by Colin Watson, reported by Chris Lamb.
• giada/0.10.2~dfsg1-1 by IOhannes m zm lnig.
• groff/1.22.3-3 by Colin Watson.
• halibut/1.1-2 by Colin Watson.
• ivy/2.4.0-2 by Emmanuel Bourg.
• libfreemarker-java/2.3.23-2 by Emmanuel Bourg.
• libjna-java/4.2.1-1 by Emmanuel Bourg.
• lmemory/0.6c-8 by Markus Koschany.
• man-db/2.7.5-1 by Colin Watson.
• maven2-core/2.2.1-23 by Emmanuel Bourg.
• ncurses/6.0+20151024-2 by Sven Joachim, report by Esa Peuha.
• netmask/2.4.3-1 by Guilhem Moulin.
• ogre-1.9/1.9.0+dfsg1-7 uploaded by Manuel A. Fernandez Montecelo, original patch by Chris Lamb.
• praat/6.0.4-2 by Rafael Laboissiere.
• soundscaperenderer/0.4.2~dfsg-5 by IOhannes m zm lnig.
• usb-modeswitch-data/20151101-1 uploaded by Didier Raboud, original patch by Reiner Herrmann.

Some uploads fixed some reproducibility issues but not all of them:

• dbconfig-common/1.8.55 by Paul Gevers.
• mondrian/1:3.11.0.1-1 by Emmanuel Bourg.

Patches submitted which have not made their way to the archive yet:

• #803893 on goaccess by Guillaume Delacour: remove __DATE__ and __TIME__ macros.
• #803908 on starlink-pal by Chris Lamb: pass -info 0 to latex2html.

Chris Lamb closed a wrongly reopened bug against haskell-devscripts that was actually a problem in haddock. reproducible.debian.net FreeBSD tests are now run for three branches: master, stable/10, release/10.2.0. (h01ger) diffoscope development Support has been added for Free Pascal unit files (.ppc). (Paul Gevers) The homepage is now available using HTTPS, thanks to Let's Encrypt!. Work has been done to be able to publish diffoscope on the Python Package Index (also known as PyPI): the tlsh module is now optional, compatibility with python-magic has been added, and the fallback code to handle RPM has been fixed. Documentation update Reiner Herrmann, Paul Gevers, Niko Tyni, opi, and Dhole offered various fixes and wording improvements to the reproducible-builds.org. A mailing-list is now available to receive change notifications. NixOS, Guix, and Baserock are featured as projects working on reproducible builds. Package reviews 70 reviews have been removed, 74 added and 17 updated this week. Chris Lamb opened 22 new fail to build from source bugs. New issues this week: randomness_in_ocaml_provides, randomness_in_qdoc_page_id, randomness_in_python_setuptools_requires_txt, gettext_creates_ChangeLog_files_and_entries_with_current_date. Misc. h01ger and Chris Lamb presented Beyond reproducible builds at the MiniDebConf in Cambridge on November 8th. They gave an overview of where we stand and the changes in user tools, infrastructure, and development practices that we might want to see happening. Feedback on these thoughts are welcome. Slides are already available, and the video should be online soon. At the same event, a meeting happened with some members of the release team to discuss the best strategy regarding releases and reproducibility. Minutes have been posted on the Debian reproducible-builds mailing-list.

For my 11th month working on Debian LTS, I carried over 5.5 hours from September and was assigned another 13.5 hours of work by Freexian's Debian LTS initiative. I worked 14 of a possible 19 hours. As I mentioned in the report for September, I uploaded binutils and issued DLA-324-1 early in October. I fixed a few security issues in the kernel, uploaded and issued DLA-325-1. I had some email discussions about long-term support of the Linux kernel with Willy Tarreau (Linux 2.6.32 maintainer) and Greg Kroah-Hartman (overall stable maintainer). Greg normally selects one version per year to maintain as a 'longterm' branch for 2 years, after which he may hand it over to another maintainer. A few upstream versions have received long-term support entirely from another developer. We were in agreement that it's desirable to have fewer of these branches with more developers and distributions contributing to each, but didn't come to a conclusion about how to coordinate this. The topic came up again at the Kernel Summit, and Greg then agreed to select the first kernel version of each calendar year, starting with Linux 4.4 (expected in January). This doesn't fit well with Debian's current release schedule, but I mean to discuss with the release team whether the freeze date can be set to allow inclusion of 2017's LTS kernel. I spent another week in the 'front desk' role, where I triaged new security issues for squeeze. There was a mixture of serious and trivial, old and new (not affecting squeeze) issues. The many ntp issues announced in October were fixed in unstable by a new upstream release. I spent a long time digging out the specific commits that fixed them and comparing with the older version in squeeze. Several of the issues had been introduced in ntp 4.2.7 or 4.2.8 and therefore didn't affect squeeze (or the newer stable releases). Of the fixes that were needed, most applied with minimal changes. Having prepared an update, I asked the ntp maintainer, Kurt Roeckx, to review my work. (The package has a limited test suite and none of the fixes added new tests.) Following this review he added a few more patches, uploaded and issued DLA-335-1. MySQL 5.1, as shipped in squeeze, no longer receives security support from upstream, and the security fixes they do issue are mixed with other changes that make it impractical to backport them. The LTS team is planning to backport the mysql-5.5 package to squeeze while avoiding conflicts with the binaries built from mysql-5.1. Santiago Ruano Rinc n has prepared a backport and I spent some time reviewing this, but haven't yet sent my review comments.

Two days worth of sprints - lots of hugely good work done.

Two days worth of open days with talks - lots of interest, feedback, chatting out of earshot in the breakout rooms.

Two days worth of monetary and other input from all the sponsors: ARM, Codethink, Cosworth, Hewlett Packard Enterprise Collabora - PRICELESS

Sociableness in pubs and so on overnight

Thanks also to Steve and Jo McIntyre for a houseful of guests and to all on front desk

And also lastly, again to ARM, as in all these posts because of this great venue and for the small army of ARM pass holders who have let us in and out of doors all this time.

MiniDebconf postings are being typed on my lap on a laptop real time.

I can't remember the consistent format of how I titled them last time :)

Thanks to all for coffee carrying, to Planet Debian for getting the postings up so quickly, to front desk, organisers, facilitators.

Next up - Network Performance Tuning: Lessons from the Coal Face by Christopher J Walker

[And yes, elgriff, I'm breaking all your good advice I heard less than an hour ago]

Auditorium fairly full - waiting for Bits from the DPL talk to kick off proceedings.

Thanks to ARM staff for getting me in, sat down, with coffee and ready to blog. Front desk friendly as ever ... and here we go.

Let's Encrypt is now in beta. Here's how to use the automated CA with Hitch TLS proxy, and Varnish HTTP accelerator as a backend for Hitch.

Debian LTS October was the sixth month I contributed to Debian LTS under the Freexian umbrella. In total I spent four hours working on:

• krb5: I applied patches for CVE-2015-2697 and CVE-2015-2695. The DLA-340-1 was released on November though since one of the patches was incomplete.

Besides that I did CVE triaging of 16 CVEs to check if and how they affect oldoldstable security as part of my LTS front desk work. I also added some very basic indentation support to our CVE/list Emacs major-mode on non LTS time. Other Debian stuff

• I've released git-buildpackage 0.7.0 with lots of updates, most notably more complete rpm support, a git-pbuilder update and documentation updates. This release has patches from 9 different contributors, thanks a lot!
• Uploaded libvirt 1.2.21~rc1 to experimental, submitted a patch to fix running autopkg tests in pbuilder (#802379) and fixed RC bug #802281 in Icedove.
• I've updated cl2vcs, a CGI to link commit IDs in the debian/changelog to the VCS, to 0.0.4 fixing some bugs that showed up after I updated the hosting machine to Jessie as well as support for the [commitid1,commitd2,commit3,...] format when grouping commits. (SSL certificate of the server is CAcert signed)
• At Halloween five Debian aficionados met for Hacking Erpel 1 (aka HEPL1) in Erpel (link goes to German Wikipedia) between Bonn and Koblenz. Some details are here. We're aiming for more of these events on a more frequent basis (HEPL0 being back in 2013) so if you're somewhere from that area and want to join us next time just subscribe to the new mailing list (in German, SSL certificate of the server is CAcert signed).

This is the fifth -and last- part in a series of articles about SRE, based on the talk I gave in the Romanian Association for Better Software. Previous articles can be found here: part 1, part 2, part 3, and part 4.

---

Other lessons learned Apart from these guidelines for SRE I have described in previous posts, there were a few other practices I learned at google that I believe could benefit most operations teams out there (and developers too!).

Automate everything It's worth repeating, it is not sustainable to do things manually. When your manual work grows linearly with your usage, either your service is not growing enough, or you will need to hire more people than there are available in the market.

Involve Ops in systems design Nobody knows better than Ops the challenges of a real production environment, getting early feedback from your operations team can save you a lot of trouble down the road. They might give you insights about scalability, capacity planning, redundancy, and the very real limitations of hardware.

Give Ops time and space to innovate If there is so much emphasis on limiting the amount of operational load put on SRE, that freed time is not only used for creating monitoring dashboards or writing documentation. As I said in the beginning, SRE is an engineering team. And when engineers are not running around putting fires off all day long, they get creative. Many interesting innovations come from SREs even when there is no requirement for them.

Write design documents Design documents are not only useful for writing software. Fleshing out the details of any system on paper is a very useful way to find problems early in the process, communicate with your team exactly what are you building, and convince them why it is a great idea.

Review your code, version your changes This is something that is ubiquitous at Google, and not exclusive to SRE: everything is committed into source control: big systems, small scripts, configuration files. It might not seem worth it at the beginning, but having complete history of all your production environment is invaluable. And with source control, another rule comes into play: no change is committed without first being reviewed by a peer. It can be frustrating having to find a reviewer and wait for the approval for every small change, and some times reviews will be suboptimal, but once you get used to it, the benefits greatly out-weights any annoyances.

Before touching, measure Monitoring is not only for sending alerts, it is an essential tool of SRE. It allows you to gauge your availability, evaluate trends, forecast growth, perform forensic analysis. Also very importantly, it should give you the data needed to take decisions based on reality and not on guesses. Before optimising, find really where the bottleneck is; do not decide which database instance to use until you saw the utilisation of the past few months, etc. And speaking of that... We really need to have a chat about your current monitoring system. But that's for another day.

---

I hope I did not bore you too much with these walls of text! Some people told me directly they were enjoying these posts, so soon I will be writing more about related topics. In particular I would like to write about modern monitoring and Prometheus. I would love to hear your comments, questions, and criticisms. Comment