I posted this on debian-devel today. I am also posting it here, because I believe it is important to more than just Debian developers. Good afternoon, This message comes on the heels of Sam Hartman s wonderful plea for compassion [1] and the sad news of Joey Hess s resignation from Debian [2]. I no longer frequently post to this list, but when you ve been a Debian developer for 18 years, and still care deeply about the community and the project, perhaps you have a bit of perspective to share. Let me start with this: Debian is not a Free Software project. Debian is a making-the-world-better project, a caring for people project, a freedom-spreading project. Free Software is our tool. As many of you, hopefully all of you, I joined Debian because I enjoyed working on this project. We all did, didn t we? We joined Debian because it was fun, because we were passionate about it, because we wanted to make the world a better place and have fun doing it. In short, Debian is life-giving, both to its developers and its users. As volunteers, it is healthy to step back every so often, and ask ourselves two questions: 1) Is this activity still life-giving for me? 2) Is it life-giving for others? I have my opinions about init. Strong ones, in fact. [3] They re not terribly relevant to this post. Because I can see that they are not really all that relevant. 14 years ago, I proposed what was, until now anyhow, one of the most controversial GRs in Debian history. It didn t go the way I hoped. I cared about it deeply then, and still care about the principles. I had two choices: I could be angry and let that process ruin my enjoyment of Debian. Or I could let it pass, and continue to have fun working on a project that I love. I am glad I chose the latter. Remember, for today, one way or another, jessie will still boot. 18 years ago when I joined Debian, our major concerns were helping newbies figure out how to compile their kernels, finding manuals for monitors so we could set the X modelines properly, finding some sort of Free web browser, finding some acceptable Office-type software. Wow. We WON, didn t we? Not just Debian, but everyone. Freedom won. I promise you 18 years from now, it will not matter what init Debian chose in 2014. It will probably barely matter in 3 years. This is not key to our goals of making the world a better place. Jessie will still boot. I say that even though my system runs out of memory every few days because systemd-logind has a mysterious bug [4]. It will be fixed. I say that even though I don t know what init system it will use, or how much choice there will be. I say that because it is simply true. We are Debian. We will make it work, one way or another. I don t post much on this list anymore because my personal passion isn t with posting on this list anymore. I make liberal use of my Delete Thread keybinding on -vote these days, because although I care about the GR, I don t care about it enough to read all the messages about it. I have not yet decided if I will spend the time researching it in order to vote. Instead of debating the init GR, sometimes I sit on the sofa with my wife. Sometimes I go out and fly the remote-control airplane I m learning to fly. Sometimes I repair my plane after a flight that was shorter than planned. Sometimes I play games with my boys, or help them with homework, or share my 8-year-old s delight as a text file full of facts about the Titanic that he wrote in Emacs comes spitting out of the printer. Sometimes I write code or play with the latest Linux filesystems or build a new server for my basement. All these things matter more to me than init. I have been using Debian at home for almost 20 years, at various workplaces for almost that long, and it is not going to stop being a part of my life any time soon. Perhaps I will have to learn how to administer a new init system. Well, so be it; I enjoy learning new things. Or perhaps I will have to learn to live with some desktop limitations with an old init system. Well, so be it; it won t bother me much anyhow. Either way, I m still going to be using what is, to me, the best operating system in the world, made by one of the world s foremost Freedom projects. My hope is that all of you may also have the sense of peace I do, that you may have your strong convictions, but may put them all in perspective. That we as a project realize that the enemy isn t the lovers of the other init, but the people that would use law and technology to repress people all over the world. We are but one shining beacon on a hill, but the world will be worse off if our beacon winked out. My plea is that we each may get angry at what matters, and let go of the smaller frustrations in life; that we may each find something more important than init/systemd to derive enjoyment and meaning from. [5] May you each find that airplane to soar freely in the skies, to lift your soul so that the joy of using Free Software to make the world a better place may still be here, regardless of what /sbin/init is. [1] https://lists.debian.org/debian-project/2014/11/msg00002.html [2] https://lists.debian.org/debian-devel/2014/11/msg00174.html [3] A hint might be that in my more grumpy moments, I realize I haven t ever quite figured out why the heck this dbus thing is on so many of my systems, or why I have to edit XML to configure it ;-) [4] #765870 [5] No disrespect meant to the init/systemd maintainers. Keep enjoying what you do, too!

After upgrading psgml complains. Hangs forever starting up on psgml-html mode startup, and after breaking, 'tab' would error. Seems like trying to load HTML 4.01 transitional DTD makes this happen. I switched to HTML5 DTD and things were no longer broken. Hmmm...

