Categories:

• Debian-Blog
• Tools

Keywords:

• apt-offline
• Offline APT Package Manager

Images:

Like:

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

It s now official: I m a pilot. This has been one of the most challenging, and also most rewarding, journeys I ve been on. It had its moments of struggle, moments of joy, moments of poetry. I wrote about the poetry of flying at night recently. Here is the story of my first landing on a grass runway, a few months ago. Grass

Where the air is so pure, the zephyrs so free,
The breezes so balmy and light,
That I would not exchange my home on the range
For all of the cities so bright. John A. Lomax

We are used to seeing planes in these massive palaces of infrastructure we call airports. We have huge parking garages, giant terminals, security lines hundreds of people deep, baggage carts, jetways, video screens, restaurants, and miles and miles of concrete. But most of the world s airports are not like that. A pilot of a small plane gets to see the big airports, sure, but we also get to use the smaller airports hidden in plain sight to most. Have you ever taken off from a strip of grass? As I told my flight instructor when I tried it for the first time, I know this will work, but somehow I will still be amazed if it actually does. I took off from a strip of grass not long ago. The airport there had one paved runway, and the rest were grass. Short runways, narrow runways, grass runways. No lights. No paint. No signs. No trucks, no jetways, nothing massive. In fact, no people. Just a mowed path and a couple of yellow or white markers. I taxied down the grass runway, being careful to never let the plane s wheels stop moving lest the nose gear get stuck in a pothole. I felt all the bumps in the ground as we moved. End of runway. Turn the plane around. A little bit of flap for more lift, full throttle, mind the centerline imaginary centerline, this time. It starts picking up speed, slower than usual, bump bump bump. Those buildings at the end of the runway are staring me down. More speed, and suddenly the runway feels smooth; it has enough lift to keep from falling into every bump. Then we lift off just a touch; I carefully keep the plane down until we pick up enough speed to ascend farther, then up we go. I keep a watchful eye on those buildings straight ahead and that water tower just slightly off to the one side. We climb over a lake as I watch that water tower pass safely below and to the side of the plane. It had worked, and I had a smile of amazement. With a half mile of grass, you really can go anywhere. Many times I had driven within half a mile of that runway, but never seen it. Never wondered where people go after using it. Never realizing that, although it s a 45-minute drive from my house, it s really pretty close. Never understanding that where people go after taking off from that runway is everywhere .

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

Last week Simon retweeted a link to Don t Feed the Beast the Great Tech Recruiter Infestation. Which reminded me I d been meaning to comment on my own experiences from earlier in the year. I don t entertain the same level of bile as displayed in the post, but I do have a significant level of disappointment in the recruitment industry. I had conversations with 3 different agencies, all of whom were geographically relevant. One contacted me, the other 2 (one I d dealt with before, one that was recommended to me) I contacted myself. All managed to fail to communicate with any level of acceptability. The agency hat contacted me eventually went quiet, after having asked if they could put my CV forward for a role and pushing very hard about when I could interview. The contact in the agency I d dealt with before replied to say I was being passed to someone else who would get in contact. Who of course didn t. And the final agency, who had been recommended, passed me between 3 different people, said they were confident they could find me something, and then went dark except for signing me up to their generic jobs list which failed to have anything of relevance on it. As it happens my availability and skill set were not conducive to results at that point in time, so my beef isn t with the inability to find a role. Instead it s with the poor levels of communication presented by an industry which seems, to me, to have communication as part of the core value it should be offering. If anyone had said at the start Look, it s going to be tricky, we ll see what we can do or Look, that s not what we really deal in, we can t help , that would have been fine. I m fine with explanations. I get really miffed when I m just left hanging. I d love to be able to say I ll never deal with a recruiter again, but the fact of the matter is they do serve a purpose. There s only so far a company can get with word of mouth recruitment; eventually that network of personal connections from existing employees who are considering moving dries up. Advertising might get you some more people, but it can also result in people who are hugely inappropriate for the role. From the company point of view recruiters nominally fulfil 2 roles. Firstly they connect the prospective employer with a potentially wider base of candidates. Secondly they should be able to do some sort of, at least basic, filtering of whether a candidate is appropriate for a role. From the candidate point of view the recruiter hopefully has a better knowledge of what roles are out there. However the incentives to please each side are hugely unbalanced. The candidate isn t paying the recruiter. If you re not paying for it, you re the product may be bandied around too often, but I believe this is one of the instances where it s very applicable. A recruiter is paid by their ability to deliver viable candidates to prospective employers. The delivery of these candidates is the service. Whether or not the candidate is happy with the job is irrelevant beyond them staying long enough that the placement fee can be claimed. The lengthy commercial relationship is ideally between the company and the recruitment agency, not the candidate and the agency. A recruiter wants to be able to say Look at the fine candidate I provided last time, you should always come to me first in future . There s a certain element of wanting the candidate to come back if/when they are looking for a new role, but it s not a primary concern. It is notable that the recommendations I d received were from people who had been on the hiring side of things. The recruiter has a vested interest in keeping the employer happy, in the hope of a sustained relationship. There is little motivation for keeping the candidate happy, as long as you don t manage to scare them off. And, in fact, if you scare some off, who cares? A recruiter doesn t get paid for providing the best possible candidate. Or indeed a candidate who will fully engage with the role. All they re required to provide is a hire-able candidate who takes the role. I m not sure what the resolution is to this. Word of mouth only scales so far for both employer and candidate. Many of the big job websites seem to be full of recruiters rather than real employers. And I m sure there are some decent recruiters out there doing a good job, keeping both sides happy and earning their significant cut. I m sad to say I can t foresee any big change any time soon. [Note I m not currently looking for employment.] [No recruitment agencies were harmed in the writing of this post. I have deliberately tried to avoid outing anyone in particular.]

