Update: I was able to get in touch with the Googlers responsible for the dl.google.com service, and the root cause for the mismatched signature problem described below has been found and fixed. I now consistently receive from Google's servers Release and Release.gpg files that pass apt's signature validation on my home connection. Google publishes Linux software repositories for several of their products, including Google Chrome, which is available from the following apt source:

deb http://dl.google.com/linux/chrome/deb/ stable main

These repositories are signed with an 8 year old 1024-bit DSA key:

pub   1024D/7FAC5991 2007-03-08
      Key fingerprint = 4CCA 1EAF 950C EE4A B839  76DC A040 830F 7FAC 5991
uid                  Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>
sub   2048g/C07CB649 2007-03-08

Asymmetric 1024-bit keys are not considered strong enough and were, for instance, aggressively retired from Google's SSL frontends almost two years ago. Such short keys should not be used to protect the integrity of software package repositories. Note that this key has a longer 2048-bit ElGamal subkey, which is not actually used to produce signatures, but only for encryption. In fact, only a signing key is needed to sign the files in a secure apt repository, and, for instance, the archive keys used to sign official debian.org repositories do not contain an encryption subkey. Since years, many users have reported an error message like the following when running apt-get update:

W: GPG error: http://dl.google.com stable Release: The following signatures were
invalid: BADSIG A040830F7FAC5991 Google, Inc. Linux Package Signing Key
<linux-packages-keymaster@google.com>

This error might resolve itself if apt-get update is run again. Apparently, this is due to "bad pushes" occurring in the Google infrastructure. An example of this can be seen in the following curl output:

$ curl -v http://dl.google.com/linux/chrome/deb/dists/stable/Release \
        http://dl.google.com/linux/chrome/deb/dists/stable/Release.gpg