I got involved with Debian development in, I think, 1998. In early 1999, I was accepted as a Debian developer. The next two or three years were a formative experience for me. I learned both software engineering and massively international collaboration; I also made two major contributions to Debian that are still around (of this, I am very proud). In consequence, being a Debian developer became a part of my identity. Even after my activity lessened more than a decade ago, after I no longer was a carefree student, it was very hard for me to let go. So I ve hung on. Until now. I created my 4096-bit GPG key (B00B474C) in 2010, but never got around to collecting signatures to it. I ve seen other people send me their key transition statements, but I have not signed any keys based on them. It just troubles me to endorse a better secured key based on the fact that I once verified a less secure key and I have a key signature chain to it. For this reason, I have not made any transition statements of my own. I ve been meaning to set up key signing meetings with Debian people in Finland. I never got around to that, either. That, my friends, was my wakeup call. If I can t be bothered to do that, what business do I have clinging on to my Debian identity? My conclusion is that there is none. Therefore, I will be retiring from Debian. This is not a formal notice; I will be doing the formal stuff (including disposing of my packages) separately in the appropriate forums in the near future. I agree with the sentiment that Joey Hess wrote elsewhere: It s become abundantly clear that this is no longer the project I originally joined . Unlike Joey, I think that is a good thing. Debian has grown, a lot. It s not perfect, but like my elementary-school teacher once said: A thing that is perfect was not made by people. Just remember to continue growing and getting better. And keep making the Universal Operating System. Thank you, all.

Fun and Sanity in Debian A friend of mine recently asked: "is there anything happening in Debian besides systemd?" Of course there is. He asked it 2 days after the freeze, which happened in time, and with an amazingly low RC bug count. The most visible thing right now seems to be this endless init system argument, but there are fun and sane things in Debian. Many of them. I think someone should put the spotlight on them, and here's my attempt. Yesterday I set up a gobby document asking "What is now happening in Debian that is exciting, fun and sane?", and passed the link around the Cambridge Miniconf and some IRC channels. Here are a few quotations that I collected:

The armhf and arm64 ports have for me been wonderful and exciting, and were a great time for me to start getting involved. (Jon "Aardvark" Ward) We have a way of tracking random contributors, and as far as I know no other project has anything like it. (Enrico Zini) codesearch.debian.net is an incredibly important resource, not just for us but for the free software community at large. (Ben Hutchings) sources.debian.net is a very useful resource with lots of interested contributors, it received 10 OPW applicants (Stefano Zacchiroli) It has never been easier to work on new infrastructure project thanks to the awesome work of the DSA team. We have dozens of contribution opportunities outside of just plain packaging. (Rapha l Hertzog) The work on reproducible builds has achieved excellent results with 61.3% of packages being reproducible. (Paul Wise) Porting arm64 has been (peversely) great fun. It's remarkably morish and I like nothing more than a tedious argument with autoconf macros. Working with lots of enthusiastic people from other teams, helping getting the port set up and build has been great - thank you everybody. (Wookey)

And here are random exciting things that were listed:

• build-profile support (for bootstrapping) is all in jessie (dpkg, apt, sbuild, python-apt, debhelper, libconfig-model-dpkg-perl, lintian).
• PointCloudLibrary (PCL) got migrated from Ubuntu to Debian
• Long Term Support has arrived!
• http://ci.debian.net
• Debian is participating for the second time in OPW as mentor orga
• ftp-master is getting an API
• cross-toolchains for jessie are available
• arm64/ppc64el ready to go into jessie
• wheezy-backports is more useful and used than ever
• we froze, in time, with a remarkably low RC bug count, and we have a concrete plan for getting from that to a release

In 2009 I called for a general resolution regarding membership procedures in Debian, to block a change that, in my opinion, was going against our values. Results, even if they satisfied the majority came with a bitter feeling and it became questioned whether a better solution could have been reached without using a constraining procedure. I did not think so, but not to the point of not having doubts about it, and therefore, regrets. This year, we are again having a vote related to a change that some people think it goes against our values, and again the existence of this vote makes it hard to find compromises. Bitterness will win whatever the result is. For the avoidance of doubt, I have proposed the amendment number 3, stating that this general resolution should not have been started. I hope that this amendment will defeat the original proposition and will make people think twice before pressing Debian's alarm button next time. PS: amendment 3, that is amendment C, that is choice 4. If there was a need for an example that the procedure is complex, here it is...

The topic of Debian forks has come up a lot recently, and as time goes on I've actually started considering the matter seriously: How would you fork Debian? The biggest stumbling block is that the Debian distribution contains thousands of packages, which are maintained by thousands of developers. A small team has virtually no hope of keeping up to date, importing changes, dealing with bug-reports, etc. Instead you have to pick your battle and decide what you care about. This is why Ubuntu split things into "main" and "universe". Because this way they didn't have to deal with bug reports - instead they could just say "Try again in six months. Stuff from that repository isn't supported. Sorry!" So if you were going to split the Debian project into "supported" and "unsupported" what would you use as the dividing line? I think the only sensible approach would be :

• Base + Server stuff.
• The rest.

On that basis you'd immediately drop the support burden of GNOME, KDE, Firefox, Xine, etc. All the big, complex, and user-friendly stuff would just get thrown away. What you'd end up with would be a Debian-Server fork, or derivative. Things you'd package and care about would include:

• The base system.
• The kernel.
• SSHD.
• Apache / Nginx / thttpd / lighttpd / etc
• PHP / Perl / Ruby / Python / etc
• Jabberd / ircd / rsync / etc
• MySQL / PostGres / Redis / MariadB / etc.

Would that be a useful split? I suspect it would. It would also be manageable by a reasonably small team. That split would also mean if you were keen on dropping any particular init-system you'd not have an unduly difficult job - your server wouldn't be running GNOME, for example. Of course if you're thinking of integrating a kernel and server-only stuff then you might instead prefer a BSD-based distribution. But if you did that you'd miss out on Docker. Hrm.

This evening, after the boys were in bed, Laura and I sat down to an episode of MASH (a TV series from the 70s) and leftover homemade pumpkin bars. She commented, Sometimes I wonder what generation we re in. This doesn t seem to be something people our age are usually doing. Probably true. I suppose people my age aren t usually learning to play the penny whistle or put up antennas in trees either. We ve had a fun day today a different sort of day in a lot of ways. We took the boys for their first Wichita Symphony Orchestra experience they were doing their first-ever family concert (Beethoven Lived Upstairs, which combined Beethoven s music with a two-person play aimed at kids). And they had an instrument petting zoo beforehand. Both boys loved it.

From November 8, 2014

After that, we took them to a sushi place for the first time. We ordered different types of rolls for our table, encouraging them to start with the California roll. They loved it (though Oliver did complain it was a bit hard to eat). Jacob happily devoured everything he could that wasn t spicy. He would have probably devoured the plate of California roll slices by himself if I hadn t stopped him and encouraged him to slow down and try some other things too. It doesn t seem very common around here to take 5-year-olds to a sushi place and plan on them eating the same sort of food that the adults around them are. It is a lot of fun to be different. Jacob and Oliver both have their unique personalities and interests, and I hope that they continue to find strength and joy in all the ways they are unique.

Docker is the well-known tool for building, distributing, and launching containers. I use it personally to run a chat-server, a graphite instance, and I distribute some of my applications with Dockerfiles too, to ease deployment. Here are some brief notes on things that might not be obvious. For a start when you create a container it is identified by a 64-byte ID. This ID is truncated and used as the hostname of the new guest - but if you ever care you can discover the full ID from within the guest:

~# awk -F/ ' print $NF ' /proc/self/cgroup
9d16624a313bf5bb9eb36f4490b5c2b7dff4f442c055e99b8c302edd1bf26036

Compare that with the hostname:

~# hostname
9d16624a313b

Assigning names to containers is useful, for example:

$ docker run -d -p 2222:22 --name=sshd skxskx/sshd

However note that names must be removed before they can be reused:

#!/bin/sh
# launch my ssh-container - removing the name first
docker rm  sshd   true
docker run --name=sshd -d -p 2222:22 skxskx/sshd

The obvious next step is to get the IP of the new container, and setup a hostname for it sshd.docker. Getting the IP is easy, via either the name of the ID:

~$ docker inspect --format '  .NetworkSettings.IPAddress  ' sshd
172.17.0.2

The only missing step is the ability to do that magically. You'd hope there would be a hook that you could run when a container has started - unfortunately there is no such thing. Instead you have two choices:

• Write a script which parses the output of "docker events" and fires appropriately when a guest is created/destroyed.
• Write a wrapper script for launching containers, and use that to handle the creation.

I wrote a simple watcher to fire when events are created, which lets me do the job. But running a deamon just to watch for events seems like the wrong way to go. Instead I've switched to running via a wrapper dock-run:

$ dock-run --name=sshd -d -p 2222:22 skxskx/sshd

This invokes run-parts on the creation directory, if present, and that allows me to update DNS. So "sshd.docker.local" will point to the IP of the new image. The wrapper was two minutes work, but it does work, and if you like you can find it here. That concludes my notes on docker - although you can read articles I wrote on docker elsewhere.

WE ARE FROZEN! Please note that Lucas hacked a "key packages" count into this list. If you have spare cycles, look at those first. I hope to have a (somewhat) random bug of the week thingie by next week which picks stalled bugs for increased exposure. As you can see, we are a bit worse than in the Squeeze cycle, but way ahead of Wheezy. Stats with proper diffs will also start next week. The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 1154 (Including 190 bugs affecting key packages)
  • Affecting Jessie: 295 (key packages: 150) That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting Jessie and unstable: 229 (key packages: 116) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 22 bugs are tagged 'patch'. (key packages: 12) Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 14 bugs are marked as done, but still affect unstable. (key packages: 8) This can happen due to missing builds on some architectures, for example. Help investigate!
      • 193 bugs are neither tagged patch, nor marked done. (key packages: 96) Help make a first step towards resolution!
    • Affecting Jessie only: 66 (key packages: 34) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 37 bugs are in packages that are unblocked by the release team. (key packages: 24)
      • 29 bugs are in packages that are not unblocked. (key packages: 10)