As many (Debianic) people possibly know, the appindicator support (libindicator, libappindicator, etc.) in Debian is very weak and outdated. Various native indicators (e.g. indicator-* packages , where * is "datetime", "sound", "session", etc.) are missing or unmaintained in Debian and neither is the indicator-application service available (a service that allows other applications e.g., like the nm-applet tool to dock to the indicator area of the desktop's panel bar). Furthermore, no recent appindicator related uploads have been seen in Debian (last seen uploads are from 2013). I recently e-mailed with Andrew Starr-Bochicchio, one of the Ayatana Packaging team members, about the current Debian status of indicator packages specifically and Ayatana packages [1] in general. The below information summarizes (I hope) what I got from the mail exchange: read more

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.

I've been trying to run containers using systemd-nspawn for quite some time. I was always bumping to one or other dead end. This is not systemd-nspawn's fault, rather my impatience stopping me from reading manual pages properly lack of good tutorial like article available online. Compared to this LXC has a quite a lot of good tutorials and howto's available online. This article is my effort to create a notes putting all required information in one place.

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]

Andy (rattusrattus) on Video team sprint over the last few days with Ivo de Decker and Stefano Rovera

Background/Existing infrastructure/Why change? [DV/Firewire are EOL]
Things to do

1. Replace twinpact video slide capture system with something that can capture HDMI - better resolution,- digital all the way
Using a pre-production prototype at the moment. CCC also hoping to use this. All kit needs to go into one big box with sensible power supplies
2. Replace DVswitch
Better resolution, select sources, record all inputs, record all edits
Gstreamer based transport solution - import/output format agnostic
GST-Switch - possibly dead? VoctoMix looks more promising - CCC are testing this. First use in anger may be December
3. Improve streaming - single stream out. Encode stream on in-room hardware.
Sharing is a thing ... CCC workflow and setup are good - everyone should share technology. FOSDEM has 25 rooms ...
4 Replace/expand AV equipment
Workstation PC - SDI capture/video mixing/local record and encode
Laptop for remote UI
2 cameras
Opsis frame grabber
5 BoF Room recording - lots of options to handle differently
1 Operator maximum / preferably automated
Video conferencing camera / microphone setup
Frame grabber for slides / Gobby feed
6 Logistics
Organise equipment by room
Kit must be kept deployable
Quartermastering necessary
Checklists for each box
Set up a lab for development and release
DO NOT CHANGE ANYTHING ON THE PRODUCTION KIT

Lightning talks -

David McBride Scalable infrastructure package distribution - even more mad idea than last year for his scalable package distribution round University of Cambridge - npn

Iain Learmonth - Vmdebootstrap sprint report detailing the work from the Sprint on Thursday/Friday. Live-build-ng needs more unit testing, boot testing, documentation. Working now and some images have been built but still in progress http://vmdebootstrap.alioth.debian.org

Helen (elgriff) talking about her weird keyboard
Repetittive strain injuries, carpal tunnel injuries.
Extensive computer use / brass instrument playing AND ignoring pain doing the above. Dont do this.
Vertical keyboards - SafeType and Yogitype.
You should care. If it hurts stop.You don't come with a five year warranty

Stefano Rovera (stefanor) - SVN-Git migration. Debian Python migration team did this for hundreds of packages. "Subversion is really, really evil - it's more evil than you thought"

Sledge - Update on ARM ports. Three ports - armel - older hardware. Armhf - ARMv7 hard float ABI. ARM64 / aarch64 - in Jessie - mostly working. Bits and pieces to be done. Over time, requirements have gone up and there are bits and pieces to work on. For the oldest machines in armel there's an amount of work to do - port may not survive beyond stretch: manpower / people who care is critical.

Just had a really good couple of sessions: one from the DPL including Q&A, then a good overview of reproducible builds and where we are today from Holger Levsen (h0lger) and Chris Lamb (lamby)

Then a 2 minute silence at 11.00 as is customary in the UK on this date.

Now Lucy Wayland - who says she has a brainful of IEEE754 from a few years ago working on safety-critical systems so she's unburdening by sharing with all of us - everything you wanted to know about floating point but were afraid to ask (and including a primer on signed/unsigned and fixed point as part of the explanation)

Steve Capper's Java presentation is unfortunately not going to take place, so this afternoon's live stream schedule will be different.

Coffee going down well.

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.