For quite a while, Lintian has been able to create performance logs (--perf-debug --perf-output perf.log) that help diagnose where lintian spends most of its runtime. I decided to make lintian output these logs on lintian.debian.org to help us spot performance issues, though I have not been very good at analysing them regularly. At the beginning of the month, I finally got around to look a bit into one of them. My findings on IRC triggered Mattia Rizzolo to create this following graph. It shows the accumulated runtime of each check/collection measured in seconds. Find these findings, we set out to solve some of the issues. This lead to the following changes in 2.5.33 (in no particular order):

• Increased buffer size in check/cruft.pm to reduce overhead [bc8b3e5] (S)
• Reduced overhead in strings(1) extraction [b058fef] (P)
• Reduced overhead in spell-checking [b824170] (S)
  • Also improves the performance of spellintian!
• Removed a high overhead check that did not work [2c7b922] (P)

Legend: S: run single threaded (1:1 performance improvement). P: run in parallel. Overall, I doubt the changes will give a revolutionary change in speed, but it should improve the 3rd, 4th and 5th slowest parts in Lintian. Beyond runtime performance, we got a few memory optimisations in the pipeline for Lintian 2.5.34:

• Remove member from non-dir nodes in the Lintian path graph (2%) [6365635]
• Remove two fields at the price of computing them as needed (~5%) [a696197 + 8dacc8e]
• Merge 4 fields into 1 (~8%) [5d49cd2 + fb074e4]
• Share some memory between package-based caches (18%) [ffc7174]

Combined these 6 commits reduce memory consumption in caches by ~33% compared to 2.5.33, when lintian processes itself. In absolute numbers, we are talking about a drop from 12.53MB to 8.48MB. The mileages can certainly vary depending on the package (mscgen only saw an ~25% improvement). Nevertheless, I was happy to list #715035 as being closed in 2.5.34. :)
Filed under: Debian, Lintian

I ve been pretty quiet for the last few months because I m learning to fly. I want to start with a few quotes about aviation. I have heard things like these from many people and can vouch for their accuracy:

Anyone can learn to fly. Learning to fly is one of the hardest things you ll ever do. It is totally worth it. Being a pilot will give you a new outlook on life. You ll be amazed at what radios do a 3000ft. Have you ever had an 3000-foot antenna tower? The world is glorious at 1000ft up. Share your enthusiasm with those around you. You have a perspective very few ever see, except for a few seconds on the way to 35,000ft.

Earlier this month, I flew solo for the first time the biggest milestone on the way to getting the pilot s license. Here s a photo my flight instructor took as I was coming in to land that day. Today I took my first flight to another airport. It wasn t far about 20 miles away but it was still a thrill. I flew about 1500ft above the ground, roughly above a freeway that happened to be my route. From that height, things still look three-dimensional. The grain elevator that marked out the one small town, the manufacturing plant at another, the college at the third. Bales of hay dotting the fields, the occasional tractor creeping along a road, churches sticking up above the trees. These are places I ve known for decades, and now, suddenly, they are all new. What a time to be alive! I am glad that our world is still so full of wonder and beauty.

Another small update to RcppRedis arrived on CRAN this morning. The fix I made a few days ago addressing a unit test setup (for the rredis package loaded only for a comparison) didn't quite work out.

Changes in version 0.1.5 (2015-07-17)

• Another minor fix to unit test setup for rredis.

Courtesy of CRANberries, there is also a diffstat report for the most recent release. More information is on the RcppRedis 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.

We introduced RcppTOML in April with the initial CRAN release 0.0.3. It permits R to read the (absolutely awesome) TOML format which is simply fabulous for configuration files. A new version appeared on CRAN yesterday. We had observed a somewhat rare segfault in our production use which came down me dereferencing a list iterator which checking length first. Ooops. As usual, a few other changes were made as, mostly to stay on the good side of R CMD check --as-cran for the development version of R. Courtesy of CRANberries, there is also a diffstat report for this release More information is on the RcppRedis 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.

Just a litte update on the DUCK challenge: In the last week, the following packages were fixed and uploaded into unstable:

• Alastair McKinstry uploaded grip-api
• Tiago Bortoletto Vaz uploaded musescore
• Azat Khuzhin uploaded blktool
• J rg Frings-F r uploaded libmongo-client
• C dric Boutillieruploaded ruby-oauth
• Rapha l Hertzoguploaded ditaa
• Maximiliano Curia uploaded attica-f5, kdelibs4support and kactivities-kf5
• Jeremy Lain uploaded sailcut
• Axel Beckert uploaded libtext-markdown-perl
• Benjamin Drung uploaded esperanza
• Joao Eriberto Mota Filho uploaded pasco
• Heiko Stuebner uploaded libnl3

Last week we had 10 packages uploaded & fixed, the current week resulted in 15 fixed packages. So there are currently 25 packages fixed by 20 different uploaders. I really hope i can meet you all at DebConf15!! The list of the fixed and updated packages is availabe here. I will try to update this ~daily. If I missed one of your uploads, please drop me a line. A big "Thank You" to you. There is still lots of time till the end of DebConf15 and the end of the DUCK Challenge, so please get involved. And rememeber:

Well this has been an interesting project. It all started with a need to get better password storage at work. We wound up looking heavily at a GPG-based solution. This prompted the question: how can we make it even more secure? Well, perhaps, smartcards. The theory is this: a smartcard holds your private keys in a highly-secure piece of hardware. The PC can never actually access the private keys. Signing and decrypting operations are done directly on the card to prevent the need to export the private key material to the PC. There are lots of standards to choose from (PKCS#11, PKCS#15, and OpenPGP card specs) that are relevant here. And there are ways to use SSH and OpenVPN with some of these keys too. Access to the card is protected by a passphrase (called a PIN in smartcard lingo, even though it need not be numeric). These smartcards might be USB sticks, or cards you pop into a reader. In any case, you can pop them out when not needed, pop them in to use them, and well, pretty nice, eh? So that s the theory. Let s talk a bit of reality. First of all, it is hard for a person like me to evaluate how secure my data is in hardware. There was a high-profile bug in the OpenPGP JavaCard applet used by Yubico that caused the potential to use keys without a PIN, for instance. And how well protected is the key in the physical hardware? Granted, in most of these cards you re talking serious hardware skill to compromise them, but still, this is unknown in absolute terms. Here s the bigger problem: compatibility. There are all sorts of card readers, but compatibility with pcsc-tools and pcscd on Linux seems pretty good. But the cards themselves oh my. PKCS#11 defines an interface API, but each vendor would provide their own .so or .dll file to interface. Some cards (for instance, the ACOS5-64 mentioned on the Debian wiki!) are made by vendors that charge $50 for the privilege of getting the drivers needed to make them work and they re closed-source proprietary drivers at that. Some attempts I ordered several cards to evaluate: the OpenPGP card, specifically designed to support GPG; the ACOS5-64 card, the JavaCOS A22, the Yubikey Neo, and a simple reader listed on the GPG smartcard howto. The OpenPGP card and ACOS5-64 are the only ones in the list that support 4096-bit RSA keys due to the computational demands of them. The others all support 2048-bit RSA keys. The JavaCOS requires the user to install a JavaCard applet to the card to make it useable. The Yubico OpenPGP applet works here, along with GlobalPlatform to install it. I am not sure just how solid it is. The Yubikey Neo has yet to arrive; it integrates some interesting OAUTH and TOTP capabilities as well. I found that Debian s wiki page for smartcards lists a bunch of them that are not really useable using the tools in main. The ACOS5-64 was such a dud. But I got the JavaCOS A22 working quite nicely. It s also NFC-enabled and works perfectly with OpenKeyChain on Android (looking like a Yubikey Neo to it, once the OpenPGP applet is installed). I m impressed! Here s a way to be secure with my smartphone without revealing everything all the time. Really the large amount of time is put into figuring out how all this stuff fits together. I m getting there, but I ve got a ways to go yet. Update: Corrected to read signing and decrypting rather than signing and encrypting operations are being done on the card. Thanks to Beno t Allard for catching this error.

If you wonder why it was so silent here over the last weeks, there is a simple explanation: I am on scientific freak weeks As you might know, in my main profession I am logician, mathematician, computer scientist at the Japan Advanced Institute of Science and Technology (btw, searching urgently for a new job, in case someone is interested!!!). The last weeks have been very busy with attenting and presenting at LICS 2015 (Logic in Computer Science), followed by a workshop on Proofs as Processes organized by myself, then a presentation at CCA 2015 (Conference on Computability and Complexity in Analysis), and now working with visitors on our hyper natural deduction system. Above all that, there is also my lecture on Logical Decision Procedures at JAIST that a colleague and I a creating on the fly. All in all a very busy July, but I hope that after the weekend, and another workshop at JAIST, things settle down around beginning of August.

I'm still working on the Norwegian version of the Free Culture book by Lawrence Lessig, and is now working on the final typesetting and layout. One of the features I want to get the structure similar to the original book is to typeset the footnotes as endnotes in the notes chapter. Based on the feedback from the Debian maintainer and the dblatex developer, I came up with this recipe I would like to share with you. The proposal was to create a new LaTeX class file and add the LaTeX code there, but this is not always practical, when I want to be able to replace the class using a make file variable. So my proposal misuses the latex.begindocument XSL parameter value, to get a small fragment into the correct location in the generated LaTeX File. First, decide where in the DocBook document to place the endnotes, and add this text there:

<?latex \theendnotes ?>

Next, create a xsl stylesheet file dblatex-endnotes.xsl to add the code needed to add the endnote instructions in the preamble of the generated LaTeX document, with content like this:

<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version='1.0'>
  <xsl:param name="latex.begindocument">
    <xsl:text>
\usepackage endnotes 
\let\footnote=\endnote
\def\enoteheading \mbox \par\vskip-\baselineskip  
\begin document 
    </xsl:text>
  </xsl:param>
</xsl:stylesheet>

Finally, load this xsl file when running dblatex, for example like this:

dblatex --xsl-user=dblatex-endnotes.xsl freeculture.nb.xml

The end result can be seen on github, where my book project is located.

While updating the maintainer's guide, I had faced with several issues to update it as it is, since it was based on the dh-make package and does not play nice with new features such as multi-arch etc. Also. the lack of capability to create a decent copyright information template was my concern.

Mostly a mental note as I've reinvented this the second time now. If you just quickly want to share some org-mode notes with some non-Emacs-users the built-in HTML export comes handy. However it has one Problem: All source syntax highlighting is derived from your current theme. Which of course is a bad idea if your editor has a dark background (say Emacs.reverseVideo: on). The same if your terminal's background color is dark. Running Emacs in batch mode and still getting colorful code formatting seems to be an unsolved problem. All that can be found on the Internet suggests adding a dark background to your HTML export (at least to the code blocks). Or maybe use an external style-sheet. Both not exactly the thing if you just want to scp snippets of HTML somewhere to share. However there's a working hack:

#!/usr/bin/make -f
%.html: %.org
	xvfb-run urxvt +rv -e emacs -nw --visit $< --funcall org-html-export-to-html --kill >/dev/null

So use a terminal you can easily force into light-background-mode (like urxvt +rv) so the emacs -nw runs in light-background-mode and wrap the thing in xvfb-run so you can properly run this over ssh (and don't get annoying windows pop up and disappear again when typing make)

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

• Ben Hutchings did 14.75 hours.
• Guido G nther did 10 hours.
• Mike Gabriel did 8 hours.
• Rapha l Hertzog did 14.5 hours.
• Santiago Ruano Rinc n did 14.75 hours.
• Scott Kitterman did 4 hours.
• Thorsten Alteholz did 14.5 hours.

Evolution of the situation July has seen a nice increase in terms of sponsored hours (79.50 hours per month) but the trend is unlikely to continue for the next month, worse it might be negative. While most sponsors who joined us last year in July will renew their support, there are a few where I have no confirmation yet. Many thanks to those who confirmed early: Universit Lille 3, MyTux. Our first milestone of funding the equivalent of a half-time position is unlikely to be reached before DebConf or even this summer. If you want to prove me wrong, it s time to get in touch with your management and convince your company to contribute a small amount. In terms of security updates waiting to be handled, the situation is similar to last month: the dla-needed.txt file lists 24 packages awaiting an update (5 more than last month), the list of open vulnerabilities in Squeeze shows about 33 affected packages in total (3 less than last month). Thanks to our sponsors There are no new sponsors this month. But I decided to include the number of months that the sponsor has been with us. Since we value long-lasting relations, it seemed quite natural to add this.

• Gold sponsors:
• The Positive Internet (for 13 months already)
• Linode LLC
• Silver sponsors:
• David Ayers IntarS Austria (for 13 months already)
• Blablacar (for 12 months already)
• Domeneshop AS (for 12 months already)
• Universit Lille 3 (for 12 months already)
• Trollweb Solutions (for 10 months already)
• Gandi SAS (for 7 months already)
• University of Luxembourg (for 4 months already)
• Rentabiliweb Group
• Bronze sponsors:
• Offensive Security (for 13 months already)
• Seznam.cz, a.s. (for 13 months already)
• Evolix (for 12 months already)
• Freeside Internet Service (for 12 months already)
• MyTux (for 12 months already)
• Linuxhotel GmbH (for 10 months already)
• Nantes M tropole (for 10 months already)
• Intevation GmbH (for 9 months already)
• Daevel SARL (for 8 months already)
• FOSSter (for 8 months already)
• Bitfolk LTD (for 7 months already)
• Megaspace Internet Services GmbH (for 7 months already)
• Gree, Inc. (for 6 months already)
• Greenbone Networks GmbH (for 6 months already)
• NUMLOG (for 6 months already)
• WinGo AG (for 5 months already)
• Ecole Centrale de Nantes LHEEA

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

A new release of RcppEigen arrived on CRAN and in Debian yesterday. It synchronizes the Eigen code with the 3.2.5 upstream release. Once again, Yixuan Qiu did most of the heavy lifting in one very nice pull request, and I added some minor updates to keep R CMD check --as-cran happy. The NEWS file entry follows.

Changes in RcppEigen version 0.3.2.5.0 (2015-07-11)

• Updated to version 3.2.5 of Eigen
• Fixed some incorrect error messages stemming from Eigen code.
• Updated package to current R CMD check standards.

Courtesy of CRANberries, there is also a diffstat report for the most recent 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.

(In order to avoid any ambiguity here, this is a personal opinion. The Free Software Foundation's opinion on this matter is here)

Canonical have a legal policy surrounding reuse of Intellectual Property they own in Ubuntu, and you can find it here. It's recently been modified to handle concerns raised by various people including the Free Software Foundation[1], who have some further opinions on the matter here. The net outcome is that Canonical made it explicit that if the license a piece of software is under explicitly says you can do something, you can do that even if the Ubuntu IP policy would otherwise forbid it.

Unfortunately, "Canonical have made it explicit that they're not attempting to violate the GPL" is about the nicest thing you can say about this. The most troubling statement is Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks. Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries.. The apparent aim here is to avoid situations where people take Ubuntu, modify it and continue to pass it off as Ubuntu. But it reaches far further than that. Cases where this may apply include (but are not limited to):

• Anyone producing a device that runs an operating system based on Ubuntu, even if it's entirely invisible to the user (eg, an embedded ARM device using Ubuntu as its base OS)
• Anyone producing containers based on Ubuntu
• Anyone producing cloud images (such as AMIs) based on Ubuntu

In each of these cases, a strict reading of the policy indicates that you are distributing a modified version of Ubuntu and therefore must either get it approved by Canonical or remove the trademarks and rebuild everything. The strange thing is that this doesn't limit itself to rebuilding packages that include Canonical's trademarks - there's a requirement that you rebuild all binaries.

Now obviously this is good engineering practice in a whole bunch of ways, but it's a huge pain in the ass. And to make things worse, Canonical won't clarify what they consider to be use of their trademarks. Many Ubuntu packages rebuilt from Debian include the word "ubuntu" in their version string. Many Ubuntu packages will contain the word "ubuntu" in maintainer email addresses. Many Ubuntu packages include references to Ubuntu (for instance, documentation might say "This configuration file is located under /etc/default in Debian and Ubuntu"). And many Ubuntu packages will include the compiler version string, which will include the word "ubuntu". Realistically, there's no risk of confusion by using the trademarks in this way, and as a consequence there would be no infringement under trademark law. But Canonical aren't using trademark law here. Canonical assert that they hold copyright over binaries that they have built form source, and require that for you to have permission to redistribute these binaries under copyright law you must remove the trademarks. This means that it doesn't matter whether your use of the trademarks would be infringing or not - you're required to remove them, because fuck you that's why.

This is a huge overreach. It's hostile to free software, in that it makes it significantly more difficult to produce derivative works of Ubuntu and doesn't benefit the community in the process. It's hostile to our understanding of IP law, in that it claims that the mechanical process of turning source code into binaries creates an independently copyrightable work. And in some cases it may make it impossible to create derivative works that interoperate with Ubuntu due to applications making assumptions about the presence of strings.

It'd be easy write this off as an over the top misinterpretation of the policy if it hadn't been confirmed by the Ubuntu Community Manager that any binaries shipped by Ubuntu under licenses that don't grant an explicit right to redistribute the binaries can't be redistributed without permission or rebuilding. When I asked for clarification from Canonical over a year ago, I got no response[2]. Perhaps Canonical don't want to force you to remove every single use of the word Ubuntu from derivative works, but their policy is written such that the natural reading is that they do, and they've refused every single opportunity they've been given to clarify the point.

So, we're left with a policy that makes it hugely impractical to redistribute modified versions of Ubuntu unless Canonical approve of it. That's not freedom, and it's certainly not Ubuntu. If Canonical are serious about participating in the free software community then they need to demonstrate their willingness to continue improving this policy to bring it closer to our goals. Failure to do so will give a strong indication of their priorities.

[1] While I'm a member of the FSF's board of directors, I'm not involved in the majority of the FSF's day to day activities and was not part of this process
[2] Nebula's OS was a mixture of binary packages we pulled straight from Ubuntu and packages we rebuilt, so we were obviously pretty interested in what the answer was

comments

Categories:

• Debian-Blog
• Virtualization

Keywords:

• VirtualBox

Like:

Yesterday, Wammu 0.39 has been released. The list of changes is not really huge:

• Fixed connecting to phone with no SMSC set.
• Various code cleanups.
• Translation updates.

I will not make any promises for future releases (if there will be any) as the tool is not really in active development.

Filed under: English Gammu Wammu 0 comments

This was my second month as a Freexian sponsored LTS contributor. I was assigned 4 hours which was enough for me to update libclamunrar to the latest version we have, 0.98.5. This aligns libclamunrar with last month s clamav update and resolved a potentially concerning double free error. This is consistent with the way clamav and its components are updated for Debian supported releases through proposed-updates. This is covered under DLA 250-1. This update took longer than expected due to time spent wrestling with the git repository for the packaging, but that s resolved now, so if future updates are needed, it should be much easier.

I looked a bit more into the possible arguments to keep DHE alive once you support ECDHE and you only expect traffic from endusers with a real browser (machine2machine traffic with access from obscure libraries is a different matter). From the SSL Labs checks we can deduce the following components that support DHE but do not support ECDHE:

• Android 2.3.7
• Java 6

Windows XP does not support forward secrecy at all, and all other browsers beside IE (except for the first Chrome releases) bring their own TLS implementation. A very interesting data point is the cipher usage graphing provided by Wikimedia you can find on this dashboard. Currently I see roughly 4% of connections to be negotiated with some variant of a DHE cipher. That is after all not much, so I'm tempted to disable DHE for HTTPS where I've working ECDHE support soon. I'd first like to gather some stats from the BigIPs which I'm babysitting but that unfortunately is not that easy. As far as I can tell the only option is to insert a header a via an iRule and log the header on a backend system. Or you can setup HSL and log directly from the iRule.

In a comment to my previous post, Daniele asked the entirely reasonable question,

Would you like to comment on why you think that DNSSEC+DANE are not a possible and much better alternative?

Where DANE fails to be a feasible alternative to the current system is that it is not widely acknowledged to be superior in every possible way . A weak demonstration of this is that no browser has implemented DANE support, and very few other TLS-using applications have, either. The only thing I use which has DANE support that I m aware of is Postfix and SMTP is an application in which the limitations of DANE have far less impact. My understanding of the limitations of DANE, for large-scale deployment, are enumerated below.

DNS Is Awful Quoting Google security engineer Adam Langley:

But many (~4% in past tests) of users can t resolve a TXT record when they can resolve an A record for the same name. In practice, consumer DNS is hijacked by many devices that do a poor job of implementing DNS.

Consider that TXT records are far, far older than TLSA records. It seems likely that TLSA records would fail to be retrieved greater than 4% of the time. Extrapolate to the likely failure rate for lookup of TLSA records would be, and imagine what that would do to the reliability of DANE verification. It would either be completely unworkable, or else would cause a whole new round of just click through the security error training. Ugh. This also impacts DNSSEC itself. Lots of recursive resolvers don t validate DNSSEC, and some providers mangle DNS responses in some way, which breaks DNSSEC. Since OSes don t support DNSSEC validation by default (for example, by having the name resolution APIs indicate DNSSEC validation status), browsers would essentially have to ship their own validating resolver code. Some people have concerns around the single point of control for DNS records, too. While the weakest link nature of the CA model is terribad, there is a significant body of opinion that replacing it with a single, minimally-accountable organisation like ICANN isn t a great trade. Finally, performance is also a concern. Having to go out-of-band to retrieve TLSA records delays page generation, and nobody likes slow page loads.

DNSSEC Is Awful Lots of people don t like DNSSEC, for all sorts of reasons. While I don t think it is quite as bad as people make out (I ve deployed it for most zones I manage, there are some legitimate issues that mean browser vendors aren t willing to rely on DNSSEC. 1024 bit RSA keys are quite common throughout the DNSSEC system. Getting rid of 1024 bit keys in the PKI has been a long-running effort; doing the same for DNSSEC is likely to take quite a while. Yes, rapid rotation is possible, by splitting key-signing and zone-signing (a good design choice), but since it can t be enforced, it s entirely likely that long-lived 1024 bit keys for signing DNSSEC zones is the rule, rather than exception.

DNS Providers are Awful While we all poke fun at CAs who get compromised, consider how often someone s DNS control panel gets compromised. Now ponder the fact that, if DANE is supported, TLSA records can be manipulated in that DNS control panel. Those records would then automatically be DNSSEC signed by the DNS provider and served up to anyone who comes along. Ouch. In theory, of course, you should choose a suitably secure DNS provider, to prevent this problem. Given that there are regular hijackings of high-profile domains (which, presumably, the owners of those domains would also want to prevent), there is something in the DNS service provider market which prevents optimal consumer behaviour. Market for lemons, perchance?

Conclusion None of these problems are unsolvable, although none are trivial. I like DANE as a concept, and I d really, really like to see it succeed. However, the problems I ve listed above are all reasonable objections, made by people who have their hands in browser codebases, and so unless they re fixed, I don t see that anyone s going to be able to rely on DANE on the Internet for a long, long time to come.

The Debian Perl team had its first sprint in May and it was a success: 7 members met in Barcelona the weekend from May 22nd to May 24th to kick off the development around perl for Stretch and to work on QA tasks across the more than 3000 packages that the team maintains. Even though the participants enjoyed the beautiful weather and the food very much, a good amount of work was also done:

• 53 bugs were filed or worked on, 31 uploads were accepted.
• The current practice of patch management (quilt) was discussed and possible alternatives were shown (git-debcherry and git-dpm).
• Improvements were made in the Debian Perl Tools (dpt) and discussed how to get track of upstream git history and tags.
• Team's policies, documentation and recurring tasks were reviewed and updated.
• Perl 5.22 release was prepared and src:perl plans for Stretch were discussed.
• autopkgtest whitelists were reviewed, new packages added, and IRC notificacions by KGB were discussed.
• Outstanding migrations were reviewed.
• Reproducibility issues with POD_MAN_DATE were commented.

The full report was posted to the relevant Debian mailing lists. The participants would like to thank the Computer Architecture Department of the Universitat Polit cnica de Catalunya for hosting us, and all donors to the Debian project who helped to cover a large part of our expenses.

A new version of RcppGSL arrived on CRAN a couple of days ago. This package provides an interface from R to the GNU GSL using our Rcpp package. In the course of preparation for the higher-performance R via C++ course I gave in Zuerich last month, I overhauled this package, its embedded package (!!) showing how to build a package which uses R, C++ and the GSL (and which can serve as a fine example of how to build and R and C++ package using an external library), and also overhauled the vignette which discusses all these aspect. All examples now consistently use Rcpp Attributes. The NEWS file entries follows below:

Changes in version 0.2.5 (2015-07-05)

• The colnorm function in the included example package was rewritten to use Rcpp Attributes, the example package was updated and its version number increased to 0.0.3.
• The unit tests also use the updated version of the example package.
• The package, and the included example package, were updated throughout to conform to the current R CMD check standards.
• The RcppGSL-intro vignette was updated throughout.
• The Travis CI integration now uses r-cran-* packages which leads to faster tests.

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.