How do we compare to the Squeeze release cycle?

Week	Squeeze	Wheezy	Diff
43	284 (213+71)	468 (332+136)	+184 (+119/+65)
44	261 (201+60)	408 (265+143)	+147 (+64/+83)
45	261 (205+56)	425 (291+134)	+164 (+86/+78)
46	271 (200+71)	401 (258+143)	+130 (+58/+72)
47	283 (209+74)	366 (221+145)	+83 (+12/+71)
48	256 (177+79)	378 (230+148)	+122 (+53/+69)
49	256 (180+76)	360 (216+155)	+104 (+36/+79)
50	204 (148+56)	339 (195+144)	+135 (+47/+90)
51	178 (124+54)	323 (190+133)	+145 (+66/+79)
52	115 (78+37)	289 (190+99)	+174 (+112/+62)
1	93 (60+33)	287 (171+116)	+194 (+111/+83)
2	82 (46+36)	271 (162+109)	+189 (+116/+73)
3	25 (15+10)	249 (165+84)	+224 (+150/+74)
4	14 (8+6)	244 (176+68)	+230 (+168/+62)
5	2 (0+2)	224 (132+92)	+222 (+132/+90)
6	release!	212 (129+83)	+212 (+129/+83)
7	release+1	194 (128+66)	+194 (+128/+66)
8	release+2	206 (144+62)	+206 (+144/+62)
9	release+3	174 (105+69)	+174 (+105/+69)
10	release+4	120 (72+48)	+120 (+72/+48)
11	release+5	115 (74+41)	+115 (+74/+41)
12	release+6	93 (47+46)	+93 (+47/+46)
13	release+7	50 (24+26)	+50 (+24/+26)
14	release+8	51 (32+19)	+51 (+32/+19)
15	release+9	39 (32+7)	+39 (+32/+7)
16	release+10	20 (12+8)	+20 (+12/+8)
17	release+11	24 (19+5)	+24 (+19/+5)
18	release+12	2 (2+0)	+2 (+2/+0)

Graphical overview of bug stats thanks to azhag:

TLDR: Using the awesome window manager: how to automatically send SIGSTOP and SIGCONT to application windows when they get unfocused or focused, respectively, to let the application not waste CPU cycles when not in use. I don't require any fancy looking GUI, so my desktop runs no full-blown desktop environment like Gnome or KDE but instead only awesome as a light-weight window manager. Usually, the only application windows I have open are rxvt-unicode as my terminal emulator and firefox/iceweasel with the pentadactyl extension as my browser. Thus, I would expect that CPU usage of my idle system would be pretty much zero but instead firefox decides to constantly eat 10-15%. Probably to update some GIF animations or JavaScript (or nowadays even HTML5 video animations). But I don't need it to do that when I'm not currently looking at my browser window. Disabling all JavaScript is no option because some websites that I need for uni or work are just completely broken without JavaScript, so I have to enable it for those websites. Solution: send SIGSTOP when my firefox window looses focus and send SIGCONT once it gains focus again. The following addition to my /etc/xdg/awesome/rc.lua does the trick: Since I'm running Debian, the class is "Iceweasel" and not "Firefox". When the window gains focus, a SIGCONT is sent immediately. I'm executing kill because I don't know how to send UNIX signals from lua directly. When the window looses focus, then the SIGSTOP signal is only sent after a 10 second timeout. This is done for several reasons:

• I don't want firefox to stop in cases where I'm just quickly switching back and forth between it and other application windows
• When firefox starts, it doesn't have a window for a short time. So without a timeout, the process would start but immediately get stopped as there is no window to have a focus.
• when using the X paste buffer, then the application behind the source window must not be stopped when pasting content from it. I assume that I will not spend more than 10 seconds between marking a string in firefox and pasting it into another window

With this change, when I now open htop, the process consuming most CPU resources is htop itself. Success! Another cool advantage is, that firefox can now be moved completely into swap space in case I run otherwise memory hungry applications without ever requiring any memory from swap until I really use it again. I haven't encountered any disadvantages of this setup yet. If 10 seconds prove to be too short to copy and paste I can easily extend this delay. Even clicking on links in my terminal works flawlessly - the new tab will just only load once firefox gets focused again. EDIT: thanks to Helmut Grohne for suggesting to compare the pid instead of the raw client instance to prevent misbehaviour when firefox opens additional windows like the preferences dialog.