* Hostname was NOT found in DNS cache
*   Trying 74.125.196.136...
* Connected to dl.google.com (74.125.196.136) port 80 (#0)
> GET /linux/chrome/deb/dists/stable/Release HTTP/1.1
> User-Agent: curl/7.38.0
> Host: dl.google.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 1347
< Content-Type: application/octet-stream
< Etag: "518b8"
< Expires: Sun, 22 Mar 2015 18:55:19 PDT
< Last-Modified: Fri, 20 Mar 2015 04:22:00 GMT
* Server downloads is not blacklisted
< Server: downloads
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Xss-Protection: 1; mode=block
< Date: Sun, 22 Mar 2015 01:55:19 GMT
< Alternate-Protocol: 80:quic,p=0.5
< 
Origin: Google, Inc.
Label: Google
Suite: stable
Codename: stable
Version: 1.0
Date: Thu, 19 Mar 2015 22:55:29 +0000
Architectures: amd64 i386
Components: main
Description: Google chrome-linux repository.
MD5Sum:
 53375c7a2d182d85aef6218c179040ed 144 main/binary-i386/Release
 c556daf52ac818e4b11b84cb5943f6e0 4076 main/binary-i386/Packages
 867ba456bd6537e51bd344df212f4662 960 main/binary-i386/Packages.gz
 2b766b2639b57d5282a154cf6a00b172 1176 main/binary-i386/Packages.bz2
 89704f9af9e6ccd87c192de11ba4c511 145 main/binary-amd64/Release
 fa88101278271922ec9b14b030fd2423 4082 main/binary-amd64/Packages
 1ba717117027f36ff4aea9c3ea60de9e 962 main/binary-amd64/Packages.gz
 19af18f376c986d317cadb3394c60ac5 1193 main/binary-amd64/Packages.bz2
SHA1:
 59414c4175f2cc22e67ba6c30687b00c72a7eafc 144 main/binary-i386/Release
 1764c5418478b1077ada54c73eb501165ba79170 4076 main/binary-i386/Packages
 db24eafac51d3e63fd41343028fb3243f96cbed6 960 main/binary-i386/Packages.gz
 ad8be07425e88b2fdf2f6d143989cde1341a8c51 1176 main/binary-i386/Packages.bz2
 153199d8f866350b7853365a4adc95ee687603dd 145 main/binary-amd64/Release
 7ce66535b35d5fc267fe23af9947f9d27e88508b 4082 main/binary-amd64/Packages
 a72b5e46c3be8ad403df54e4cdcd6e58b2ede65a 962 main/binary-amd64/Packages.gz
 dbc7fddd28cc742ef8f0fb8c6e096455e18c35f8 1193 main/binary-amd64/Packages.bz2
* Connection #0 to host dl.google.com left intact
* Found bundle for host dl.google.com: 0x7f24e68d06a0
* Re-using existing connection! (#0) with host dl.google.com
* Connected to dl.google.com (74.125.196.136) port 80 (#0)
> GET /linux/chrome/deb/dists/stable/Release.gpg HTTP/1.1
> User-Agent: curl/7.38.0
> Host: dl.google.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 198
< Content-Type: application/octet-stream
< Etag: "518f4"
< Expires: Sun, 22 Mar 2015 18:55:19 PDT
< Last-Modified: Fri, 20 Mar 2015 04:05:00 GMT
* Server downloads is not blacklisted
< Server: downloads
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Xss-Protection: 1; mode=block
< Date: Sun, 22 Mar 2015 01:55:19 GMT
< Alternate-Protocol: 80:quic,p=0.5
< 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAlULm7YACgkQoECDD3+sWZFyxACeNPuK/zQ0v+3Py1n2s09Wk/Ti
DckAni8V/gy++xIinu8OdUXv7c777V9H
=5vT6
-----END PGP SIGNATURE-----
* Connection #0 to host dl.google.com left intact

Note that both the Release and Release.gpg files were fetched with the same HTTP connection, so the two files must have come from the same web frontend. (Though, it is possible they were served by different backends.) However, the detached signature in Release.gpg does not match the content in Release:

gpgv: Signature made Fri 20 Mar 2015 12:01:58 AM EDT using DSA key ID 7FAC5991
gpgv: BAD signature from "Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>"

Performing the same pair of fetches again, the same Release.gpg file is returned, but the Release file is slightly different:

$ curl -v http://dl.google.com/linux/chrome/deb/dists/stable/Release \
        http://dl.google.com/linux/chrome/deb/dists/stable/Release.gpg
* Hostname was NOT found in DNS cache
*   Trying 74.125.196.136...
* Connected to dl.google.com (74.125.196.136) port 80 (#0)
> GET /linux/chrome/deb/dists/stable/Release HTTP/1.1
> User-Agent: curl/7.38.0
> Host: dl.google.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 1347
< Content-Type: application/octet-stream
< Etag: "518f3"
< Expires: Sun, 22 Mar 2015 18:55:04 PDT
< Last-Modified: Fri, 20 Mar 2015 04:05:00 GMT
* Server downloads is not blacklisted
< Server: downloads
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Xss-Protection: 1; mode=block
< Date: Sun, 22 Mar 2015 01:55:04 GMT
< Alternate-Protocol: 80:quic,p=0.5
< 
Origin: Google, Inc.
Label: Google
Suite: stable
Codename: stable
Version: 1.0
Date: Fri, 20 Mar 2015 04:02:02 +0000
Architectures: amd64 i386
Components: main
Description: Google chrome-linux repository.
MD5Sum:
 89704f9af9e6ccd87c192de11ba4c511 145 main/binary-amd64/Release
 fa88101278271922ec9b14b030fd2423 4082 main/binary-amd64/Packages
 1ba717117027f36ff4aea9c3ea60de9e 962 main/binary-amd64/Packages.gz
 19af18f376c986d317cadb3394c60ac5 1193 main/binary-amd64/Packages.bz2
 53375c7a2d182d85aef6218c179040ed 144 main/binary-i386/Release
 c556daf52ac818e4b11b84cb5943f6e0 4076 main/binary-i386/Packages
 867ba456bd6537e51bd344df212f4662 960 main/binary-i386/Packages.gz
 2b766b2639b57d5282a154cf6a00b172 1176 main/binary-i386/Packages.bz2
SHA1:
 153199d8f866350b7853365a4adc95ee687603dd 145 main/binary-amd64/Release
 7ce66535b35d5fc267fe23af9947f9d27e88508b 4082 main/binary-amd64/Packages
 a72b5e46c3be8ad403df54e4cdcd6e58b2ede65a 962 main/binary-amd64/Packages.gz
 dbc7fddd28cc742ef8f0fb8c6e096455e18c35f8 1193 main/binary-amd64/Packages.bz2
 59414c4175f2cc22e67ba6c30687b00c72a7eafc 144 main/binary-i386/Release
 1764c5418478b1077ada54c73eb501165ba79170 4076 main/binary-i386/Packages
 db24eafac51d3e63fd41343028fb3243f96cbed6 960 main/binary-i386/Packages.gz
 ad8be07425e88b2fdf2f6d143989cde1341a8c51 1176 main/binary-i386/Packages.bz2
* Connection #0 to host dl.google.com left intact
* Found bundle for host dl.google.com: 0x7ffa33d8b6a0
* Re-using existing connection! (#0) with host dl.google.com
* Connected to dl.google.com (74.125.196.136) port 80 (#0)
> GET /linux/chrome/deb/dists/stable/Release.gpg HTTP/1.1
> User-Agent: curl/7.38.0
> Host: dl.google.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 198
< Content-Type: application/octet-stream
< Etag: "518f4"
< Expires: Sun, 22 Mar 2015 18:55:05 PDT
< Last-Modified: Fri, 20 Mar 2015 04:05:00 GMT
* Server downloads is not blacklisted
< Server: downloads
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Xss-Protection: 1; mode=block
< Date: Sun, 22 Mar 2015 01:55:05 GMT
< Alternate-Protocol: 80:quic,p=0.5
< 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAlULm7YACgkQoECDD3+sWZFyxACeNPuK/zQ0v+3Py1n2s09Wk/Ti
DckAni8V/gy++xIinu8OdUXv7c777V9H
=5vT6
-----END PGP SIGNATURE-----
* Connection #0 to host dl.google.com left intact

Note that the Date line in the Release file is different:

@@ -6 +6 @@
-Date: Thu, 19 Mar 2015 22:55:29 +0000
+Date: Fri, 20 Mar 2015 04:02:02 +0000

The file hashes listed in the Release file are in a different order, as well, though the actual hash values are the same. This Release file does have a valid signature:

gpgv: Signature made Fri 20 Mar 2015 12:01:58 AM EDT using DSA key ID 7FAC5991
gpgv: Good signature from "Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>"

Note that the Release.gpg files in the good and bad cases are the same, and the same signature cannot cover two files with different content. Also note that the same mis-signed content is available via HTTPS, so it is probably not caused by a MITM attack. The possibility of skew between the Release and Release.gpg files is precisely why inline signed Release files were introduced, but Google's repositories use only the older format with a detached signature. It would be nice if Google could fix the underlying bug in their infrastructure that results in mis-signed repositories being published frequently, because it trains users to ignore cryptographic failures.

One of fresh additions to Debian, that is showing Debian's commitment to diversity in all fields is Laura Arjona Reina. A helpful hand on channels and a great flux of FLOSS energy she brings with herself. Although applied for non-packaging Debian Developer status, Laura does recognize that there are still some technical aspects what must grasp on. Her dedication to FLOSS and trying to solve some of its issues is astonishing, as this woman is doing a lot of self-hosting and system administration. Yes, you read it right - she does all of that and still applied for non-packaging Debian Developer. She is perfect example how FLOSS enhances humans in many ways. Hello Laura. Who are you? I am Laura Arjona, I work as IT assistant at Technic University of Madrid, I am married and I have a son, and I use and promote free (libre) software both at job and at home and with friends. I have a nice time contributing in Debian and other FLOSS projects but I always want to do more than what I manage to actually do (I hope I can improve that, as time goes by... and maybe when I get retired I am the SuperLArjona that you wrote about!). What parts of FLOSS community are you engaged? I use Debian, and CyanogenMod + F-Droid in my phone. I coordinate the translation of the Debian website into Spanish, help with FSFE website translation too, and translate some other free software (GNU MediaGoblin, F-Droid, Android apps that I use, web services that we use at work...). I use and promote some free social networks: pump.io, GNU Social, and XMPP. My work/friends environment is mostly Windows/Android so I try to find/promote libre software replacements or interesting applications for them. I give free FLOSS stickers to everybody showing interest for libre software, and a nice Debian sticker if they finally install it in their computers. Setup of your main machine? My machine is a humble Compaq Mini 110C laptop (32bits, Atom N270@1.60GHz, 1GB RAM) and I have Debian Jessie (future-stable ATM) with xfce on it. I'm not tied to particular tools, for example I use Mousepad for editing here in my xfce, Kate in my desktop at work, nano in the server. The only "tuning" that I always do is to set a dark background for terminals and text editors, but I don't even switch to a desktop dark theme... (BTW I love Jessie's theme, "Lines"!). I know there are awesome pieces of software out there (hey emacs-org-mode!), but I just don't have fun having to learn them by myself (no LUG near, I'm afraid...). Some memorable moments from Debian conferences? I've only been at Barcelona MiniDebConf Women 2014 and it was great. It was memorable that I promoted the keysigning for that MiniDebConf, and came home with lots of signatures and papers to verify and sign... and then I was not remembering my GPG main key passphrase! so I hid under my desk for two months, and then, decided to start again (created a new key and tried to meet some Debian people in Madrid...). So I guess I should go to some (Mini)DebConf again. You are currently involved in process of becoming non-packaging Debian Developer - what made you take that step? I began translating in 2011, and since then, I enjoyed contributing in Debian (women, l10n-es, website, publicity). I'm quite regular with the translation work, and applying for DD is a plan to 'force' myself to find chunks of time to contribute more in the other areas too. I also believe that applying I may help other people to also apply or get more involved or become more visible. So here I am. Although you applied for non-packaging Debian Developer you recognize that there is still a technical learning curve in Debian even for that - what are the technical aspects a non-Developer should grasp? Well, I suppose it depends on the area you are contributing. In Publicity you find repositories in git (bits.debian.org), and subversion (Debian Project News). The website uses CVS (www.debian.org)... So you need the basics of 3 different version control systems to commit your changes (or send them to the mailing list and wait somebody to commit them). We use a mail robot to coordinate the translation work, so you need to write the subject with a certain format, and some people complains when somebody send mail in HTML (plain text is preferred). There are some other tools such as IRC and GPG that I began using just for contributing to Debian. Once that you learn them a bit and you learn how Debian works, you understand they are the great tools and you get in love (hey meetbot and KGB! hey i18n.debian.org!), but I wonder how people with no technical background, or even Computer Engineering students nowadays, accostumed to instant messaging in the mobile, fancy web interfaces and so on, look at these tools and just don't even try. How do you see future of Debian development? I don't know, Debian is huge... Some areas in which I hope we, as a community, find the way to work more: packaging (or help configuring) web applications or network services, provide LTS support, and keep on improving outreach/diversity. What are your future plans in Debian, what would you like to work on? In the Spanish team area, my plan is to go on translating the website, jump more often into translating package descriptions too, and help first-time-contributors to keep themselves involved. In the website and publicity teams, I hope I manage to put some weekly time to help with pending tasks/bugs, and serve as liaison with the other areas in which I'm involved (women, l10n, contributors...). If I become DD, I would like to create/adopt some data sources for contributors.debian.org, or convince people to do it I'm not sure if I will be able to attend DebConf some year; meanwhile, at least, I'll continue trying to help with the blog and promotion (as -publicity-team member). Why should developers and users join Debian community? What makes Debian a great and happy place? For using it: the desktop experience has improved very much in the last years, there's a clear separation between free and non-free software so the Debian users always know where are we, and there is wide documentation (in English, at least. Probably in other languages too). For getting involved: I like very much that you can lurk what almost everybody does: just join some mailing lists or IRC channels, the Debian people work in the open. So you know a bit where are you jumping in. Later you learn that everything is easier than what was looking from the outside, because you make friends and with friends everything is better.
Contributions made to Debian have many chances to reach a very wide community: Debian users, upstream projects, and the hundreds of derivatives. It's a quite horizontal, decentralized organization (that has its downsides too, but I can live with them). Is there something you would change in FLOSS ecosystem? We need much more internationalization and localization efforts. People don't need English for using libre software nowadays in their desktop, it's one of our big strenghts, but they definitely need English for using libre software for Android, or solving problems with the libre software they use in your computers/devices, or to contribute to any community. I think we need more local groups for user support/outreach, more libre-software-based translation tools and online services (replacements for Google Translator, for Transifex...),and more internationalization and localization efforts (manuals, websites... not only the software itself). If we work hard in this area, we'll gain much more users and much more contributors. Why does privacy matter to you? I have a son, at our family we interchange photos, and sometimes I have private conversations using the smartphone, mail or other internet services. I want to have the chance that the day that I (or my family) need privacy, we can have it easily. And I want that the people that really need privacy today, have proper tools at their hand. So I try to use PGP, selfhost my multimedia website, use decentralized, free software based networks and XMPP mobile apps... to help those projects to thrive. I try do my part of the network effect! You are being upset with rise of Github - why is that and what would change would you like to see? I totally agree with Mako's essay "Free software needs free tools". Yes, many nonfree web services are easier and have better features right now, but the key is that only dogfooding can change that, the same like changed it with the GNU/Linux desktop and Open/LibreOffice for example...
I would like to see more people trying to selfhost, use and promote libre software based forges, so in addition to avoid vendor lock in and win consistency in our discourse, we polish the available tools and eventually win the battle also in the technical side. You are hosting yours own instances of Mediagoblin - as it is not officially packaged in Debian yet, how do you manage it and how would you encourage others to do it? I followed the MediaGoblin documentation for its last stable release, and hanged on the IRC channel when in doubts/problems. It was not so hard, because it's well documented for Debian systems, and most of the dependencies are already packaged (in stable and testing). MediaGoblin is in its way to stretch too (thanks simonft and the rest of people working on this!). I'm documenting my adventures with selfhosting in [my blog (http://larjona.wordpress.com), but I need to write more often, and put more time in my small server (now I try to selfhost my git projects with cgit, and I want to setup an XMPP server and Etherpad Lite too). You are trying to resolve with self-hosting personal issues with services such as WhatsUp and other non-free parts of our everyday lives- what issues are you hitting on during your way and how do you resolve them? "#iloveemail", but people don't love it anymore, it seems... I've researched a bit about instant messaging to try to propose alternatives to WhatsApp to my family and friends. It seems Conversations with a community XMPP server where to create multi user chat rooms can be a replacement, so my plan is to try during this year. Meanwhile, I've setup the MediaGoblin site so I upload the photos there instead of sending them with the phone, and for the 1-to-1 chat I try to move people to Kontalk (instant messaging, GPG, photos, voice notes...). For the videocalls, I promote Jitsi or just point people to meet.jit.si/FancyNameofChatRoom. I have account and owndrive.com and will try to host Owncloud too. We'll see what happens. You are interested in radio shows - what drives you into that field and will we see soon any podcasts from Laura? I like to talk and I'm not a shy person, so the few times that in any of my social groups there was a chance to "talk in the radio", I volunteered and enjoyed. This has been, in my life, 6 or 7 times (in Spanish, talking about social activism or politics. No records, though!). Some months ago the people of "El Binario" invited me to talk at "findenegro" about pump.io and free networks (in Spanish), I accepted and had a very nice time (audios in my mediagoblin). I wish I have more free time to listen to podcasts and maybe to join some other people to participate in a program in a regular basis. OTOH, my son asks for a tale almost each day... I follow one of Gianni Rodari "The grammar of fantasy"'s approach: take some day-to-day facts and add something unexpected and crazy, and tailor a short story. Maybe I could record them and publish in my MediaGoblin... Of course their literary quality is not even near to Gianni Rodari's but people that listened to them when I was storytelling (in the metro, my mother at home, some friends...) say they are fun and interesting. Who knows!

Notice: There were several requests for me to more elaborate on my path to Debian and impact on life so here it is. It's going to be a bit long so anyone who isn't interested in my personal Debian journey should skip it. :) In 2007. I enrolled into Faculty of Mechanical Engineering (at first at Department of Industrial Management and later transfered to Department of Mechatronics - this was possible because first 3 semesters are same for both departments). By the end of same year I was finishing my tasks (consisting primarily of calculations, some small graphical designs and write-ups) when famous virus, called by users "RECYCLER", sent my Windows XP machine into oblivion. Not only it took control over machine and just spawned so many processes that system would crash itself, it actually deleted all from hard-disk before it killed the system entirely. I raged - my month old work, full of precise calculations and a lot of design details, was just gone. I started cursing which was always continued with weeping: "Why isn't there an OS that can whithstand all of viruses, even if it looks like old DOS!". At that time, my roommate was my cousin who had used Kubuntu in past and currently was having SUSE dual-booted on his laptop. He called me over, started talking about this thing called Linux and how it's different but de facto has no viruses. Well, show me this Linux and my thought was, it's probably so ancient and not used that it probably looks like from pre Windows 3.1 era, but when SUSE booted up it had so much more beautiful UI look (it was KDE, and compared to XP it looked like the most professional OS ever). So I was thrilled, installed openSUSE, found some rough edges (I knew immediately that my work with professional CAD systems will not be possible on Linux machines) but overall I was bought. After that he even talked to me about distros. Wait, WTF distros?! So, he showed me distrowatch.com. I was amazed. There is not only a better OS then Windows - there where dozens, hundreds of them. After some poking around I installed Debian KDE - and it felt great, working better then openSUSE but now I was as most newbies, on fire to try more distros. So I was going around with Fedora, Mandriva, CentOS, Ubuntu, Mint, PCLinuxOS and in beginning of 2008 I stumbled upon Debian docs which where talking about GNU and GNU Manifesto. To be clear, I was always as a high-school kid very much attached to idea of freedom but started loosing faith by faculty time (Internet was still not taking too much of time here, youth still spent most of the day outside). So the GNU Manifesto was really a big thing for me and Debian is a social bastion of freedom. Debian (now with GNOME2) was being installed on my machine. As all that hackerdom in Debian was around I started trying to dig up some code. I never ever read a book on coding (until this day I still didn't start and finish one) so after a few days I decided to code tetris in C++ with thought that I will finish it in two days at most (the feeling that you are powerful and very bright person) - I ended it after one month in much pain. So instead I learned about keeping Debian system going on, and exploring some new packages. I got thrilled over radiotray, slimvolley (even held a tournament in my dorm room), started helping on #debian, was very active in conversation with others about Debian and even installed it on few laptops (I became de facto technical support for users of those laptops :D ). Then came 2010 which with negative flow that came in second half of 2009, started to crush me badly. I was promised to go to Norway, getting my studies on robotics and professor lied (that same professor is still on faculty even after he was caught in big corruption scandal over buying robots - he bought 15 years old robots from UK, although he got money from Norway to buy new ones). My relationship came to hard end and had big emotional impact on me. I fell a year on faculty. My father stopped financing me and stopped talking to me. My depression came back. Alcohol took over me. I was drunk every day just not to feel anything. Then came the end of 2010, I somehow got to the information that DebConf will be in Banja Luka. WHAT?! DebConf in city where I live. I got into #debconf and in December 2010/January 2011 I became part of the famous "local local organizers". I was still getting hammered by alcohol but at least I was getting out of depression. IIRC I met Holger and Moray in May, had a great day (a drop of rakia that was too much for all of us) and by their way of behaving there was something strange. Beatiful but strange. Both were sending unique energy of liberty although I am not sure they were aware of it. Later, during DebConf I felt that energy from almost all Debian people, which I can't explain. I don't feel it today - not because it's not there, it's because I think I integrated so much into Debian community that it's now a natural feeling which people here, that are close to me are saying that they feel it when I talk about Debian. DebConf time in Banja Luka was awesome - firstly I met Phil Hands and Andrew McMillan which were a crazy team, local local team was working hard (I even threw up during the work in Banski Dvor because of all heat and probably not much of sleep due to excitement), met also crazy Mexican Gunnar (aren't all Mexicans crazy?), played Mao (never again, thank you), was hanging around smart but crazy people (love all) from which I must notice Nattie (a bastion of positive energy), Christian Perrier (which had coordinated our Serbian translation effort), Steve Langasek (which asked me to find physiotherapist for his co-worker Mathias Klose, IIRC), Zach (not at all important guy at that time), Luca Capello (who gifted me a swirl on my birthday) and so many others that this would be a post for itself just naming them. During DebConf it was also a bit of hard time - my grandfather died on 6th July and I couldn't attend the funeral so I was still having that sadness in my heart, and Darjan Prtic, a local team member that came from Vienna, committed suicide on my birthday (23 July). But DebConf as conference was great, but more importantly the Debian community felt like a family and Meike Reichle told me that it was. The night it finished, me and Vedran Novakovic cried. A lot. Even days after, I was getting up in the morning having the feeling I need something to do for DebConf. After a long time I felt alive. By the end of year, I adopted package from Clint Adams and Moray became my sponsor. In last quarter of 2011 and beginning of 2012, I (as part of LUG) held talks about Linux, had Linux installation in Computer Center for the first time ever, and installed Debian on more machines. Now fast forwarding with some details - I was also on DebConf13 in Switzerland, met some great new friends such as Tincho and Santiago (and many many more), Santiago was also my roommate in Portland on the previous DebConf. In Switzerland I had really great and awesome time. Year 2014 - I was also at DebConf14, maintain a bit more packages and have applied for DD, met some new friends among which I must put out Apollon Oikonomopoulos and Costas Drogos which friendship is already deep for such a short time and I already know that they are life-long friends. Also thanks to Steve Langasek, because without his help I wouldn't be in Portland with my family and he also gave me Arduino. :) 2015. - I am currently at my village residence, have a 5 years of working experince as developer due to Debian and still a lot to go, learn and do but my love towards Debian community is by magnitude bigger then when I thought I love it at most. I am also going through my personal evolution and people from Debian showed me to fight for what you care, so I plan to do so. I can't write all and name all the people that I met, and believe me when I say that I remember most and all of you impacted my life for which I am eternally grateful. Debian, and it's community effect literally saved my life, spring new energy into me and changed me for better. Debian social impact is far bigger then technical, and when you know that Debian is a bastion of technical excellence - you can maybe picture the greatness of Debian. Some of greatest minds are in Debian but most important isn't the sheer amount of knowledge but the enormous empathy. I just hope I can in future show to more people what Debian is and to find all lost souls as me to give them the hope, to show them that we can make world a better place and that everyone is capable to live and do what they love. P.S. I am still hoping and waiting to see Bdale writing a book about Debian's history to this day - in which I think many of us would admire the work done by project members, laugh about many situations and have fun reading a book about project that was having nothing to do but fail and yet it stands stronger then ever with roots deep into our minds.

I've run OpenWRT on my home router for a long time, and these days I maintain a couple of packages for the project. In order to make most efficient use of the hardware resources on my router, I run a custom build of the OpenWRT firmware with some default features removed and others added. For example, I install bind and ipsec-tools, while I disable the web UI in order to save space. There are quite a few packages required for the OpenWRT build process. I don't necessarily want all of these packages installed on my main machine, nor do I want to maintain a VM for the build environment. So I investigated using Docker for this. Starting from a base jessie image, which I created using the Docker debootstrap wrapper, the first step was to construct a Dockerfile containing instructions on how to set up the build environment and create a non-root user to perform the build:

FROM jessie:latest
MAINTAINER Noah Meyerhans <frodo@morgul.net>
RUN DEBIAN_FRONTEND=noninteractive apt-get update && apt-get -y install \
asciidoc bash bc binutils bzip2 fastjar flex git-core g++ gcc
util-linux gawk libgtk2.0-dev intltool jikespg zlib1g-dev make \
genisoimage libncurses5-dev libssl-dev patch perl-modules \
python2.7-dev rsync ruby sdcc unzip wget gettext xsltproc \
libboost1.55-dev libxml-parser-perl libusb-dev bin86 bcc sharutils \
subversion
RUN adduser --disabled-password --uid 1000 --gecos "Docker Builder,,," builder

And we generate a docker image based on this Dockerfile per the docker build documentation. At this point, we've got a basic image that does what we want. To initialize the build environment (download package sources, etc), I might run: docker run -v ~/src/openwrt:/src/openwrt -u builder -t -i jessie/openwrt sh -c "cd /src/openwrt/openwrt && scripts/feeds update -a" Or configure the system: docker run -v ~/src/openwrt:/src/openwrt -u builder -t -i jessie/openwrt make -C /src/openwrt/openwrt menuconfig And finally, build the OpenWRT image itself: docker run -v ~/src/openwrt:/src/openwrt -u builder -t -i jessie/openwrt make -C /src/openwrt/openwrt -j3 The -v ~/src/openwrt:/src/openwrt flags tell docker to bind mount my ~/src/openwrt directory (which I'd previously cloned using git) to /src/openwrt inside the running container. Without this, one might be tempted to clone the git repo directly into the container at runtime, but the changes to non-bind-mount filesystems are lost when the container terminates. This could be suitable for an autobuild environment, in which the sources are cloned at the start of the build and any generated artifacts are archived externally at the end, but it isn't suitable for a dev environment where I might be making and testing small changes at a relatively high frequency. The -u builder flags tell docker to run the given commands as the builder user inside the container. Recall that builder was created with UID 1000 in the Dockerfile. Since I'm storing the source and artifacts in a bind-mounted directory, all saved files will be created with this UID. Since UID 1000 happens to be my UID on my laptop, this is fine. Any files created by builder inside the container will be owned by me outside the container. However, this container should not have to rely on a user with a given UID running it! I'm not sure what the right way to approach this problem is within Docker. It may be that someone using my image should create their own derivative image that creates a user with the appropriate UID (creation of this derivative image is a cheap operation in Docker). Alternatively, whatever Docker init system is used could start as root, add a new user with a specific UID, and execute the build commands as that new user. Neither of these seems as clean as it could be, though. In general, Docker seems quite useful for such a build environment. It's easy to set up, and it makes it very easy to generate and share a common collection of packages and configuration. Because images are self-contained, I can reclaim a bunch of disk space by simple executing "docker rmi".

The organization of DebConf15 (from 15 to 22 August 2015, in Heidelberg, Germany) is going smoothly, the call for proposals is open and today we want to provide some updates about our sponsors. Twelve more companies have joined our nine first sponsors in supporting DebConf15. Thank you to all of them! Our third Gold sponsor is the Matanel Foundation, which encourages social entrepreneurship in all over the world. IBM, the technology and consulting corporation, has also joined the DebConf15 sponsorship at a Gold level. Google, the search engine and advertising company, has increased its sponsorship level from Silver to Gold. Mirantis, 1&1 (which is also one of Debian's service partners), MySQL and Hudson River Trading have committed sponsorship at Silver level. And last but not least, six more sponsors have agreed to support us at Bronze level: Godiug.net, the University of Zurich, Deduktiva, Docker, DG-i (which is also one of Debian's service partners), and PricewaterhouseCoopers (which also provides consultancy support for DebConf15). The DebConf15 team is very thankful to all the DebConf sponsors for their support. Become a sponsor too! DebConf15 is still accepting sponsors. Interested companies and organizations may contact the DebConf team through sponsors@debconf.org, and visit the DebConf15 website at http://debconf15.debconf.org.

Like each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In February, 58 work hours have been equally split among 4 paid contributors. Their reports are available:

• Ben Hutchings
• Holger Levsen (though he did only 9h out of the 14.5h allocated, he will have to catch up in March)
• Rapha l Hertzog
• Thorsten Alteholz

Evolution of the situation During the last month, we gained 3 paid work hours: we re now at 61 hours per month sponsored by 28 organizations and we have one supplementary sponsor in the pipe that should bring 4 more hours. The increase is not very quick but seems to be steady. Hopefully at some point, we will have enough resources to do a more exhaustive job. For now, the paid contributors handle in priority the most popular packages used by the sponsors and there are some packages in the end of the queue which have open security issues for months already (example: CVE-2012-6685 on libnokogiri-ruby). So, as usual, we are looking for more sponsors. In terms of security updates waiting to be handled, the situation looks a little bit worse than last month: the dla-needed.txt file lists 40 packages awaiting an update (3 more than last month), the list of open vulnerabilities in Squeeze shows about 58 affected packages in total (5 less than last month). We are getting a bit more effective with CVE triage. A logo for the LTS project? Every time that I write an LTS report, I remember that it would be nice if my LTS related articles could feature a nice picture/logo that reminds people of the LTS team/initiative. Is there anyone up for the challenge of creating that logo? Thanks to our sponsors The new sponsors of the month are in bold.

• Gold sponsors:
• The Positive Internet
• Silver sponsors:
• AD&D David Ayers IntarS Austria
• Blablacar
• Domeneshop AS
• Evolix
• Gandi SAS
• Trollweb Solutions
• Universit Lille 3
• Bronze sponsors:
• Bitfolk LTD
• Daevel SARL
• FOSSter
• Freeside Internet Service
• Gree, Inc.
• Greenbone Networks GmbH
• Intevation GmbH
• Linuxhotel GmbH
• Megaspace Internet Services GmbH
• MyTux
• NUMLOG
• Nantes M tropole
• Offensive Security
• Seznam.cz, a.s.
• WinGo AG

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

We'd like to reshare a post from Nicolas Dandrimont. Hi all, I am delighted to announce that Debian will be participating in the next round of Outreachy and GSoC, and that we are currently welcoming applications! Outreachy helps people from groups underrepresented in free and open source software get involved. The current round of internships is open to women (cis and trans), trans men, genderqueer people, and all participants of the Ascend Project regardless of gender. Google Summer of Code is a global program, sponsored by Google, that offers post-secondary student developers ages 18 and older stipends to write code for various open source software projects. Interns for both programs are granted a $5500 stipend (in three installments) allowing them to dedicate their summer to working full-time on Debian. Our amazing team of mentors has listed their project ideas on the Debian wiki, and we are now welcoming applicants for both programs. If you want to apply for an internship with Debian this summer, please fill out the template for either Outreachy or GSoC. If you re eligible to both programs, we ll encourage you to apply to both (using the same application), as Debian only has funds for a single Outreachy intern this round. Don t wait up! The application period for Outreachy ends March 24th, and the GSoC application period ends March 27th. We really want applicants to start contributing to their project before making our selection, so that mentors can get a feel of how working with their intern will be like for three months. The small task is a requirement for Outreachy, and we re strongly encouraging GSoC applicants to abide by that rule too. To contribute in the best conditions, you shouldn t wait for the last minute to apply :-) I hope we ll work with a lot of great interns this summer. If you think you re up for the challenge, it s time to apply! If you have any doubts, or any question, drop us a line on the soc-coordination mailing list or come by on our IRC channel (#debian-soc on irc.debian.org) and we ll do our best to guide you.

Wow, it's been quite a long time since I've posted something here. Everything is going well -- I'm just very, very engrossed with the new job, since I'm still in exponential ramp-up mode. It's lasting for longer than I expected, although my expectations didn't have much basis since this is the first time I've started a new job in 17 years. I'm feeling more and more capable every day, but the combination of a very heavily social learning process, a lot of new technical areas to learn, and not having taken a vacation since last June means that my weekends are spent just passively watching things and zoning. Not sure yet how long that will last, and I don't want to make any predictions, although I do have my first significant vacation coming up next month. Anyway, book reading and buying has continued, although I'm again far behind on writing reviews. With luck, I'll be writing one of those (for posting later) right after writing this post. Michelle Alexander The New Jim Crow (non-fiction)
Elizabeth Bear Karen Memory (sff)
Becky Chambers The Long Way to a Small, Angry Planet (sff)
Fred Clark The Anti-Christ Handbook (non-fiction)
Charles de Lint The Very Best of Charles de Lint (sff)
S.L. Huang A Neurological Study on the Effects... (sff)
S.L. Huang Half Life (sff)
Kameron Hurley The Mirror Empire (sff)
Sophie Lack Dissonance (sff)
Sophie Lack Imbalance (sff)
Susan R. Matthews An Exchange of Hostages (sff)
Kaoru Mori A Bride's Story #1 (graphic novel)
Donald Shoup The High Cost of Free Parking (non-fiction)
Jo Walton The Just City (sff) Pretty nice variety of different stuff from a huge variety of recommendation sources. I've already read the Chambers (and can recommend it). A review will be forthcoming.

0. Who are you and what is your history with Debian Project? I guess this part is well covered in my platform. 1. What is your most proud moment as Debian Developer? I am pretty proud of having been part of the few who implemented the first automatic dependency resolver for OCaml programs and libraries in Debian packages. It was really the first one in the OCaml community and we were quite proud of it. But that was done before I become a Debian Developer. As a DD, I have to admit I am quite proud to be part of the Release Team. It is a fantastic team where there is so much to do. Helping the team means something to me, and I invested a considerable amount of time (a few months) working on reviewing patches for Squeeze and helping to get it ready by our standards. My best moment was Squeeze's release, my first Debian release as Release Team member. 2. In your opinion what is the strongest part of Debian Project? I am not sure we can identify one single strength of the Debian project. But, when I think about your question, I remember something I've heard many times: Debian is about people . I have to admit that I didn't realize it myself until I heard it for the first time and I completely share the idea! For me, all the technical side of the project comes after the community. With time, I think we managed to build a strong community. Many contributors became friends with time. We are seeing many Developers having babies and bringing them to Debian events. I find that really amazing. 3. And what is the weakest part of Debian Project? Our strength is somehow also our weakness. We are humans and make mistakes. We have feelings and some discussions get heated sometimes. It is not easy to keep everyone calm and focused. We have seen the damage that was caused to our core community last year with all the flamewars. Many people lost their motivation and we have seen some of them stepping down. We are also having troubles on-boarding new contributors, which is a problem today because some teams are under-staffed and could become an even bigger issue on the longer term. 4. How do you intend to resolve the weakest part? An effort has already been made on this front. We can mention the introduction of the Code of Conduct and the diversity statement, for example. Both are important and make us a more welcoming and caring community. In my platform, I mentioned some ideas about recruitment and change management. I believe that both sides will help us to get a stronger community. Moreover, a DPL should act as a mediator to help some situation get through. This is one of the DPL tasks that is not formally identified and is usually under-estimated. 5. DPL term lasts for one year - what would you challenge during that term and what have you learned from previous DPL's? Personally, the main thing I have learned from past DPLs is that communication is very important. A DPL should dedicate time to communicate about ongoing actions and achievements. It is also important to remind a few things even if it may sound repetitive or trivial:

• Why such action/subject is important.
• What actions have been tried/done in the past.
• What progress has been made since last time.
• What is possibly the next step.

If the communication is only about listing some actions, many people will miss its essence and its goals. It is even more important when we know that some actions may take years (thus, several DPL terms) to complete. If I am elected as DPL, I'd really like to help the project to publish a roadmap. I think it is very important to set goals to the project to better explain our philosophy and approach in the Free Software world. This may also help to attract new contributors which may be interested by one or some items. Of course, I will not work on that subject only. I invite you to read the rest of my platform to see the other ideas. 6. What motivates you to work in Debian and run for DPL? Many many things. And more importantly, many many people As many of us, I like programming and socializing. It feels nice to be part of such a big project and where you can do many different things. I contribute to Debian because I find it fun and let me meet people I will not have been able to meet elsewhere. In my platform, I tried to identify ideas I'd like to see implemented, or at least started. Since Debian is a do-ocracy, I thought I could try to get them implemented by myself. I think that those ideas are important for the Debian community and will help us moving forward. Running for DPL is also another way of contributing to Debian and I'd feel honored to represent Debian.

0. Who are you and what's your history with Debian Project? I'm a little mouse behind a keyboard, going by the nickname "algernon". I used to be a lot of things: a flaming youth, an application manager, package maintainer, upstream, ftp-assistant, a student, a mentor, a hacker. In the end, however, I am but a simple, albeit sometimes crazy person. I did a number of things within Debian - mostly small and marginal things, mind you. With a little break, I've been here for over a decade, and am planning to stay for at least another. 1. What's your most proud moment as Debian Developer? At last year's LinuxTag, I was wandering around a stand where they sold Raspberry Pis (with cases and other accessories). I had a nice chat with one of the staffers there, inquired about the price (including the case, of course), and a few other things. He asked a few things back: what I'll be using it for, and so on. After it turned out that I'm a Debian Developer, and syslog-ng hacker, he went to the back, and emerged a few minutes later with a boxed up Pi, and gave it to me as a gift, for working on Debian. This was an incredibly touching moment, in many, many ways. 2. In your opinion what is the strongest part of Debian Project? That's hard to say, to be honest. There are a good number of things Debian is incredibly strong at, and it would be hard to arbitrarily pick one. Quality, responsibility, safety, predictability are all areas we are very good at. But those are the qualities of the OS. As a project, we are remarkably well organised, given the volunteer & distributed nature of the project. 3. And what is the weakest part of Debian Project? While we can resolve and work with technical issues in a reasonable manner, the project as a whole is rather lacking in all other areas. To grow beyond being the creators of the Universal OS, we, as a project, need to pursue goals beyond the OS. Being part of GSoC and Outreachy are great steps forward. But we still have a lot of internal issues that need to be resolved. Areas such as innovation, team work, where we're in dire need of improvement. 4. How do you intend to resolve the weakest part? As explained in my platform, my primary goal is to remove roadblocks. The DPL can do very little alone, his time and powers are better spent on enabling those who have the required skills and desires, to pursue those. 5. DPL term lasts for one year - what would you challenge during that term and what have you learned from previous DPL's? The most valuable thing I learned from past DPLs is that the expectations are sky-high, yet, a significant portion of what the DPL does is very different than what I imagined in past years. I'd like to challenge the status quo of the DPL being a nearly full-time job. 6. What motivates you to work in Debian and run for DPL? I'm in it for the fame and glory, of course! And because my Tamagotchi told me to. But on a more serious tone, my main motivation to work on Debian is because contributing makes me happy. It satisfies my hunger for doing useful work. Debian is - in my opinion - the perfect platform to give back to the wider Free Software community. Similarly, my motivation to run for DPL is to allow Debian to be a stronger member of that greater

0. Who are you and what's your history with Debian Project? My name's Neil, I've been involved with Debian for over 10 years now. I've held a variety of roles, from the SPI board, writing policy and secure testing team, to being one of the Release Managers for Squeeze and Wheezy. 1. What's your most proud moment as Debian Developer? Probably the release of Squeeze, my first as RM. It was the end of a great effort to get the release out. I particularly remember at the end of DebConf 10 in New York going to the local Disney store and buying every single small squeeze plush toy they had, so I could send a thank you gift to the rest of the release team! Another perhaps was when I first got my Debian kilt. 2. In your opinion what is the strongest part of Debian Project? I think this is our social contract. It guides us, and is what we all agree on. This is our promise to ourselves, to the wider open source community and to our users. 3. And what is the weakest part of Debian Project? At a push, I'd say it's the variety of packages we have in the archive. I'm not sure it's weakness, but it's certainly a challenge. It becomes exponentially harder to ensure that everything integrates well as you add more packages. To have made it do so this far is quite impressive. 4. How do you intend to resolve the weakest part? Well, see the section in my platform on PPAs, and modernising our build and infrastructure system Wouldn't it be great if you could stage a package against all of stable, testing and unstable, and see what fails to build and where, with live build logs on all architectures? 5. DPL term lasts for one year - what would you challenge during that term and what have you learned from previous DPL's? I think my primary role as DPL for 2015 would be to get a great start of development for Stretch. The start of a new release cycle is the exact time to implement wide changes that are potentially disruptive. Every couple of years we seem to relax after the release, rather than get geared up for the next one, and then time passes, and plans slip, and before we know it, the freeze is fast approaching. If we start planning /now/, then we can hopefully enter the freeze with fewer RC bugs, which should be great news for everyone! For the second part, I've talked to a lot of the previous DPLs, and worked with them in one role or another. The main thing I was told was that I shouldn't try and do everything I planned on. It's hard work, and all sorts of things pop up that derail your original plans. 6. What motivates you to work in Debian and run for DPL? The people involved. I've met and worked with some of my greatest friends due to the project. The work, dedication and commitment of those over the years is outstanding. Most of these people are still with us, and unfortunately, a few are not. Whenever I'm feeling disheartened or annoyed, usually due to a giant flame-war then I simply remember that what we're doing is truly remarkable, and the effort that everyone has put in over the years isn't something that should be taken for granted.

My Lenovo x220, which I've owned for almost four years now (I remember fetching it from the supplier shortly before driving off to Banja Luka), was getting somewhat worn out. The keyboard and the screen had both been replaced at some point already, and the wwan interface had given up as well. The case was all cracked, and the NIC connector wasn't doing very well anymore either; there have been a few cases of me trying to configure the wireless network at a customer, but this being harder than it needs to be because the NIC will only work if I put in the network cable just so, and someone dropped a piece of paper onto the cable. In other words, it was time for a new one. At first I wanted to buy a Lenovo x250, but then I noticed that the Fujitsu came with an i7 4712MQ, which I liked (as today it is still quite exceptional for an ultrabook to have a quadcore processor). Fujitsu also claims up to 9 hours of battery life, but it's not clear to me whether this is supposed to be the case with the default battery only. They also have a battery for the modular bay, which I bought as well (to replace the optical drive whic I sometimes use, but only rarely), and on top of that it came with a free port replicator. Not all is well, however. In the x220, getting the WWAN interface to work involved some creative use of chat against /dev/ttyACM0 wherein I issue a few AT commands to put the WWAN interface into a particular mode, and from then on the WWAN interface is just a regular Ethernet interface on which I can do DHCP. The new laptop has a "Sierra Wireless, Inc." WWAN interface (USB id 1199:9041) which annoyingly doesn't seem to expose the ttyACM (or similar) devices, and I'm not sure what to use instead. Just trying to do DHCP doesn't work -- yes, I tried. Unfortunately, the keyboard isn't very good; it's of the bubble gum type, and I keep getting annoyed at it not picking up my keystrokes all the time. When I'm at home or at my main customer, I have a Das Keyboard Ultimate S (3rd (customer) and 4th (home) generation), so it's only a problem when I'm not at home, but it's still extremely annoying. There is a "backlight" function in that keyboard, but that's not something I think I'll ever use (hint: "das keyboard ultimate s"). The display can't do more than 1366x768, which is completely and utterly wrong for a computer -- but it's the same thing as my x220, so it's not really a regression. The "brightness" ACPI keys don't seem to work. I may have to fiddle with some ACPI settings at some point, I suppose, but it's not a major problem. When I plugged it in, I noticed that fdpowermon ignored the second battery. I had originally written fdpowermon with support for such a second battery, but as my x220 had only one, I never tested it. Apparently there was a bug, but that's been fixed now -- at least in unstable. On the good side of the equation, it has three USB3 ports in the laptop, and four in the port replicator, with no USB2; this is a major leap forwards from the one USB3 and six USB2 in the x220. A positive surprise was the CCID smartcard reader that I somehow missed while reading the specs, but which -- given my current major customer, is very welcome, indeed. Update: After having used it a few days, there were a few minor annoyances:

• Audio didn't work whenever I plugged the laptop to its port replicator and used the external screen. It took me a while to figure out that the default ALSA card (i.e., card 0) is the HDMI output, whereas card 1 is the PCH output, and that since I'm using the DVI port and analog audio, I hear nothing. To fix, create a .asoundrc containing:

    pcm.!default  
      type hw
      card 1
     
    ctl.!default  
      type hw
      card 1
     
  

• Backlight didn't work. My .config/awesome/rc.lua now contains the following lines:

    awful.key(   , "XF86MonBrightnessDown", function() awful.util.spawn("xbacklight -dec 5") end),
    awful.key(   , "XF86MonBrightnessUp", function() awful.util.spawn("xbacklight -inc 5") end),
    awful.key(  modkey  , "XF86MonBrightnessDown", function() awful.util.spawn("xbacklight -set 1") end),
    awful.key(  modkey  , "XF86MonBrightnessUp", function() awful.util.spawn("xbacklight -set 100") end),
  

  The lines with "modkey" allow me to go to "brightness max" or "brightness min" in one go, rather than have to hit fn+f6 or fn+f7 repeatedly, which is a useful extra.
• It was suggested to me that ModemManager might be able to figure out how to enable the WWAN modem. The good news is that it detects the modem, and mmcli should have a way to enable things. The bad news is that mmcli -m 0 -e just comes back with "error: couldn't enable the modem: 'timed out'" (partially translated into Dutch). I haven't had the time to look into this much yet, but it seems to be another one of those dbus complications. To be continued, I'm sure.

For quite some time now, I've been following Rust, a new(ish) programming language by Mozilla. It's been around for a while, but recently it's been attracting a lot of buzz. Around the new year, I finally decided to take a deeper look into the language. I find that the best way to learn a new programming language is to simply dive in and try to build something nontrivial. At that point I'd also been interested in learning more about the specifics behind the new HTTP/2 spec, so I decided to combine the two... The result is a (work in progress) client library for HTTP/2 written in Rust, which can be found at this GitHub repository: https://github.com/mlalic/solicit What follows is a description of what I aim to achieve with the library, as well as an overview of its current design. If that doesn't interest you, you can just check out the GitHub repo for some examples or the source code itself. Goals Given that there are already some fairly popular HTTP libraries for Rust (hyper leading the way), I decided that I wouldn't aim to replace them. Rather, the idea is to focus on the lower levels of the HTTP/2 protocol what is essentially another transport protocol and expose an API that allows those libraries to use an HTTP/2 connection to send requests and receive responses. HTTP/2 doesn't change the semantics of the protocol, so once any HTTP/1.1 library gets the raw headers and body, it should be able to represent the response regardless of the fact that it came on an HTTP/2 connection. The same holds for sending requests: only the representation of the request changes, not its content. There are some minor differences, such as HTTP/2 doing away with the reason phrases being part of the response, but those were only meant to be human readable and "MUST NOT" have had any influence on the semantics of the response. Therefore, the primary goal for the library is to provide an API for using an HTTP/2 connection on the lowest level, but making it easy for clients to customize or augment any particular step of handling a response, without having to know the details of functionality below the layer they want to customize. As an example, if one wanted to build a client that sends out progress notifications for downloads, it wouldn't be good if they needed to muck about with raw HTTP/2 frames ideally, they'd only need to implement a new way to handle incoming data chunks for streams. The same applies for implementing a client that streams the download into a file (instead of saving it in memory) or one that sends the chunks to a different component for processing as soon as they're received (e.g. parsing HTML). Since the Rust standard library only exposes blocking IO primitives, I decided to base this library on blocking IO, as well. However, the goal was to make it flexible enough so that clients that would like to allow multiple requests to be sent concurrently on the same HTTP/2 connection can be built, but without the library itself spawning any threads. Finally, on a less conceptual level (and more of an implementation level), the code should have extensive test coverage. Design The library is split into several layers, each of which provides services to the one above it. A brief description of each layer follows. Transport Layer This layer provides the API for raw byte stream communication with the peer. Essentially, it's a wrapper around the particular transport protocol that is used for the HTTP/2 connection. As the HTTP/2 spec allows the transport protocol to be either a cleartext TCP connection or a TLS-protected one, those are the ones that need to be implemented at this level. The API of the layer is represented by a single trait TransportStream that simply requires io::Read and io::Write to be implemented and (for now) provides a single convenience method based on the underlying io::Read implementation. For a clear-text TCP connection, the only thing that was required to implement it was one line of code:

impl TransportStream for TcpStream  

HTTP/2 Connection Layer The connection layer provides an API for reading and writing to a raw HTTP/2 connection. This means reading and writing HTTP/2 frames, not arbitrary bytes. Each HTTP/2 frame has to follow the same basic structure(a 9-byte header followed by a sequence of byte representing the payload of the frame). This is represented by the RawFramestruct. Each HTTP/2 frame type can have its own specific format for the content of the payload and assign meaning to the flags found in the header. Therefore, each frame needs to have its own implementation that can parse a RawFrame or return an error if the raw frame does not represent a valid frame of that type. Some common methods that each frame type implementation needs to support are given by the Frametrait that must be implemented by the implementations. Finally, the HttpConnectionstruct handles reading the byte stream from the underlying TransportStream instance, correctly delineating frames and parsing them into the appropriate frame type implementation (by delegating to the correct Frame implementation based on the frame type found in the header). Obviously, varying the implementation of the transport layer is a matter of choosing the appropriate TransportStream implementation. This includes using mock implementations for testing the HttpConnection itself. HTTP/2 Client Connection The ClientConnectionbuilds upon the HttpConnection by using it to expose functionality that is specific to the client side of an HTTP/2 connection. This includes sending requests and reading responses. The struct takes care of creating frames that need to be sent for a given request (including HPACK header encoding) and shipping them off to the server (using the underlying HttpConnection instance). As for handling a response, the ClientConnection expects to get an instance of a struct implementing the Sessiontrait when constructed. This trait essentially defines a number of callbacks: methods that will be called on this instance when the corresponding event occurs in the ClientConnection. Therefore, the ClientConnection understands the semantics of the particular frames that it reads (e.g. performs the decoding of the HEADERS frames' payloads, passing the raw data received in a DATA frame to the session, etc.). However, it does not know anything about streams; it only passes the stream ID up to the session layer, without thinking about whether the stream is open, valid, etc. HTTP/2 Session As mentioned in the previous section, each ClientConnection requires an instance of a struct implementing the Sessiontrait to be passed to it at construction time. The Session trait defines a number of callbacks that are invoked in the appropriate moments during the processing of frames read on a client connection. For example, new_headers (takes a list of heaers and a stream on which they were received) or new_data_chunk (a buffer and a stream on which the data arrived). The session is in charge of handling these events as they arise. It is up to it to decide what (if anything) should be done with the data that it receives. There is a default implementation of the Session trait (unimaginatively named DefaultSession), which provides an implementation that tracks which streams are currently open and delegates the processing of new events on particular streams to instances of a Streamtrait. This allows for client implementations to simply vary the implementation of a Stream that they provide to the DefaultSession in order to change how a particular part of a response is handled, but let the DefaultSession take care of tracking which streams are open and valid. Different implementations of a Session still can exist, if the particular client needs more fine-grained customization over how these events are handled, but for most purposes the default session, along with Stream customization should probably be enough. HTTP/2 Stream Again, as mentioned previously, the DefaultSessionimplementation of the Session trait relies on a Streamtrait providing the handling for events arising on individual streams. This level should be the one that gets customized most often in alternate implementations. A default stream implementation DefaultStreamhandles the messages by building up a response in-memory. Different implementations could instead send progress notifications on an associated channel, for instance. HTTP/2 Client The final layeris that of a client that exposes methods that would usually be expected for a client HTTP library: sending requests, obtaining responses. This layer is not the primary focus, though, and it only exposes two simple implementations that showcase how the lower level APIs can be used to build a client. The second purpose it fulfills is as a "sanity check" that the APIs actually do allow the goals to be met. Therefore, one of the clients allows for requests to be sent from concurrently running threads and the responses to those requests to be obtained asynchronously (in the form of a Future<Response>). However, the responses are basic and very raw: they are stored fully in memory (not available until they've been read until the end) and both the body, as well as the headers, exposed as raw byte sequences. As an example how this clientcan be used (as well as the simpler single-threaded version), check out the Examplessection in the GitHub repository's README file. Future Work Refactoring APIs As the project was started as a Rust learning exercise, the initial APIs are slightly awkward and fairly inefficient to work with. For example, the solicit::hpackmodule requires headers to be represented as a tuple of Vec<u8>, which means that whenever we need to encode a header list, even though their values might be (statically known) byte sequence literals, such as (b":method", b"GET"), we need to make a bunch of to_vec calls on the &[u8]s before passing them to the encoder, leading not only to a really ugly and tedious way of obtaining the encoded representation of the headers, but also to a lot of unnecessary allocations. Another API that will see some refactoring and improvement is the TransportStream, as well as the HttpConnection in order to make it possible to have separate threads perform reads and writes on the connection. Currently, the socket is owned by the HttpConnection instance and all writes and reads require a &mut reference, making this impossible. This change would tackle this by embracing Rust's new try_clone method on the TcpStream into the TransportStream and refactoring the HttpConnection to allow splitting it into a write and read handle. HTTP/2 Features As already mentioned, only a small subset of the full HTTP/2 spec is currently implemented, so, obviously, implementing the rest of it falls under the most important future work. Some near- to mid-term priorities that will be tackled are:

• TLS-backed connections: a new TransportStream implementation that wraps a TCP socket into a TLS wrapper. This will probably rely on OpenSSL bindings.
• Support for all HTTP/2 frames: only the three vital frames are implemented so far; other frames are a prerequisite to implementing properly closing streams, handling closed streams etc.
• Signaling stream- and connection-level errors to the peer
• Flow control: right now this aspect is completely ignored
• Server push: the idea is that multithreaded clients could handle pushed responses as soon as they arive, whereas single-threaded ones would be allowed to fetch a list of them every so often.

Obviously, those aren't all the features of HTTP/2, but it's a rough list of things I'm planning on working on myself as the next steps. Integration With an (existing?) HTTP Library I would like it if in the end the library or at least some of its pieces ended up being used in the scope of one of the fully featured HTTP libraries. If there's any interest in this, I wouldn't mind putting in some extra legwork to help make it happen. Conclusion While I'm certain that there can be better, more efficient, more elegant implementations, I've had a lot of fun working on this so far (learning new things is always fun!) and if nothing else I'll continue in order to gain the deepest possible understanding of HTTP/2. For anyone that might have read all the way through, thanks for reading and I'm open for any sort of feedback!

ApologyAs a twisted turn of fate, I need to start my platform with an apology. Last year, I withdrew my nomination, because my life turned upside down, and the effects of that are still felt today, and will continue to have a considerable footprint for the rest of my life. But this is not what I want to apologise for! I want to apologise because my nomination, my platform, and my plans are rather uncommon - or so I believe. Unlike past Project Leaders, if elected, I will not have as much time to travel, as some of them. Nor will I have the resources to do all the things one may expect from a Project Leader. But - as you'll read later - I consider this both the biggest weakness and the greatest strength of my platform.Furthermore, I will not be available from the second half of the voting period until after the new Project Leader's term starts: I'll be getting married, and will enjoy a nice honeymoon, and as such, my email will remain unread from the 9th of April until we're back on the 21st of April.On the mouse behind the keyboardMy name is Gergely Nagy, or algernon, for those of you who may know me by my online presence. I used to be a lot of things: a flaming youth, an application manager, package maintainer, upstream, ftp-assistant, a student, a mentor, a hacker. In the end, however, I am but a simple, albeit sometimes crazy person. I imagine, a lot of people reading this will not know me, and that is actually not only fine, but in my case, desirable.The Role of the Project LeaderThe role of the Project Leader, what people perceive about the role, and what is actually done by one single person changed dramatically over time. In some ways for the better, some ways for the worse. It should be sufficiently clear by now that if we combine all the things past Project Leaders have done, and what people expect the Project Leader to do, then not even all the time in the world would be enough to accomplish everything. On the other hand, we should not cut the responsibilities back to constitution-granted ones only.There has been some discussion about this very topic on debian-project@, back in February, with excellent observations by both past Project Leaders and the current one. I encourage my dear readers to stop reading this platform now, and read at least Lucas's mail. I'll be right here when you get back.Back? Good.You may notice that unlike in previous years, I do not have a Grand Vision, not in the same sense at least. No matter what I envision, however noble that vision may be, it is not the Project Leader's job to save the world, so to say. While I still believe that we have serious problems with motivation, inspiration and innovation within the project, the Project Leader is the wrong person to try and solve these issues with.Apart from the constitutionally required responsibilities, the primary purpose of the Project Leader in my opinion, is to be an enabler: the Project Leader is not a front runner to lead the herd to victory, but a gentle shepherd to make them happy.HappyThere are many ways to make people happy. One such way is to enable them to pursue their passion - and not just enable them, but encourage and fuel that passion, too! -, to remove barriers, to empower them, or in a lot of cases, to include them in the first place. My vision is a project that is greater than just an amazing distribution. More than a role model for technical excellence. I want to do away with territorial pissings (with which I don't mean to imply that this would be the general atmosphere within the project - far from it!), and would rather see a warm, welcoming culture within the project - the kind of "I'm home!" feeling I had at the DebConfs I had the privilege to attend -, on public and private media alike.That is the vision I have, but I can't do it. At best, I can hope to enable people much better at the these things to do what needs to be done. I wish to take the burden of administration, bureaucracy off their shoulders, so they can focus on what they do best. I feel that this is the most important part of being a Project Leader: to enable the project to grow. And this is why I feel that most of you not knowing my name is an advantage here: When you look at a beautiful flower, you admire the flower itself, rarely the gardener.In the endI wish to be the Project Leader no one remembers. I'd rather see people remember all the great things the Project - as a whole - accomplished, for there are many. My purpose is to let You pursue your passion, which in turn enables even more people to pursue their happiness, and allows the greater Free Software community to bask in the warm glow of accomplished dreams.

On the assumption that the post titled "Delete file when you have more than 100g for deleting" on the "Linux.com - Content Feed" is not an elaborate joke, it's not unlikely that it will be deleted so I will conserve it here: Hello Linix community members, Today I would like to share a simple script for deleting files when you have more than 100g for deleting and when you try to delete using rm -rm /path/fo/files failed. To do this I use the following procedure; first I use a "for" ciclo to read file that I going to delete also you can use a mtime for calculate file's date that you're going to delete or you can to calculate previous date of a past day "x=TZ=GMT+24 date +%Y%m%d" Ex;

#!/bin/bash -x
x= TZ=GMT+24 date +%Y%m%d 
delcnt=0
for files in  find /path/of/file/to/eraser/ -name \*$x*.bin.gz 
do
echo "Deleting file $files"
/bin/rm -rf $files
delcnt=$(($delcnt + 1))
done

Best regards Charles E. Rivera Solaris Server Specialist Engeeneer But then, Linux.com still aggregates Phoronix, so their focus is not exactly on quality.

Between december 9th 2014 and march 9th 2015 I ve been working as an intern for Debian on Improving AppArmor support in Debian. Progress Before the internship started, I had no clue about AppArmor at all. Reading the Wikipedia page and the AppArmor wiki did barely enlighten me. At least, until I got my hands dirty and installed and activated it. I was able to do this only because there was already some basic documentation on the Debian wiki on how to get AppArmor running on a Debian system. When the internship started I felt a little bit lost. I started to read the documentation and to play around with some AppArmor profiles. But the error messages I saw and the profiles I opened for reading overwhelmed me. What did all these lines mean? Then one mentor briefed me about the current status of AppArmor in Debian. I took many notes and tried to bring some order into the information I was being given. These notes became the first page of the documentation and my first blog post.
Surprise: suddenly I was in the middle of knowing what we were talking about and how the next few weeks would look like. To start with, I have set up a test environment and continued to test some of the profiles which came with the packages I had installed, namely apparmor-profiles-extra which provided me with a profile for Pidgin. I was very much interested in securing this several thousand lines long C-code application on my machine! As a Pidgin user, I noticed immediately that one of my favourite features pidgin blinklight threw an error in the logs. I tried to fix it on my test VM and eventually made it work. Now knowing that such fixes should first be done upstream, i cloned the corresponding upstream repository and sent my first patch. It was not easy at first to switch to another VCS than Git, although I had been using Bazaar and Subversion years ago. Shortly afterwards, I saw my patch showing up on the upstream mailing list, and some days later it got merged. That was a huge encouragement. I was now able to write more documentation on how to contribute upstream. In order to organize the documentation, we ve set up some User Stories. I did not know about this tool before and had quite a hard time to grasp all the details but it proved to be very useful as some pages started to become long and confusing. Writing the documentation took up a lot of time, but before being able to write anything down, I needed to work everything out! This way I incidentally learned how to interact with many parts of Debian s infrastructure:

• Git repositories for packaging I imported my upstream patches into the AppArmor team s repositories. My previous experience in Debian packaging was not only helpful but indispensable for this task.
• Debian bug tracker I learned more about reporting and usertagging bugs and filed some whishlist bugs which would make life easier.
• Debian wiki I wrote documentation but I also read a lot of documentation, namely about using the Bug Tracking System and making things work on Alioth.
• Ultimate Debian Database I wrote a Python script which queries the UDD and sends email notifications for new usertags. Writing the Python script was a lot of fun. I had some prior coding experience, but thanks to the mentors and upstream authors feedback I realized how important it is to write consistent code that can be easily understood and maintained by several people.
• Setting up Git repositories, post commit hooks and cronjobs on Alioth for group maintaining scripts.

While playing around with the tools provided to inspect AppArmor status on the system, I even accidentally found a little bug in one of the upstream tools. It got fixed very quickly after I mentioned it on the AppArmor team s mailing list. Organization Although I was uncomfortable with this in the beginning, we organized public meetings every two weeks on IRC. These meetings were also attended by MeetBot who took care of taking notes and leaving a trace of our discussions.
Based on the meetings, I maintained a progress page and todo list on the Debian wiki, which helped us to know which tasks were planned for the next two weeks. Before each meeting I sent a status update to the mailing list, so the mentors could catch up with my work. During the meetings I was not only asked to provide feedback on progress but also on mentoring itself. It proved to be very useful to be able to say where I was stuck and if the mentoring process worked out well enough (it did!).
Furthermore, I got regular, detailed and pedantic (thanks for trying to push me to perfection!) feedback on the team s mailing list. The mentors had introduced me on the upstream IRC channel in the beginning, so most of the people who are active there knew about my existence, something which also proved to be handy! Future The internship time is over, but some work remains to be done. As a new member of the AppArmor Packaging team, I am committed to make it happen:

• Think about a cross distro meeting there was a proposal to do that during DebConf
• Write the migrate profile documentation after migrating a profile in a real world scenario together with intrigeri.
• Fix Debian bug #702030 intrigeri should review my technical proposal before I work on it.

Thanks I feel much more confident after these three months, technically but also personally. Thank you: Holger Levsen and intrigeri for mentoring and encouraging me on this journey and to upstream contributors Christian Boltz, Steve Beattie (and everybody else I might forget here) for providing help and feedback. The Debian community (OPW organizers, sponsors, Alioth maintainers, planet.debian.org maintainers although my posts don t show up anymore -and others) has been very friendly and welcoming and I am very happy to be part of it.

Graham Neubig published Travater , an OpenSource statistical machine translation system and the demosite (http://ahclab.naist.jp/travatar/translator/). Graham said It makes good result likely Google Translation. Unfortunately, it seems to be crwoded, so I can t get correct result (output IO Error dialog). Anyway, it is a good new for Japanese processing scene.

The new release 0.11.5 of Rcpp just reached the CRAN network for GNU R, and a Debian package has also been be uploaded. Rcpp has become the most popular way of enhancing GNU R with C++ code. As of today, 345 packages on CRAN depend on Rcpp for making analyses go faster and further; BioConductor adds another 41 packages, and casual searches on GitHub suggests dozens mores. This release continues the 0.11.* release cycle, adding another large number of small bug fixes, polishes and enhancements. Since the previous release in January, we incorporated a number of pull requests and changes from several contributors. This time, JJ deserves a special mention as he is responsible for a metric ton of the changes listed below, making Rcpp Attributes even more awesome. As always, you can follow the development via the GitHub repo and particularly the Issue tickets and Pull Requests. And any discussions, questions, ... regarding Rcpp are always welcome at the rcpp-devel mailing list. See below for a detailed list of changes extracted from the NEWS file.

Changes in Rcpp version 0.11.5 (2015-03-04)

Changes in Rcpp API:

• An error handler for tinyformat was defined to prevent the assert() macro from spilling.
• The Rcpp::warning function was added as a wrapper for Rf_warning.
• The XPtr class was extended with new checked_get and release functions as well as improved behavior (throw an exception rather than crash) when a NULL external pointer is dereferenced.
• R code is evaluated within an R_toplevelExec block to prevent user interrupts from bypassing C++ destructors on the stack.
• The Rcpp::Environment constructor can now use a supplied parent environment.
• The Rcpp::Function constructor can now use a supplied environment or namespace.
• The attributes_hidden macro from R is used to shield internal functions; the R_ext/Visibility.h header is now included as well.
• A Rcpp::print function was added as a wrapper around Rf_PrintValue.

Changes in Rcpp Attributes:

• The pkg_types.h file is now included in RcppExports.cpp if it is present in either the inst/include or src.
• sourceCpp was modified to allow includes of local files (e.g. #include "foo.hpp"). Implementation files (.cc; .cpp) corresponding to local includes are also automatically built if they exist.
• The generated attributes code was simplified with respect to RNGScope and now uses RObject and its destructor rather than SEXP protect/unprotect.
• Support addition of the rng parameter in Rcpp::export to suppress the otherwise automatic inclusion of RNGScope in generated code.
• Attributes code was made more robust and can e.g. no longer recurse.
• Version 3.2 of the Rtools is now correctly detected as well.
• Allow 'R' to come immediately after '***' for defining embedded R code chunks in sourceCpp.
• The attributes vignette has been updated with documentation on new features added over the past several releases.

Changes in Rcpp tests:

• On Travis CI, all build dependencies are installed as binary .deb packages resulting in faster tests.

Thanks to CRANberries, you can also look at a diff to the previous release As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads page, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

I found an Acurite Weather Center 02032CAUDI at Costco for $99, which seemed like a pretty good deal. It includes the "colour" display panel and a 5-in-1 remote sensor that includes temperature, wind-speed and direction, humidity and rain gauge. The colour in the diplay is really just a fancy background sticker with the usual calculator-style liquid-crystal display in front. It does seem that for whatever reason the viewing angle is extremely limited; even off centre a little and it becomes very dim. It has an inbuilt backlight that is quite bright; it is either off or on (3-levels) or in "auto" mode, which dims it to the lowest level at certain hours. Hacking in a proximity sensor might be a fun project. The UI is OK; it shows indoor and outdoor temperature/humidity, wind-speed/rain and with is able to show you highs and lows with a bit of scrolling. I was mostly interested in its USB output features. After a bit of fiddling I can confirm I've got it connected up to Meteobridge that is running on a Dlink DIR-505 and reporting to Weather Underground. One caveat is that you do need to plug the weather-station into a powered USB hub, rather than directly into the DIR-505; I believe because the DIR-505 can only talk directly to USB2.0 devices and not older 1.5 devices like the weather station. Another small issue is that the Meteobridge license is 65 which is not insignificant. Of course with some effort you can roll-your-own such as described in this series which is fun if you're looking for a project. Luckily I had a mounting place that backed onto my small server cupboard, so I could easily run the cables through the wall to power and the DIR-505. Without this the cables might end up a bit of a mess. Combined with the fairly limited viewing angle afforded, finding somewhere practical to put the indoor unit might be one of the hardest problems. Mounting the outdoor unit was fine, but mine is a little close to the roof-line so I'm not sure the wind-speed and direction are as accurate as if it were completely free-standing (I think official directions for wind-speed are something like free-standing 10m in the air). It needs to face north; both for the wind-direction and so the included solar-panel that draws air into the temp/humidity sensor is running as much as possible (it works without this, but it's more accurate with the fan). One thing is that it needs to mounted fairly level for the rain-gauge; it includes a small bubble-level on the top to confirm this. Firstly you'll probably find that most mount points you thought were straight actually aren't! Since the bubble is on the top, if you want to actually see it you need to be above it (obviously) which may not be possible if you're standing on a ladder and mounting it over your head. This may be a situation that inspires a very legitimate use of a selfie-stick. It's a fun little device and fairly hackable for an overall reasonable price; I recommend.