I found an interesting side-effect of the Juniper firewalls when you introduce IPv6. In hindsight it appears perfectly reasonable but if you are not aware of it in the first place you may have a much more permissive firewall than you thought. My setup is such that my internet address changes every time I connect to an ISP. I have services behind the Juniper that I want to expose onto the Internet, in this case a mailserver. Most of the documentation states to have a reasonably open firewall rule and a nat rule.

[edit security nat]
destination  
    pool mailserver-smtp  
        address 10.1.1.1/32 port 25;
     
 
[edit security policies]
from-zone Internet to-zone Internal  
    policy Mailserver  
        match  
            source-address any;
            destination-address any;
            application smtp;
         
        then  
             permit;
         
    
 

Pretty standard stuff and its documented in plenty of places. We cannot set a destination address because its dynamic, so set it to all. My next step was, ok my mailserver is on IPv4 and IPv6, how do I let the IPv6 connections in? Any means ANY That s where I noticed I had a problem, they could already get in. In fact anyone could get to the mailserver (good) and anything else that had an open SMTP port on my network and used IPv6 (bad). It seems that any destination address means ANY IPv4 or IPv6 address. Both myself and the writers of the documentation hadn t initially thought of what happens when you add IPv6. The solution is to not let any destination, but any IPv4 and the specific mailserver destination. First create an addressbook entry for the IPv6 address of the mailserver.

[edit security address-book global]
address mailserver-ipv6 2001:Db8:1111:2222::100/128;

then adjust the rule

[edit security policies]
from-zone Internet to-zone Internal  
    policy Mailserver  
        match  
            source-address any;
            destination-address [ any-ipv4 mailserver-ipv6];
            application smtp;
         
        then  
             permit;
         
    
 

That way there is access to the mailserver using either IPv4 or IPv6. I m also going to try to see if I adjust the rule so the destination only includes the mailserver address (both IPv4 and IPv6) even though the IPv4 is NATed and see if that works.

A new release 0.2.12 of RInside is now on CRAN. RInside provides a set of convenience classes which facilitate embedding of R inside of C++ applications and programs, using the classes and functions provided by the Rcpp integration package. This release adds new examples which were contributed by Christian Authmann, plus some updates and fixes including one requested by the CRAN maintainers regarding GNU extensions to Makefile. The NEWS extract below has more details.

Changes in RInside version 0.2.12 (2015-01-27)

• Several new examples have been added (with most of the work done by Christian Authmann):
  • standard/rinside_sample15.cpp shows how to create a lattice plot (following a StackOverflow question)
  • standard/rinside_sample16.cpp shows object wrapping, and exposing of C++ functions
  • standard/rinside_sample17.cpp does the same via C++11
  • sandboxed_servers/ adds an entire framework of client/server communication outside the main process (but using a subset of supported types)
• standard/rinside_module_sample9.cpp was repaired following a fix to InternalFunction in Rcpp
• For the seven example directories which contain a Makefile, the Makefile was renamed GNUmakefile to please R CMD check as well as the CRAN Maintainers.

CRANberries also provides a short report with changes from the previous release. More information is on the RInside page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp 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.

In the middle of OPW internship I originally thought taking part in FOSSOPW is a great chance to lift my coding skills and I shouldn t miss it. As time passes by, I now have a new thought towards it. # 1 It do improves your coding skill. Zack, Matthieu and I often have discussions on coding style. For example, once Zack said, For code like this, you should explicitly use an if/else clause, not if-return. I was totally unaware of this sort of issue. Actually I even didn t know how I should call this problem. Matthieu gave me a detailed FYI link on this in no time. Besides, my completeness of thinking is also trained. Recently, I was fixing a HTTP GET Method ?suite=suite-name issue. It s a trivial task. And you know most trivial tasks require lots of scattered modification on the source code base. I did have fixed most places, such as the pages of /src/packagename and /search/ . Zack did a thorough review, and pointed out that the pages rendered by /prefix has some malformed urls in the HTML. Waiiiit, I should have noticed it. But somehow I missed it. Maybe because my mind was wandering at that time? This made me think, I shall have a thorough view of what I should do before getting my hands dirty. Or more preferably, if I could write down what I exactly want to achieve before coding, then silly problems definitely wouldn t occur. This may sound a little bit like TDD. ;). # 2 It makes you look like a (not-that-good) ninja. I use a macbook. It s not my fault! I ve tried several times, but I never successfully find a laptop that is not capable of boiling eggs when running Debian. (and especially KDE+Debian). So I have no way but switched to OSX. The development of Debsources happens on a remote Ubuntu LTS (now Debian SID, haha) virtual machine. Of course I have to install all the dependency on my own, e.g., Postgres, set up port-forwarding, e.g., ssh -D, write automate shell scripts, e.g., dash, but more importantly, I am forced to live under the dark terminal with no GUI. You know the feeling when pain hurts? Yes, exactly! But I survived. How shall I call myself now? A dedicated with-a-lot-of-useless-plugin-installed vimmer? A fond-of-fancy-window tmux-er? Yep, both. I finally found a comfort zone under the black-white-blinking screen. I wonder how people feel when they see a girl hanging out in the library, facing a full-screened black console, typing at a speed of 140wpm (Yeah, I am kidding). I don t know, but please don t call me a geek. Show me your respect, I am a ninja! # 3 It tells you communication is the most important. I bet anyone who has participated in a group-based project would understand what I mean. For one perspective, communication helps to eliminate misunderstanding. So I won t doing some useless stuff for all day and finally find out that it totally doesn t meet the requirement. On the other hand, it speeds up your learning process. I often have problems on git. So in the email I will complain if I mess up with the git repo. After a short while, my dear mentors will reply in detail on how to correctly do the git stuff. My OPW journey is cool! ;).

Dear lazyweb, using a ThinkPad X1 Carbon with Debian unstable and KDE 4.14.2, I have not had battery warnings for a few weeks, now. The battery status can be read out via acpi -V as well as via the KDE widget. Hibernation via systemctl hibernate works as well. What does not work is the warning when my battery is low, or automagic hibernation when shutting the lid or when the battery level is critical. From what I gather, something in the communication between upower and KDE broke down, but I can't find what it is. I have also been told that Cinnamon is affected as well, so this seems to be a more general problem Sadly, me and anyone else who's affected has been unable to fix this. So, dear lazyweb, please help. In loosely related news, this old status is still valid. UMTS is stable-ish now but even though I saved the SIM's PIN, KDE always displays a "SIM PIN unlock request" prompt after booting or hibernating. Once I enter that PIN, systemd tells me that a system policy prevents the change and wants my user password. If anyone knows how to get rid of that, I would also appreciate any pointers.

I've done a bunch of hacking on the Redis key/value database server recently:

• Lua-based maxmemory eviction scripts. (#2319) (This changeset was sponsored by an anonymous client.) Redis typically stores the entire data set in memory, using the operating system's virtual memory facilities if required. However, one can use Redis more like a cache or ring buffer by enabling a "maxmemory policy" where a RAM limit is set and then data is evicted when required based on a predefined algorithm. This change enables entirely custom control over exactly what data to remove from RAM when this maxmemory limit is reached. This is an advantage over the existing policies of, say, removing entire keys based on the existing TTL, Least Recently Used (LRU) or random eviction strategies as it permits bespoke behaviours based on application-specific requirements, crucially without maintaining a private fork of Redis. As an example behaviour of what is possible with this change, to remove the lowest ranked member of an arbitrary sorted set, you could load the following eviction policy script:

  local bestkey = nil
  local bestval = 0
  for s = 1, 5 do
     local key = redis.call("RANDOMKEY")
     local type_ = redis.call("TYPE", key)
     if type_.ok == "zset"
     then
         local tail = redis.call("ZRANGE", key, "0", "0", "WITHSCORES")
         local val = tonumber(tail[2])
         if not bestkey or val < bestval
         then
             bestkey = key
             bestval = val
         end
     end
  end
  if not bestkey
  then
      -- We couldn't find anything to remove, so return an error
      return false
  end
  redis.call("ZREMRANGEBYRANK", bestkey, "0", "0")
  return true
  

• TCP_FASTOPEN support. (#2307) The aim of TCP_FASTOPEN is to eliminate one roundtrip from a TCP conversation by allowing data to be included as part of the SYN segment that initiates the connection. (More info.)

• Support infinitely repeating commands in redis-cli. (#2297)

• Add --failfast option to testsuite runner. (#2290)

• Add a -q (quiet) argument to redis-cli. (#2305)

• Making some Redis Sentinel defaults a little saner. (#2292)

---

I also made the following changes to the Debian packaging:

• Add run-parts(8) directories to be executed at various points in the daemon's lifecycle. (e427f8) This is especially useful for loading Lua scripts as they are not persisted across restarts.

• Split out Redis Sentinel into its own package. (#775414, 39f642) This makes it possible to run Sentinel sanely on Debian systems without bespoke scripts, etc.

• Ensure /etc/init.d/redis-server start idempotency with --oknodo (60b7dd) Idempotency in initscripts is especially important given the rise of configuration managment systems.

• Uploaded 3.0.0 RC2 to Debian experimental. (37ac55)

• Re-enabled the testsuite. (7b9ed1)

Conrad put up a maintenance release 4.600.4 of Armadillo a few days ago. As in the past, we tested this with number of pre-releases and test builds against the now over one hundred CRAN dependents of our RcppArmadillo package. The tests passed fine as usual, and results are as always in the rcpp-logs repository. Changes are summarized below based on the NEWS.Rd file.

Changes in RcppArmadillo version 0.4.600.4.0 (2015-01-23)

• Upgraded to Armadillo release Version 4.600.4 (still "Off The Reservation")
  • Speedups in the transpose operation
  • Small bug fixes

Courtesy of CRANberries, there is also a diffstat report for the most recent release. As always, more detailed information is on the RcppArmadillo page. 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.

A new release 0.11.4 of Rcpp is now on the CRAN network for GNU R, and an updated Debian package will be uploaded in due course. Rcpp has become the most popular way of enhancing GNU R with C++ code. As of today, 323 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 once again adds a large number of small bug fixes, polishes and enhancements. And like the last time, these changes were made by a group of seven different contributors (counting code commits) plus three more providing concrete suggestions. This shows that the Rcpp development and maintenance rests a large number of (broad) shoulders. See below for a detailed list of changes extracted from the NEWS file.

Changes in Rcpp version 0.11.4 (2015-01-20)

• Changes in Rcpp API:
  • The ListOf<T> class gains the .attr and .names methods common to other Rcpp vectors.
  • The [dpq]nbinom_mu() scalar functions are now available via the R:: namespace when R 3.1.2 or newer is used.
  • Add an additional test for AIX before attempting to include execinfo.h.
  • Rcpp::stop now supports improved printf-like syntax using the small tinyformat header-only library (following a similar implementation in Rcpp11)
  • Pairlist objects are now protected via an additional Shield<> as suggested by Martin Morgan on the rcpp-devel list.
  • Sorting is now prohibited at compile time for objects of type List, RawVector and ExpressionVector.
  • Vectors now have a Vector::const_iterator that is 'const correct' thanks to fix by Romain following a bug report in rcpp-devel by Martyn Plummer.
  • The mean() sugar function now uses a more robust two-pass method, and new unit tests for mean() were added at the same time.
  • The mean() and var() functions now support all core vector types.
  • The setequal() sugar function has been corrected via suggestion by Qiang Kou following a bug report by S ren H jsgaard.
  • The macros major, minor, and makedev no longer leak in from the (Linux) system header sys/sysmacros.h.
  • The push_front() string function was corrected.
• Changes in Rcpp Attributes:
  • Only look for plugins in the package's namespace (rather than entire search path).
  • Also scan header files for definitions of functions to be considerd by Attributes.
  • Correct the regular expression for source files which are scanned.
• Changes in Rcpp unit tests
  • Added a new binary test which will load a pre-built package to ensure that the Application Binary Interface (ABI) did not change; this test will (mostly or) only run at Travis where we have reasonable control over the platform running the test and can provide a binary.
  • New unit tests for sugar functions mean, setequal and var were added as noted above.
• Changes in Rcpp Examples:
  • For the (old) examples ConvolveBenchmarks and OpenMP, the respective Makefile was renamed to GNUmakefile to please R CMD check as well as the CRAN Maintainers.

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.

A new version of RcppGSL is now on CRAN. This package provides an interface from R to the GNU GSL using our Rcpp package. This follows on the heels on the recent RcppGSL 0.2.3 release and extends the excellent point made by Qiang Kou in a contributed section of the vignette: We now not only allow to turn the GSL error handler off (to not abort() on error) but do so on package initialisation. No other user-facing changes were made. The NEWS file entries follows below:

Changes in version 0.2.4 (2015-01-24)

• Two new helper function to turn the default GSL error handler off (and to restore it) were added. The default handler is now turned off when the package is attached so that GSL will no longer abort an R session on error. Users will have to check the error code.
• The RcppGSL-intro.Rnw vignette was expanded with a short section on the GSL error handler (thanks to Qiang Kou).

Courtesy of CRANberries, a summary of changes to the most recent release is available. More information is on the RcppGSL page. 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.

A new version of RcppAnnoy is now on CRAN. RcppAnnoy wraps the small, fast, and lightweight C++ template header library Annoy written by Erik Bernhardsson for use at Spotify. RcppAnnoy uses Rcpp Modules to offer the exact same functionality as the Python module wrapped around Annoy. This version contains a trivial one-character change requested by CRAN to cleanse the Makevars file of possible GNU Make-isms. Oh well. This release also overcomes an undefined behaviour sanitizer bug noticed by CRAN that took somewhat more effort to deal with. As mentioned recently in another blog post, it took some work to create a proper Docker container with the required compiler and subsequent R setup, but we have one now, and the aforementioned blog post has details on how we replicated the CRAN finding of an UBSAN issue. It also took Erik some extra efforts to set something up for his C++/Python side, but eventually an EC2 instance with Ubuntu 14.10 did the task as my Docker sales skills are seemingly not convincing enough. In any event, he very quickly added the right fix, and I synced RcppAnnoy with his Annoy code. Courtesy of CRANberries, there is also a diffstat report for this release. More detailed information is on the RcppAnnoy page 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.

Lever Rukhin Photographs Los Angeles From His Car
Lever Rukhin shoots the sketchiest parts of Los Angeles from his car, taking a really unique perspective that helps you perceive what LA looks like, if you were in a car An experience that is apparently common to all LA people. People drive too much in the US :-). It s a very interesting interview that goes well with his full site: Lev Rukhin. What I love about this, besides the whole premise, is that Lev went the extra mile and actually hacked his car to make the images he wanted:

Phoblographer: It looks like many of these images have artificial lighting in them. What s your gear setup, and how do you introduce so much light into the scene from your car? Lever: About 9 months ago, I affixed a Mola beauty dish onto the roof rack of my 75 Volvo and juice it with a profoto bi-tube. This takes a bit of practice, as making a turn changes the light completely, which I always try to keep balanced. The Canon 5D3 with a 24mm f1.4 is set up on a tripod. The strobe has allowed me to capture more detail as well as creating a somewhat surreal feel to the sets.

Lev Rukhin http://www.levrukhin.com/

The Invisible Woman: A conversation with Bj rk
Bj rk is that Icelandic singer we all hear about but never really pay much attention to because her music is too smart for our simple ears. In this interview she goes over how her latest album is a very personal work, and unexpectedly (?) ends talking about how problematic it s been to be a female auteur in her generation. I have seen the same problem she denounces about people assuming that the male members of a team did all the work while the women just sticked to making coffee and sandwiches. I ve worked with exceptional women that don t get enough credit, but I ve also worked with potentially exceptional women who don t give themselves enough credit. It s a very interesting read, specially since it comes from someone who couldn t be higher in the art food chain. Bj rk is god-damn Bj rk. Only thing that bugs me is that Pitchfork decided to hold back most of the interview for publishing next month. I ll try to go back and read it in full, but I wonder if the technique works for them or if perhaps they are missing the opportunity for a bigger impact. But I digress.

Pitchfork: The world has a difficult time with the female auteur. B: I have nothing against Kanye West. Help me with this I m not dissing him this is about how people talk about him. With the last album he did, he got all the best beatmakers on the planet at the time to make beats for him. A lot of the time, he wasn t even there. Yet no one would question his authorship for a second. If whatever I m saying to you now helps women, I m up for saying it. For example, I did 80% of the beats on Vespertine and it took me three years to work on that album, because it was all microbeats it was like doing a huge embroidery piece. Matmos came in the last two weeks and added percussion on top of the songs, but they didn t do any of the main parts, and they are credited everywhere as having done the whole album. [Matmos ] Drew [Daniel] is a close friend of mine, and in every single interview he did, he corrected it. And they don t even listen to him. It really is strange.

In Defense of the Selfie Stick
Miguel proposes a different take on the consequences of the selfies stick:

When you ask someone to take a picture of you, technically, they are the photographer, and they own the copyright of your picture. ( ) All of a sudden, your backpacking adventure in Europe requires you to pack a stack of legal contracts. Now your exchange goes from Can you take a picture of us? to Can you take a picture of us, making sure that the church is on the top right corner, and also, I am going to need you to sign this paper .

I don t know what s with the selfie stick hate. Let people have fun, it doesn t hurt. If anything, it prevents them from asking you to take their photo, and if we already established you are the kind of people not a big fan of strangers, all the better, right? Why Top Tech CEOs Want Employees With Liberal Arts Degrees
Here s a small extra. When I decided to pursue a humanities/art formal training, I got many naysayers telling me that I was screwing up not specializing even more as a formal (titled) engineer. I argued then, and now, that if I was gonna pay for training, I might as well pay for training outside my comfort zone. The result resonates perfectly with this article. Of course, it s not like the thing is settled, but I can back the various quotes in there. Working with purely technical/engineering types can be an echo chamber, and having trained myself in the humanities and arts I have become incredibly much more sensitive to the human factor of things. I used to think I was already good at this (because we hacker types have lots of confidence), but studying humanities like human communication, social conflict and development, film language, etc; it all has made me a much more capable hacker of things. There s also a nice argument to be made about joining the arts when you are already highly skilled on technical matters. Like Robert Rodr guez s teacher (mentioned in his diary/book Rebel Without a Cause, which I also have to review soon) used to say (generous paraphrasing here): the world is of those who can be their own creative and their own technician.

Both Yi and Sheer recognize that the scientific method is valuable, with its emphasis on logic and reason, especially when dealing with data or engineering problems. But they believe this approach can sometimes be limiting. When I collaborate with people who have a strictly technical background, says Yi, the perspective I find most lacking is an understanding of what motivates people and how to balance multiple factors that are at work outside the realm of technology.

Interesting food for thought, specially if you know an engineer that ditches the arts as of little value for personal growth in their careers/life.

---

Read more Link Pack, you ll love it

Last weekend I went to Mumbai to attend the Mini-Debconf held at IIT-Bombay. These are my impressions of the trip. Arrival and Impressions of Mumbai Getting there was a quite an adventure in itself. Unlike during my ill-fated attempt to visit a Debian event in Kerala last year when a bureaucratic snafu left me unable to get a visa, the organizers started the process much earlier at their end this time and with proper permissions. Yet in India, the wheels only turn as fast as they want to turn so despite their efforts, it was only literally at the last minute that I actually managed to secure my visa. I should note however that Indian government has done a lot to improve the process compared to the hell I remember from, say, a decade ago. It's fairly straightforward for tourist visas now and I trust they will get around to doing the same for conference visas in the fullness of time. I didn't want to commit to buying a plane ticket until I had the visa so I became concerned that the only flights left would be either really expensive or on the type of airline that flies you over Syria or under the Indian Ocean. I lucked out and got a good price on a Swiss Air flight, not non-stop but you can't have everything. So Thursday afternoon I set off for JFK. With only one small suitcase getting there by subway was no problem and I arrived and checked in with plenty of time. Even TSA passed me through with only a minimal amount of indignity. The first leg of my journey took me to Zurich in about eight hours. We were only in Zurich for an hour and then (by now Friday) it was another 9 hours to Mumbai. Friday was Safala Ekadashi but owing to the necessity of staying hydrated on a long flight I drank a lot of water and ate some fruit which I don't normally do on a fasting day. It was tolerable but not too pleasant; I definitely want to try and make travel plans to avoid such situations in the future. Friday evening local time I got to Mumbai. Chhattrapati Shivaji airport has improved a lot since I saw t last and now has all the amenities an international traveller needs including unrestricted free wifi (Zurich airport are you taking notes?) But here my first ominous piece of bad luck began. No sign of my suitcase. Happily some asking around revealed that it had somehow gotten on some earlier Swiss Air flight instead of the one I was on and was actually waiting for me. I got outside and Debian Developer Praveen Arimbrathodiyil was waiting to pick me up. Normally I don't lke staying in Mumbai very much even though I have relatives there but that's because we usually went during July-August the monsoon season when Mumbai reverts back to the swampy archipelago it was originally built on. This time the weather was nice, cold by local standards, but lovely and spring-like to someone from snowy New Jersey. There have been a lot of improvements to the road infrastructure and people are actually obeying the traffic laws. (Within reason of course. Whether or not a family of six can arrange themselves on one Bajaj scooter is no business of the cops.) The Hotel Tuliip (yes, two i's. Manager didn't know why.) Residency where I was to stay while not quite a five star establishment was adequate for my needs with a bed, hot water shower, and air conditioning. And a TV which to the bellhops great confusion I did not want turned on. (He asked about five times.) There was no Internet access per se but the manager offered to hook up a wireless router to a cable. Which on closer inspection turned out to have been severed at the base. He assured me it would be fixed tomorrow so I didn't complain and decided to do something more productive thank checking my email like sleeping. The next day I woke up in total darkness. Apparently there had been some kind of power problem during the night which tripped a fuse or something. A call to the front desk got them to fix that and then the second piece of bad luck happened. I plugged my Thinkpad in and woke it up from hibernation and a minute later there was a loud pop from the power adapter. Note I have a travel international plug adapter with surge protector so nothing bad ought to have happened but the laptop would on turning on display the message "critical low battery error" and immediately power off. I was unable to google what that meant without Internet access but I decided not to panic and continue getting ready. I would have plenty of opportunity to troubleshoot at the conference venue. Or so I thought... I took an autorickshaw to IIT. There also there have been positive improvements. Being quite obviously a foreigner I was fully prepared to be taken along the "scenic route." But now there are fair zones and the rickshaws all have (tamperproof!) digital fare meters so I was deposited at the main gate without fuss. After reading a board with a scary list of dos and don'ts I presented myself at security only to be inexplicably waved through without a second glance. Later I found out they've abandoned all the security theatre but not got around to updating the signs yet. Mumbai is one of the biggest, densely populated cities in the world but the IIT campus is an oasis of tranquility on the shores of Lake Powai. It's a lot bigger than it looked on the map so I had to wander around a bit before I reached the conference venue but I did make for the official registration time. Registration I was happy to meet several old friends (Such as Kartik Mistry and Kumar Appiah who along with Praveen and myself were the other DDs there,) people who I've corresponded with but never met, and many new people. I'm told 200+ people registered altogether. Most seemed to be students from IIT and elsewhere in Mumbai but there were also some Debian enthusiasts from further afield and most hearteningly some "civilians" who wanted to know what this was all about. With the help of a borrowed Thinkpad adapter I got my laptop running again. (Thankfully, despite the error message, the battery itself was unharmed.) However, my streak of bad luck was not yet over. It was that very weekend that IIT had a freak campus-wide network outage something that had never happened before. And as the presentation for the talk I was to give had apparently been open when I hibernated my laptop the night before, the sudden forced shutdown had trashed the file. (ls showed it as 0 length. An fsck didn't help.) I possibly had a backup on my server but with no Internet access I had no way to retrieve it. I still remained cool. The talk was scheduled for the second day so I could recover it at the hotel. Keynotes Professor Kannan Maudgalya of the FOSSEE (Free and Open Source Software for Education) Project which is part of the central government Ministry for Human Resource Development spoke about various activities of his project. Of particular interest to us are:

• A scheme to get labs and college engineering/computer science departments off proprietary software by helping them identify relevant free software (writing it if necessary.) and helping them transition to it. Similarly getting curricula away from textbooks that use proprietary software by rewriting exercises to use free equivalents.
• A series of videos for self-instruction kind of like Khan Academy but geared to the challenges of being used in places where there might not be a net connection or even a trained teacher.
• The Vidyut tablet. A very low cost (~5000 Rupees) ARM-based netbook that runs Linux or Android software. You may have heard about earlier plans for a cheap tablet like this. Vidyut is the next generation correcting some flaws in previous attempts. Not only the software but the hardware is free too. It is currently running a stripped down version of Ubuntu but there was a request to port it to Debian and I'm happy to report several Debian users have accepted the challenge.

FOSSEE is well funded, backed by the government and has enthusiastic staff so we should be seeing a lot more from them in the future. Veteran Free Software activist Venky Hariharan spoke about his experiences in lobbying the government on tech issues. He noted that there has been a sea change in attitudes towards Linux and Open source in the bureacracy of late. Several states have been aggressively mandating the use of it as have several national ministries and agencies. We the community can provide a valuable service by helping them in the transition. They also need to be educated on how to work with the community (contributing changes back, not working behind closed doors etc.) Debian History and Debian Cycle Shirish Agarwal spoke about the Debian philosophy and foundational documents such as the social contract and DFSG and how the release cycle works. Nothing new to an experienced user but informative to the newcomers in the audience and sparked some questions and discussion. Keysigning One of my main missions in attending was to help get as many isolated people as possible into the web of trust. Unfortunately the keysigning was not adequately publicized and few people were ready. I would have led them through the process of creating a new key there and then but with the lack of connectivity that idea had to be abandoned. I did manage to sign about 8-10 keys during other times. Future Directions for Debian-IN BOF I led this one. Lots of spirited discussion and I found feedback from new users in particular to be very helpful. Some take aways are:

• Some people said it is hard to find concise, easily digestible information about what Debian can do. (I.e. Can I surf the web? Can I play a certain game? etc.) Debian-IN's web presence in particular needs a lot of improvement. We should also consider other channels such as a facebook page. A volunteer stepped up to look into these issues.
• Along these lines it was felt that we cannot just wait for people to come to us, we should do more outreach. I pointed out that one group that we need to reach out more to is the Debian Project at large. We need to do more publicity in debian-project, DWN, Planet etc. to let everyone know whats going on in India. I also felt that we have a strong base amongst CS/engineering students but should do more to attract other demographics.
• Debian events have suffered from organizational problems. Partly this is because the people involved are not professional event planners. They are learning how to do it which is an ongoing process and execution is improving with each iteration so no worries there but problems also arise because Debian-IN is dependent on other entities for many things and those entities do not always have, shall we say, the same sense of urgency. Therefore we need legal standing of our own for accepting donations, inviting foreign guests etc. This doesn't necessarily have to be a separate organization. Affiliating with an existing group is an option providing they share our ideology. Swathanthra Malayalam Computing was one suggestion.
• There is still not much Debian presence in the North and East of India. (Which includes large cities like Delhi and Kolkata.) Unfortunately until we can find volunteers in those areas to take the lead on organizing something there is not a lot we can do to rectify the situation.
• We must have Debian-IN t-shirts.

Lil' Debi Kumar Sukhani was a Debian GSoC student and his project which he demonstrated was to be able to install Debian on an Android phone. Why would you want to do this? Apart from the evergreen "Because I can", you can run server software such as sshd on your phone or even use it as an ARM development board. Unfortunately my phone uses Blackberry 10 OS which can run android apps (emulated under QNX) but wouldn't be able to use this. When I get a real Android phone I will try it out. Debian on ARM Siji Sunny gave this talk which was geared more towards hardware types which I am not but one thing I learned was thee difference between all the different ARM subarchitectures. I knew Siji first from a previous incarnation when he worked at CDAC with the late and much lamented Prof. R.K. Joshi. We had a long conversation about those days. Prof. Joshi/CDAC had developed an Indic rendering system called Indix which alas became the Betamax to Pango's VHS but he was also very involved in other Indic computing issues such as working with the Unicode Consortium and the preseration of Sanskrit manuscripts which is also an interest of mine. One good thing that cameout of Indix was some rather nice fonts. I had thought they were still buried in the dungeons of CDAC but apparently they were freed at one point. That's one more thing for me to look into. Evening/Next morning< My cousin met me and we had a leisurely dinner together. It was quite late by the time I got back to the hotel. FOSSEE had kindly lent me one of their tablets (which incidently are powerful enough to run LibreOffice comfortably.) so I thought I might be able to quickly redo my presentation before bedtime. Well, wouldn't you know it the wifi was not fixed. As I should have guessed but all the progress I'd had made me giddily optimistic. There was an option of trying to find an Internet cafe in a commercial area 15-20 minutes walk away. If this had been Gujarat I would have tried it but although I can more or less understand Hindi I can barely put together two sentences and Marathi I don't know at all. So I gave up that idea. I redid the slides from memory as best I could and went to sleep. In the morning I checked out and ferried myself and my suitcase via rickshaw back to the IIT campus. This time I got the driver to take me all the way in to the conference venue. Prof. Maudgalya kindly offered to let me keep the tablet to develop stuff on. I respectfully had to decline because although I love to collect bits of tech the fact it is it would have just gathered dust and ought to go to someone who can make a real contribution with it. I transferred my files to a USB key and borrowed a loaner laptop for my talk. Debian Packaging Workshop While waiting to do my talk I sat in on a workshop Praveen ran taking participants through the whole process of creating a Debian package (a ruby gem was the example.) He's done this before so it was a good presentation and well attended but the lack of connectivity did put a damper on things. Ask Me Anything It turned out the schedule had to be shuffled a bit so my talk was moved later from the announced time. A few people had already showed up so I took some random questions about Debian from them instead. GNOME Shell Accessibility With Orca Krishnakant Mane is remarkable. Although he is blind, he is a developer and a major contributor to Open Source projects. He talked about the Accessibility features of GNOME and compared them (favorably I might add) with proprietary screen readers. Not a subject that's directly useful to me but I found it interesting nonetheless. Rust: The memory safe language Manish Goregaokar talked about one of the new fad programming languages that have gotten a lot of buzz lately. This one is backed by Mozilla and it's interesting enough but I'll stick with C++ and Perl until one of the new ones "wins." Building a Mail Server With Debian Finally I got to give my talk and, yup, the video out on my borrowed laptop was incompatible with the projector. A slight delay to transfer everything to another laptop and I was able to begin. I talked about setting up BIND, postfix, and of course dovecot along with spamassassin, clamav etc. It turned out I had more than enough material and I went atleast 30 minutes over time and even then I had to rush at the end. People said they liked it so I'm happy. The End I gave the concluding remarks. Various people were thanked (including myself) mementos were given and pictures were taken. Despite a few mishaps I enjoyed myself and I am glad I attended. The level of enthusiasm was very high and lessons were learned so the next Debian-IN event should be even better. My departing flight wasn't due to leave until 1:20AM so I killed a few hours with my family before the flight. Once again I was stopping in Zurich, this time for most of a day. The last of my blunders was not to take my coat out of my suitcase and the temperature outside was 29F so I had to spend that whole time enjoing the (not so) many charms of Zurich airport. Atleast the second flight took me to Newark instead of JFK so I was able to get home a little earlier on Monday evening, exhausted but happy I made the trip.

---

---

Writing Your Way to Happiness (nytimes.com)
Researches believe that the way we think about, and remember, our story can be so powerful that it can actually influence our happiness and success. It s a nice little article summarizing actual research. The main study referred put fresh university students to test: a group received tools to rewrite their memory and story of their academic performance, another group didn t. The first group improved their grades and had only 1 student drop school within a year, the other group had 4 drop outs and no specific improvement. I ve been thinking about this as I recently rewrote my About page and also started writing down some past Travel journals. Looking back and rewriting your own story is incredibly empowering, it s a fantastic rush of confidence and self-assertion. Memory is always betraying us, and remembering our success is not particularly high on the list of things to keep.

The concept is based on the idea that we all have a personal narrative that shapes our view of the world and ourselves. But sometimes our inner voice doesn t get it completely right. Some researchers believe that by writing and then editing our own stories, we can change our perceptions of ourselves and identify obstacles that stand in the way of better health. It may sound like self-help nonsense, but research suggests the effects are real. Students who had been prompted to change their personal stories improved their grade-point averages and were less likely to drop out over the next year than the students who received no information. In the control group, which had received no advice about grades, 20 percent of the students had dropped out within a year. But in the intervention group, only 1 student or just 5 percent dropped out.

Old Masters at the Top of Their Game (nytimes.com)
Fantastic read on how these artists defy the conventions of old meaning useless. Masters at their art, they haven t quit nor have laid to rest and cash their reputation. They keep making, they stay alive (physically and metaphorically) through art. No rush to get to their age, but still a really interesting letter from the future . Full of cheat codes, read this now.

Now I am 79. I ve written many hundreds of essays, 10 times that number of misbegotten drafts both early and late, and I begin to understand that failure is its own reward. It is in the effort to close the distance between the work imagined and the work achieved wherein it is to be found that the ceaseless labor is the freedom of play, that what s at stake isn t a reflection in the mirror of fame but the escape from the prison of the self. T. H. White, the British naturalist turned novelist to write The Once and Future King, calls upon the druid Merlyn to teach the lesson to the young prince Arthur: You may grow old and trembling in your anatomies, you may lie awake at night listening to the disorder of your veins, you may miss your only love, you may see the world about you devastated by evil lunatics, or know your honour trampled in the sewers of baser minds. There is only one thing for it then to learn. Learn why the world wags and what wags it. That is the only thing which the mind can never exhaust, never alienate, never be tortured by, never fear or distrust, and never dream of regretting.

A Life with a View (ribbonfarm.com)
A somewhat tricky read, but with a nice payback. Take your time, and savor it slowly. It s a very interesting look into how we keep wanting new stuff, and how we shield from ourselves by looking for the place with no yearns , the place where we won t want anything anymore doesn t exist. Chains very well into the reads I shared a few days ago on practical contentment.

The arrival fallacy is about seeking a life from which one can look with a complacent equanimity upon the rest of reality, without yearning. It is an ideal of a life that is defined primarily by blindness to itself. You yearn while you see your life as others see it, until you arrive at a situation where you can disappear into the broader background, and see comfortably without being seen discomfittingly, especially by yourself. Once you re there, the yearning stops, so the theory goes. Of course it is a laughably bad theory.

How To Escape From A Moving Car (mrporter.com)
By Adam Kirley, stunt double for Daniel Craig in the crazy crane scene of Casino Royale (where 007 jumps from monkey nuts high to donkey bonkers high, a badger bum crazy distance). Really funny, and one of those things I always find myself thinking Almost as much as what to do in case of a Post Office Showdown (xkcd.com)

Everyone s first instinct is to put their hands or legs down first. That s the worst thing you can do: you will break something. The pointy parts of your body hurt elbows, knees, hips, ankles. Put your fists under your chin, and bring your elbows together. Keep your chin tucked in to your chest to protect your head. The best point of impact is the back of the shoulder and your back. If you dive out directly onto your shoulder you ll break it.

What the World Looks Like with Social Anxiety (collegehumor.com)
Funny vignettes about how the world looks like when you are socially anxious. I can only really identify with the last one:

Shea Strauss.

Helsinki Bus Station Theory (fotocommunity.com)
Don t get off the bus. Art comes to those who wait and persevere. At first, you replicate the same route others have done, but only if you stay long enough in such path you begin to find your own path. Although perhaps a little more classic in conception, this is an interesting text advising artists to don t give up just because they don t compare well to the masters of their current art or genre. Only those who persevere will catch up and diverge from the masters. You could say that diverging early is also a way to find your path, but there s still a case to be made for learning from those who came before. Whether you want to imitate them, or rebel against them, you still need to know them. My take: it doesn t hurt to pick up some biographies or works from past masters and see what made them masters. Create your master genealogy, kinda like in Steal Like an Artist (which I recently read but haven t got around to write about yet).

Georges Braque has said that out of limited means, new forms emerge. I say, we find out what we will do by knowing what we will not do. And so, if your heart is set on 8 10 platinum landscapes in misty southern terrains, work your way through those who inspire you, ride their bus route and damn those who would say you are merely repeating what has been done before. Wait for the months and years to pass and soon your differences will begin to appear with clarity and intelligence, when your originality will become visible, even the works from those very first years of trepidation when everything you did seemed so done before.

At 90, She s Designing Tech For Aging Boomers (npr.org)
The inspiring tale of a 90 year old woman who joined IDEO to contribute a unique point of view to the design process. You can never stop learning, life never ceases to be interesting. It s short, and not incredibly shocking, but that this has happened somewhere as referenced and revered as IDEO says a lot.

And for the bulging demographic of baby boomers growing old, Beskind has this advice: Embrace change and design for it.

---

Previously on Link Pack

Every now and then we get reports from CRAN about our packages failing a test there. A challenging one concerns UBSAN, or Undefined Behaviour Sanitizer. For background on UBSAN, see this RedHat blog post for gcc and this one from LLVM about clang. I had written briefly about this before in a blog post introducing the sanitizers package for tests, as well as the corresponding package page for sanitizers, which clearly predates our follow-up Rocker.org repo / project described in this initial announcement and when we became the official R container for Docker. Rocker had support for SAN testing, but UBSAN was not working yet. So following a recent CRAN report against our RcppAnnoy package, I was unable to replicate the error and asked for help on r-devel in this thread. Martyn Plummer and Jan van der Laan kindly sent their configurations in the same thread and off-list; Jeff Horner did so too following an initial tweet offering help. None of these worked for me, but further trials eventually lead me to the (already mentioned above) RedHat blog post with its mention of -fno-sanitize-recover to actually have an error abort a test. Which, coupled with the settings used by Martyn, were what worked for me: clang-3.5 -fsanitize=undefined -fno-sanitize=float-divide-by-zero,vptr,function -fno-sanitize-recover. This is now part of the updated Dockerfile of the R-devel-SAN-Clang repo behind the r-devel-ubsan-clang. It contains these settings, as well a new support script check.r for littler---which enables testing right out the box. Here is a complete example:

docker                              # run Docker (any recent version, I use 1.2.0)
  run                               # launch a container 
    --rm                            # remove Docker temporary objects when dome
    -ti                             # use a terminal and interactive mode 
    -v $(pwd):/mnt                  # mount the current directory as /mnt in the container
    rocker/r-devel-ubsan-clang      # using the rocker/r-devel-ubsan-clang container
  check.r                           # launch the check.r command from littler (in the container)
    --setwd /mnt                    # with a setwd() to the /mnt directory
    --install-deps                  # installing all package dependencies before the test
    RcppAnnoy_0.0.5.tar.gz          # and test this tarball

I know. It is a mouthful. But it really is merely the standard practice of running Docker to launch a single command. And while I frequently make this the /bin/bash command (hence the -ti options I always use) to work and explore interactively, here we do one better thanks to the (pretty useful so far) check.r script I wrote over the last two days. check.r does about the same as R CMD check. If you look inside check you will see a call to a (non-exported) function from the (R base-internal) tools package. We call the same function here. But to make things more interesting we also first install the package we test to really ensure we have all build-dependencies from CRAN met. (And we plan to extend check.r to support additional apt-get calls in case other libraries etc are needed.) We use the dependencies=TRUE option to have R smartly install Suggests: as well, but only one level (see help(install.packages) for details. With that prerequisite out of the way, the test can proceed as if we had done R CMD check (and additional R CMD INSTALL as well). The result for this (known-bad) package:

edd@max:~/git$ docker run --rm -ti -v $(pwd):/mnt rocker/r-devel-ubsan-clang check.r --setwd /mnt --install-deps RcppAnnoy_0.0.5.tar.gz 
also installing the dependencies  Rcpp ,  BH ,  RUnit 
trying URL 'http://cran.rstudio.com/src/contrib/Rcpp_0.11.3.tar.gz'
Content type 'application/x-gzip' length 2169583 bytes (2.1 MB)
opened URL
==================================================
downloaded 2.1 MB
trying URL 'http://cran.rstudio.com/src/contrib/BH_1.55.0-3.tar.gz'
Content type 'application/x-gzip' length 7860141 bytes (7.5 MB)
opened URL
==================================================
downloaded 7.5 MB
trying URL 'http://cran.rstudio.com/src/contrib/RUnit_0.4.28.tar.gz'
Content type 'application/x-gzip' length 322486 bytes (314 KB)
opened URL
==================================================
downloaded 314 KB
trying URL 'http://cran.rstudio.com/src/contrib/RcppAnnoy_0.0.4.tar.gz'
Content type 'application/x-gzip' length 25777 bytes (25 KB)
opened URL
==================================================
downloaded 25 KB
* installing *source* package  Rcpp  ...
** package  Rcpp  successfully unpacked and MD5 sums checked
** libs
clang++-3.5 -fsanitize=undefined -fno-sanitize=float-divide-by-zero,vptr,function -fno-sanitize-recover -I/usr/local/lib/R/include -DNDEBUG -I../inst/include/ -I/usr/local/include    -fpic  -pipe -Wall -pedantic -
g  -c Date.cpp -o Date.o
[...]
* checking examples ... OK
* checking for unstated dependencies in  tests  ... OK
* checking tests ...
  Running  runUnitTests.R 
 ERROR
Running the tests in  tests/runUnitTests.R  failed.
Last 13 lines of output:
  +     if (getErrors(tests)$nFail > 0)  
  +         stop("TEST FAILED!")
  +      
  +     if (getErrors(tests)$nErr > 0)  
  +         stop("TEST HAD ERRORS!")
  +      
  +     if (getErrors(tests)$nTestFunc < 1)  
  +         stop("NO TEST FUNCTIONS RUN!")
  +      
  +  
  
  
  Executing test function test01getNNsByVector  ... ../inst/include/annoylib.h:532:40: runtime error: index 3 out of bounds for type 'int const[2]'
* checking PDF version of manual ... OK
* DONE
Status: 1 ERROR, 2 WARNINGs, 1 NOTE
See
   /tmp/RcppAnnoy/..Rcheck/00check.log 
for details.
root@a7687c014e55:/tmp/RcppAnnoy# 

The log shows that thanks to check.r, we first download and the install the required packages Rcpp, BH, RUnit and RcppAnnoy itself (in the CRAN release). Rcpp is installed first, we then cut out the middle until we get to ... the failure we set out to confirm. Now having a tool to confirm the error, we can work on improved code. One such fix currently under inspection in a non-release version 0.0.5.1 then passes with the exact same invocation (but pointing at RcppAnnoy_0.0.5.1.tar.gz):

edd@max:~/git$ docker run --rm -ti -v $(pwd):/mnt rocker/r-devel-ubsan-clang check.r --setwd /mnt --install-deps RcppAnnoy_0.0.5.1.tar.gz
also installing the dependencies  Rcpp ,  BH ,  RUnit 
[...]
* checking examples ... OK
* checking for unstated dependencies in  tests  ... OK
* checking tests ...
  Running  runUnitTests.R 
 OK
* checking PDF version of manual ... OK
* DONE
Status: 1 WARNING
See
   /mnt/RcppAnnoy.Rcheck/00check.log 
for details.
edd@max:~/git$

This proceeds the same way from the same pristine, clean container for testing. It first installs the four required packages, and the proceeds to test the new and improved tarball. Which passes the test which failed above with no issues. Good. So we now have an "appliance" container anybody can download from free from the Docker hub, and deploy as we did here in order to have fully automated, one-command setup for testing for UBSAN errors. UBSAN is a very powerful tool. We are only beginning to deploy it. There are many more useful configuration settings. I would love to hear from anyone who would like to work on building this out via the R-devel-SAN-Clang GitHub repo. Improvements to the littler scripts are similarly welcome (and I plan on releasing an updated littler package "soon").

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

Intro I am not alone in considering Harold Abelson and Gerald Jay Sussman's recorded lectures based on their book "Structure and Interpretation of Computer Programs" is a masterpiece. There are many things to like about the content of the lectures, beginning with some pearls and wisdom about the craft of writing software (even though this is not really a "software enginneering" book), the clarity with which the concepts are described, the Freedom-friendly aspects of the authors regarding the material that they produced and much, the breadth of the subjects covered and much more.

The videos, their length, and splitting them The course consists of 20 video files and they are all uploaded on Youtube already. There is one thing, though: while the lectures are naturally divided into segments (the instructors took a break in after every 30 minutes or so worth of lectures), the videos corresponding to each lecture have all the segments concatenated. To better watch them, accounting for the easier possibility to put a few of the lectures in a mobile device or to avoid fast forwarding long videos from my NAS when I am watching them on my TV (and some other factors), I decided to sit down, take notes for each video of where the breaks where, and write a simple Python script to help split the videos in segments, and, then, reencode the segments. I decided not to take the videos from Youtube to perform my splitting activities, but, instead, to operate on one of the "sources" that the authors once had in their homepage (videos encoded in DivX and audio in MP3). The videos are still available as a torrent file (with a magnet link for the hash 650704e4439d7857a33fe4e32bcfdc2cb1db34db), with some very good souls still seeding it (I can seed it too, if desired). Alas, I have not found a source for the higher quality MPEG1 videos, but I think that the videos are legible enough to avoid bothering with a larger download. I soon found out that there are some beneficial side-effects of splitting the videos, like not having to edit/equalize the entire audio of the videos when only a segment was bad (which is understandable, as these lectures were recorded almost 30 years ago and technology was not as advanced as things are today). So, since I already have the split videos lying around here, I figured out that, perhaps, other people may want to download them, as they may be more convenient to watch (say, during commutes or whatever/whenever/wherever it best suits them). Of course, uploading all the videos is going to take a while and I would only do it if people would really benefit from them. If you think so, let me know here (or if you know someone who would like the split version of the videos, spread the word).

I signed up to the CPAN Pull Request Challenge - apparently I'm entrant 170 of a few hundred. My assigned dist for January was IO-Digest - this seems a fairly stable module. To get the ball rolling, I fixed the README, but this was somehow unsatisfying. :) To follow-up, I added Travis-CI support, with a view to validating the other open pull request - but that one looks likely to be a platform-specific problem. Then I extended the Travis file to generate coverage reports, and separately realised the docs weren't quite fully complete, so fixed this and added a test. Two of these have already been merged by the author, who was very responsive. Part of me worries that Github is a centralized, proprietary platform that we now trust most of our software source code to. But activities such as this are surely a good thing - how much harder would it be to co-ordinate 300 volunteers to submit patches in a distributed fashion? I suppose you could do something similar with the list of Debian source packages and metadata about the upstream VCS, say...

As I said, I did not certain events that begun with lea and end with ing prevent me from organising a Debian/m68k hack weekend. Well, that weekend is now. I m too unorganised, and I spent too much time in the last few evenings to organise things so I built up a sleep deficit already and the feedback was slow. (But so are the computers.) And someone I d have loved to come was hurt and can t come. On the plus side, several people I ve long wanted to meet IRL are coming, either already today or tomorrow. I hope we all will have a lot of fun. Legal disclaimer: Debian/m68k is a port of Debian to m68k. It used to be official, but now isn t. It belongs to debian-ports.org, which may run on DSA hardware, but is not acknowledged by Debian at large, unfortunately. Debian is a registered trademark owned by Software in the Public Interest, Inc.

Unfortunately I could not go on stage at the 31st Chaos Communication Congress to present reproducible builds in Debian alongside Mike Perry from the Tor Project and Seth Schoen from the Electronic Frontier Foundation. I've tried to make it up for it, though and we have made amazing progress. Wiki reorganization What was a massive and frightening wiki page now looks really more welcoming: Depending on what one is looking for, it should be much easier to find. There's now a high-level status overview given on the landing page, maintainers can learn how to make their packages reproducible, enthusiasts can more easily find what can help the project, and we have even started writing some history. .buildinfo for all packages New year's eve saw me hacking Perl to write dpkg-genbuildinfo. Similar to dpkg-genchanges, it's run by dpkg-buildpackage to produce .buildinfo control files. This is where the build environment, and hash of source and binary packages are recorded. This script, integrated with dpkg, replace the previous debhelper interim solution written by Niko Tyni. We used to fix mtimes in control.tar and data.tar using a specific addition to debhelper named dh_fixmtimes. To better support the ALWAYS_EXCLUDE environment variable and for pragramtic reasons, we moved the process in dh_builddeb. Both changes were quickly pushed to our continuous integration platform. Before, only packages using dh would create a .buildinfo and thus eventually be considered reproducible. With these modifications, many more packages had their chance and this shows: Yes, with our experimental toolchain we are now at more than eighty percent! That's more than 17200 source packages! srebuild Another big item on the todo-list was crossed over by Johannes Schauer. srebuild is a wrapper around sbuild:

Given a .buildinfo file, it first finds a timestamp of Debian Sid from snapshot.debian.org which contains the requested packages in their exact versions. It then runs sbuild with the right architecture as given by the .buildinfo file and the right base system to upgrade from, as given by the version of the base-files package version in the .buildinfo file. Using two hooks it will install the right package versions and verify that the installed packages are in the right version before the build starts.

Understanding problems Over 1700 packages have now been reviewed to understand why build results could not be reproduced on our experimental platform. The variations between the two builds are currently limited to time and file ordering, but this still has uncovered many problems. There are still toolchain fixes to be made (more than 180 packages for the PHP registry) which can make many packages reproducible at once, but others like C pre-processor macros will require many individual changes. debbindiff, the main tool used to understand differences, has gained support for .udeb, TrueType and OpenType fonts, PNG and PDF files. It's less likely to crash on problems with encoding or external tool. But most importantly for large package, it has been made a lot faster, thanks to Reiner Herrmann and Helmut Grohne. Helmut has also been able to spot cross-compilation issues by using debbindiff! Targeting our efforts It gives warm fuzzy feelings to hit the 80% mark, but it would be a bit irrelevant if this would not concern packages that matter. Thankfully, Holger worked on producing statistics for more specific package sets. Mattia Rizzolo has also done great work to improve the scripts generating the various pages visible on reproducible.debian.net. All essential and build-esential packages, except gcc and bash, are considered reproducible or have patches ready. After some lengthy builds, I also managed to come up with a patch to make linux build reproducibly. Miscellaneous After my initial attempt to modify r-base to remove a timestamp in R packages, Dirk Eddelbuettel discussed the issue with upstream and came up with a better patch. The latter has already been merged upstream! Dirk's solution is to allow timestamps to be set using an external environment variable. This is also how I modified FontForge to make it possible to reproduce fonts. Identifiers generated by xsltproc have also been an issue. After reviewing my initial patch, Andrew Awyer came up with a much nicer solution. Its potential performance implications need to be evaluated before submission, though. Chris West has been working on packages built with Maven amongst other things. PDF generated by GhostScript, another painful source of troubles, is being worked on by Peter De Wachter. Holger got X.509 certificates signed by the CA cartel for jenkins.debian.net and reproducible.debian.net. No more scary security messages now. Let's hope next year we will be able to get certificates through Let's Encrypt! Let's make a difference together As you can imagine with all that happened in the past weeks, the #debian-reproducible IRC channel has been a cool place to hang out. It's very energizing to get together and share contributions, exchange tips and discuss hardest points. Mandatory quote:

* h01ger is very happy to see again and again how this is a nice
         learning circle...! i've learned a whole lot here too... in
         just 3 months... and its going on...!

Reproducible builds are not going to change anything for most of our users. They simply don't care how they get software on their computer. But they care to get the right software without having to worry about it. That's our responsibility, as developers. Enabling users to trust their software is important and a major contribution, we as Debian, can make to the wider free software movement. Once Jessie is released, we should make a collective effort to make reproducible builds an highlight of our next release.

A new version of RcppGSL is now on CRAN today. This package provides an interface from R to the GNU GSL using our Rcpp. Similar to the recent RcppClassic release, this update was triggered by the CRAN maintainers desire to keep the Makefile free of GNU make extensions. At the same time we simplified the configure file a little, and refreshed the look and feel of the vignette. No user-facing changes were made. The NEWS file entries follows below:

Changes in version 0.2.3 (2015-01-10)

• The src/Makevars.in was pruned of GNU make features at the request of the CRAN Maintainers
• configure.ac and configure were updated, and shortened
• The RcppGSL-intro.Rnw vignette was updated for its look and feel.

Courtesy of CRANberries, a summary of changes to the most recent release is available. More information is on the RcppGSL page. 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.