While I don't consider myself part of the science fiction community directly (my con-going days are probably over), I do follow it across a wide variety of blogs. There are a lot of hard conversations and considerable soul-searching going on right now concerning an on-line commentator in that community who had been nasty and vicious to people, but originally for reasons that many people thought were good causes. (I had been one of those people. It's always very, very tempting to appreciate a good vitriolic rant from someone who shares your world view. And very easy to lose track of the people those rants are aimed at, or the excesses to which those rants go.) I'm not going to go into the details of the SF community issues here, since I have no context other than what I've read, and it's something to work out within that community. But I've been taking it as a useful reminder that abusive behavior is not acceptable, even if it comes from people who are arguably on your side. Anger is important. Anger is often how the world changes. But anger and abuse are not the same thing. I wrote something a little bit ago in a different context. Given that reminder, and given some of the arguments that are going on in the free software community as well, it seemed like a good idea to post a somewhat edited version of it in a more public place: None of us should be willing to continue to participate in a project in which we're expected to tolerate being abused and attacked, and all consequences of that abuse are our problem to deal with. It is simply not fun, and not motivating, and not interesting, and does not lead to us doing good work. I say this from lots of hard-won personal experience. I was deeply involved in Usenet governance for many years. I have made all the same arguments that I see today in favor of "blunt" speech, vitriol, and attacks. I have been a passionate advocate for the "free speech" approach. I have told other people to just filter and use killfiles. I have said that words aren't worth getting worked up about, and it's easy to ignore people. I was wrong. It took a long time for me to figure out that I was wrong, not just for other people, but for myself as well. It took me much longer to walk away from Usenet governance for good because the environment was too toxic. It remains one of the best decisions I have ever made in my life. It was the best bit of self-care that I ever did. I learned from that experience, and earlier this year, I walked away from a job for related reasons. I enjoyed the work, the job was much easier than the job that I have now, and I had a lot of time to work on free software and on Debian, but the emotional environment was toxic. (It was not as openly abusive, but it was an environment of disrespect, hierarchical dominance games, fear, blame, and emotional blackmail.) As a result, I've had to shift priorities considerably, but I'm a much happier person. It's worth having less time for things that I was previously enjoying to not to have to deal with an emotionally negative and confrontational environment. Life is too short, and I have the luxury of having choices. Both of those incidents taught me that it's very easy for me to leave that sort of situation to fester for too long, and that I underestimate how much of an improvement it is for my quality of life to walk away from abusive and negative emotional situations. I am belatedly learning how to be more ready and willing to do this. I very much understand the people who are concerned with ensuring there is space for strongly-worded opinions and heartfelt anger. But we have to draw a line, and that line needs to rule out emotional abuse of people in our community even in the name of passionate polemics about something that's important. We have to enforce that line, and if that means ejecting people from our community, that's what we have to do. Because, if we don't, we're also ejecting people from our community: the quiet people, the people who are just trying to get work done, or the people who have had past experience with abusive environments and understand the need to bail when an environment starts going in that direction. I'm not going to put up with the sort of environment I put up with when doing Big Eight newsgroup creation. I'm not saying this as some sort of threat -- I'm saying this to try to be very clear that not standing up for the members of our community and not supporting each other against abuse and emotional attacks also has consequences, and will destroy that community for a lot of us. I'm saying that I am not interested in living in an environment of fear and blame. And one should never underestimate the human power of giving people space and community in which they can be comfortable, relaxed, and truly happy. Walking the line between this stance and the "tone argument," in which people who are being abused or disenfranchised are attacked for being angry, is very difficult. There are some helpful rules of thumb, such as distinguishing between punching up and punching down, but those rules of thumb can fail or be distorted, as the SF community is learning. It's important that people be able to express anger. It's also important that people be able to name names and identify specific behaviors that they believe are worthy of that anger. But when that anger escalates into attacks, there is a real danger that passionate righteousness turns into passionate abusiveness, a danger of losing the sense of community in our own sense of righteousness. And that's not something we can or should accept. It's going to take a lot of hard work, a lot of open conversation, and a lot of empathy and care to find that line. There are many things in the world right now that should provoke anger, and with that anger comes power for good. But with that anger can also come a destructive blindness. The anger I want is the anger that drives us to change the world together, the anger that leads to confronting others with a reflection of their own better natures and challenging them to become better, more compassionate people. The anger that leads a man to feed the homeless in the true meaning of civil disobedience. Not the anger that crushes our enemies.

On Friday October 31, 2014, and Saturday November 1, 2014, around thirty-five graduate students and faculty members attended a Software Carpentry workshop. Attendees came primarily from the Economics department and the Kellogg School of Management, which was also the host and sponsor providing an excellent venue with the Allen Center on the (main) Evanston campus of Northwestern University. The focus of the two-day workshop was an introduction, and practical initiation, to working effectively at the shell, getting introduced and familiar with the git revision control system, as well as a thorough introduction to working and programming in R---from the basics all the way to advanced graphing as well as creating reproducible research documents. The idea of the workshop had come out of discussion during our R/Finance 2014 conference. Bob McDonald of Northwestern, one of this year's keynote speakers, and I were discussing various topic related to open source and good programming practice --- as well as the lack of a thorough introduction to either for graduate students and researcher. And once I mentioned and explained Software Carpentry, Bob was rather intrigued. And just a few months later we were hosting a workshop (along with outstanding support from Jackie Milhans from Research Computing at Northwestern). We were extremely fortunate in that Karthik Ram and Ramnath Vaidyanathan were able to come to Chicago and act as lead instructors, giving me an opportunity to get my feet wet. The workshop began with a session on shell and automation, which was followed by three session focusing on R: a core introduction, a session focused on function, and to end the day, a session on the split-apply-combine approach to data transformation and analysis. The second day started with two concentrated session on git and the git workflow. In the afternoon, one session on visualization with R as well as a capstone-alike session on reproducible research rounded out the second day.

Things that worked The experience of the instructors showed, as the material was presented and an effective manner. The selection of topics, as well as the pace were seen by most students to be appropriate and just right. Karthik and Ramnath both did an outstanding job. No students experienced any real difficulties installing software, or using the supplied information. Participants were roughly split between Windows and OS X laptops, and had generally no problem with bash, git, or R via RStudio. The overall Software Carpentry setup, the lesson layout, the focus on hands-on exercises along with instruction, the use of the electronic noteboard provided by etherpad and, of course, the tried-and-tested material worked very well.

Things that could have worked better Even more breaks for exercises could have been added. Students had difficulty staying on pace in some of the exercise: once someone fell behind even for a small error (maybe a typo) it was sometimes hard to catch up. That is a general problem for hands-on classes. I feel I could have done better with the scope of my two session. Even more cohesion among the topics could have been achieved via a single continually used example dataset and analysis.

Acknowledgments Robert McDonald from Kellogg, and Jackie Milhans from Research Computing IT, were superb hosts and organizers. Their help in preparing for the workshop was tremendous, and the pick of venue was excellent, and allowed for a stress-free two days of classes. We could not have done this without Karthik and Ramnath, so a very big Thank You to both of them. Last but not least the Software Carpentry 'head office' was always ready to help Bob, Jackie and myself during the earlier planning stage, so another big Thank You! to Greg and Arliss.

A minor bugfix release 0.1.1 of the RPushbullet package (interfacing the neat Pushbullet service) landed on CRAN yesterday morning. It cleans up a small issue related to the ability to transfer files between devices via the Pushbullet service where the ability to select a (non-default) target device has now been restored. With that, allow me to borrow one excellent use case of RPushbullet from the blog of Karl Broman: how to use RPushbullet for error notifications from R:

options(error = function()  
    library(RPushbullet)
    pbPost("note", "Error", geterrmessage())
 )

This is very clever: should an error occur, you get immediate notification in browser or on your phone. Left as an exercise for the reader is to combine this with the equally excellent rfoaas package (github cran) to get appropriately colourful error messages... More details about the package are at the RPushbullet webpage and the RPushbullet GitHub repo. Courtesy of CRANberries, there is also a diffstat report for this release.

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

We the Debian Qt/KDE Team want to early-announce [maintainer warning] our decision to remove Qt4 from Jessie+1. This warning is mostly targeted at upstreams.

Qt4 has been deprecated since Qt5's first release on December 19th 2012, that means almost two years ago!

So far we had bugfixes-only releases, but upstream has announced that they will end this support on august 2015. This already means we will have to do a special effort from that point on for Jessie in case RC bugs appears, so having it in Jessie+1 is simply a non-go.

Some of us where involved in various Qt4 to Qt5 migrations [0] and we know for sure that porting stuff from Qt4 to Qt5 is much much easier and less painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4. In order to easy the transition time we have provided Wheezy backports for Qt5.

Don't forget to take a look at the C++ API change page [1] whenever you start porting your application.

[0] http://perezmeyer.blogspot.com.ar/2014/03/porting-qt-4-apps-to-qt-5-example-with.html
[1] http://qt-project.org/doc/qt-5.0/qtdoc/sourcebreaks.html

[maintainer warning] **Remember the freeze** and do not upload packages ported to Qt5 to unstable. The best thing you can do now is to ask your upstream if the code can be compiled against Qt5 and, why not, try it yourself.

Our first priority now is to release Jessie, and this is why this is an early announce.

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Packaging work With the Jessie freeze approaching, I took care of packaging some new upstream releases that I wanted to get in. I started with zim 0.62, I had skipped 0.61 due to some annoying regressions. Since I had two bugs to forward, I took the opportunity to reach out to the upstream author to see if he had some important fixes to get into Jessie. This resulted in me pushing another update with 3 commits cherry picked from the upstream VCS. I also sponsored a wheezy-backports of the new version. I pushed two new bugfixes releases of Publican (4.2.3 and 4.2.6) but I had to include a work-around for a bug that I reported earlier on docbook-xml (#763598: the XML catalog doesn t allow libxml2/xmllint to identify the local copy of some entities files) and that is unlikely to be fixed in time for Jessie. Last but not least, I pushed the first point release of Django 1.7, aka version 1.7.1 to unstable and asked release managers to ensure it migrates to testing before the real freeze. This is important because the closer we are to upstream, the easier it is to apply security patches during the lifetime of Jessie (which will hopefully be 5 years, thanks to Debian LTS!). I also released a backport of python-django 1.7 to wheezy-backports. I sponsored galette 0.7.8+dfsg-1 fixing an RC bug so that it can get back to testing (it got removed from testing due to the bug). Debian LTS See my dedicated report for the paid work I did on that area. Apart from that, I took some time to get in touch with all the Debian consultants and see if they knew some companies to reach out. There are a few new sponsors in the pipe thanks to this, but given the large set of people that it represents, I was expecting more. I used this opportunity to report all bogus entries (i.e bouncing email, broken URL) to the maintainer of the said webpage. Distro Tracker Only 30 commits this month, with almost no external contribution, I m a bit saddened by this situation because it s not very difficult to contribute to this project and we have plenty of easy bugs to get you started. That said I m still happy with the work done. Most of the changes have been made for Kali but will be useful for all derivatives: it s now possible to add external repositories in the tracker and not display them in the list of available versions, and not generate automatic news about those repositories. There s a new derivative application which is only in its infancy but can already provide a useful comparison of a derivative with its parent. See it in action on the Kali Package Tracker: http://pkg.kali.org/derivative/ Thanks to Offensive Security which is sponsoring this work! Since I have pushed Django 1.7 to wheezy-backports, all distro tracker instances that I manage are now running that version of Django and I opted to make that version mandatory. This made it possible to add initial Django migrations and rely on this new feature for future database schema upgrade (I have voluntarily avoided schema change up to now to avoid problems migrating from South to Django migrations). Thanks See you next month for a new summary of my activities.

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

Follow me on Identi.ca or Twitter or Diaspora* This is a feedback about installing a self hosted instance of Friendica on a Debian server (Jessie). If you re not interested in why I use Friendica, just go to Prerequisite for Friendica section below. Frustration about social networks Being a huge user of short messages, I was quite frustated to spend so much time on my Twitter account. To be quite honest, there is no much I like about this social network, except the huge population of people being potentially interested in what I write. I also have been using Identi.ca (now powered by Pump.io) for a while. But I tried for a while to manage both networks Pump.io and Twitter by hand and it was quite painful. And something was telling me another social network was going to appear from nowhere one of these days and I ll be just horrible to try to keep it up this way. So I was looking for a scalable solution not asking too much personal investment. Subscribing to Diaspora* some days ago on the Framasphere pod, tintouli told me to try Friendica. Hmmm, what s Friendica ? Friendica is a content manager you can plug on almost anything: social networks (Facebook, Twitter, Pump.io, Diaspora*, ), but also WordPress, XMPP, emails I m in fact just discovering the power of this tool but to plug it on my different social network accounts was quite a good use case for me. And I guess if you re still reading, for you too. I tried to use some shared public servers but I was not quite happy with the result, one connector was still missing or public servers were really unstable. So I m at last self hosting my Friendica. Here is how. Prerequisite for Friendica You need to install the following packages: # apt-get install apache2 libapache2-mod-php5 php5 php5-curl php5-gd php5-mysql mysql-server git Having a already self-modified /etc/php5/apache2/php.ini, I encountered a small issue with libCurl and had to manually add the following line in the php.ini: extension=curl.so Setting up MySQL Connect to MySQL and create an empty database with a dedicated user: # mysql -u root -pV3rYS3cr3t -e create database friendica; GRANT ALL PRIVILEGES ON friendica.* TO friendica@localhost IDENTIFIED BY R3AlLyH4rdT0Gu3ss Setting up Apache My server hosts several services, so I use a subdomain friendica.mydomain.com. If you use a subdomain, of course check you do have declared this subdomain in your DNS zone. I use SSL encryption with a wildcard certificate for all my subdomains. My Friendica data are stored in /var/www/friendica. Here is my virtual host configuration for Friendica stored in the file /etc/apache2/sites-available/friendicassl.conf : <VirtualHost *:443>
ServerName friendica.mydomain.com
DocumentRoot /var/www/friendica/
DirectoryIndex index.php index.html
ErrorLog /var/log/apache2/friendica-error-ssl.log
TransferLog /var/log/apache2/friendica-access-ssl.log SSLEngine on
SSLCertificateFile /etc/ssl/certs/mydomain/mydomain.com.crt
SSLCertificateKeyFile /etc/ssl/private/mydomain.com.key
SSLVerifyClient None <Directory /var/www/friendica/>
AllowOverride All
Options FollowSymLinks
Order allow,deny
Allow from all
</Directory>
</VirtualHost> After writing the configuration file, just launch the following commands and it should be good for the Apache configuration: # a2ensite friendicassl && /etc/init.d/apache2 reload Setting up Friendica Get the master zip file of Friendica, copy it on your server and decompress it. Something like : # cd /var/www/ && wget https://github.com/friendica/friendica/archive/master.zip && unzip master.zip && mv friendica-master friendica You need to give www-data (Apache user) the rights to write in /var/www/friendica/view/smarty3/ : # chown -R www-data:www-data /var/www/friendica/view/smarty3 && chmod -R ug+w var/www/friendica/view/smarty3 Ok, I guess we re all set, lets launch the installation process! Using your web browser, connect to friendica.mydomain.com. First step you ll see the installation window which checks the prerequisite before installing. Complete if something is missing. Second step asks the host/user/password of the database, complete and the installation process starts. Hopefully all goes just fine. Next you ll have to create a /var/www/friendica/.htconfig.php with the content that the last page of the installation process provides. Just copy/paste, check the rights of this file and now you can connect again to see the register page of friendica at the url https://friendlica.mydomain.com/register . Pretty cool! Register a user That s a fairly easy step. You just need to check before that your server is able to send emails, because the password is going to be sent to you by email. If it is ok, you should now identify on the welcome page of friendica and access your account. That s a huge step to broadcast your short messages everywhere, but we have some last steps before being able to send your short messages on all the social networks we need. A small break, create an app for twitter on apps.twitter.com To send your short messages to Twitter, you need to create an app on apps.twitter.com. Just check you re logged in Twitter and connect to apps.twitter.com. Create an app called with a unique name (apparently), then go to the Keys and Access tokens page, note the consumer key and the consumer secret. You ll later need the name of the app, the consumer key and the consumer secret. Install and configure the addons Friendica uses an addon system in order to plug on the different third-parties it needs. We are going to configure Twitter, Pump.io and the Diaspora* plug. Let s go back to our server and launches some commands: # cd /tmp && git clone https://github.com/friendica/friendica-addons.git && cd friendica-addons # tar xvf twitter.tgz -C /var/www/friendica/addon # tar xvf pumpio.tgz -C /var/www/friendica/addon # cp -a diaspora /var/www/friendica/addon You need to modify your /var/www/friendica/.htconfig.php file and add the following content at the end: // names of your addons, separated by a comma $a->config['system']['addon'] = pumpio, twitter, diaspora ; // your Twitter consumer key
$a->config['twitter']['consumerkey'] = P4Jl2Pe4j7Lj91eIn0AR8vIl2 ; // your Twitter consumer secret
$a->config['twitter']['consumersecret'] = 1DnVkllPik9Ua8jW4fncxwtXZJbs9iFfI5epFzmeI8VxM9pqP1 ; // you Twitter app name $a->config['twitter']['application_name'] = whatever-twitter ; Connect again to Friendica. Go to settings => social networks, you will see the options for Twitter, Pump.io and Diaspora*. Complete the requested information for each of them. Important options you should not forget to check are: Pump.io

• Enable pump.io Post Plugin
• Post to pump.io by default
• Should posts be public?

Twitter

• Authorize publication on Twitter
• Post to Twitter by default

Diaspora*

• Post to Diaspora by default

Done? Now it s time to send your first broadcasted short message. Yay! Send a short message to your different social networks Connect to Friendica, click on the network page, write your short message in the Share box. Click on the lock , you ll see the following setup: It means your short messages will be broadcasted to the three networks. Or more, it s up to you! That s my setup, feel free to modify. Now close the lock window and send your message. For me it takes some time to appear on Twitter and Diaspora* and it immediatly appears on Identi.ca. Last words Friendica offers to take back the control of your data, by broadcasting content on different media from a single source. While self hosting, you keep your data whatever happends and are not subject to companies losing your data like recently Twitpic. Moreover the philosophy behind Friendica pushed me to dig and test the solution What about you? How do you proceed to broadcast your short messages? Does Friendica offer a good solution in your opinion? Are you interested in the philosophy behind this project? Feel free to share your thoughs in the comments. LAST MINUTE: hey, this article is on Hacker News, don t hesitate to vote for it if you liked it!

During October, I spent 10 hours on paid LTS work. I should have worked 4 hours more, but for various reasons this did not happen. Instead I ll spend 4 more hours in November. During this time, I did the following:

• CVE triage: this month I pushed 23 commits to the security tracker SVN repository, and filed #765352 against wpa.
• I released a mysql-5.1 update (DLA-75-1) fixing 3 CVE.
• I sponsored the upload of ppp 2.4.5-4+deb6u1 for DLA-74-1 which had been prepared by Andrew Bartlett.
• I uploaded a new version of apache2 (DLA-71-1) fixing 2 CVE.
• I filed a few bugs against debian-security-support to request that some packages be marked as unsupported in squeeze: #765374 for axis2c and
  rampart, #765452 for a new feature allowing binary packages to be marked as unsupported so that glassfish-appserv can be marked as such (this is #765454).

After a few months of work on LTS, I m starting to have a better grasp on the worflow and on what can be done or not. But I m still astonished that we have so few squeeze users on the mailing list. If you re using Squeeze, please subscribe to the list and test the packages that contributors are submitting for tests/validation. It really helps to have some feedback from real users before releasing an update, in particular when the Debian contributor who prepared the update is not a user of said package not everybody has the skills required to prepare security updates, but everybody can help test packages, you have no excuses. And we still need more organizations joining the LTS project, either by providing help (like Catalyst did by letting Andrew Bartlett work on LTS, thanks to them!) or by sponsoring the
project and letting others do the work.

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