If you're running Spamassassin on Debian or Ubuntu, have you enabled automatic rule updates? If not, why not? If possible, you should enable this feature. It should be as simple as setting "CRON=1" in /etc/default/spamassassin. If you choose not to enable this feature, I'd really like to hear why. In particular, I'm thinking about changing the default behavior of the Spamassassin packages such that automatic rule updates are enabled, and I'd like to know if (and why) anybody opposes this. Spamassassin hasn't been providing rules as part of the upstream package for some time. In Debian, we include a snapshot of the ruleset from an essentially arbitrary point in time in our packages. We do this so Spamassassin will work "out of the box" on Debian systems. People who install spamassassin from source must download rules using spamassassin's updates channel. The typical way to use this service is to use cron or something similar to periodically check for rule changes via this service. This allows the anti-spam community to quickly adapt to changes in spammer tactics, and for you to actually benefit from their work by taking advantage of their newer, presumably more accurate, rules. It also allows for quick reaction to issues such as the one described in bug 738872 and 774768. If we do change the default, there are a couple of possible approaches we could take. The simplest would be to simply change the default value of the CRON variable in /etc/default/spamassassin. Perhaps a cleaner approach would be to provide a "spamassassin-autoupdates" package that would simply provide the cron job and a simple wrapper program to perform the updates. The Spamassassin package would then specify a Recommends relationship with this package, thus providing the default enabled behavior while still providing a clear and simple mechanism to disable it.

Last week, I visited London for the January Docker meetup, which was the first time I'd attended this group. It was a talk-oriented format, with around 200 attendees packed into Shoreditch Village Hall; free pizza and beer was provided thanks to the sponsors, which was awesome (and makes logistics easier when you're travelling there from work). There were three talks. First, Andrew Martin from British Gas spoke about how they use Docker for testing and continuous deployment of their Node.js microservices - buzzword bingo! But it's helpful to see how companies approach these things. Second, Johan Euphrosine from Google gave a short demo of Google Cloud Platform for running Docker containers (mostly around Container Engine, but also briefly App Engine). This was relevant to my interests, but I'd already seen this sort of talk online. Third, Dan Williams presented his holiday photos featuring a journey on a container ship, which wins points from me for liberal interpretation of the meetup topic, and was genuinely very entertaining/interesting - I just regret having to leave to catch a train halfway through. In summary, this was worth attending, but as someone just getting started with containers I'd love some sort of smaller meetings with opportunities for interaction/activity. There's such a variety of people/use cases for Docker that I'm not sure how much everyone had in common with each other; it would be interesting to find out.

Categories:

• Debian-Blog
• Tools

Keywords:

• apport

Categories:

• Debian-Blog
• Tools

Keywords:

• apt-offline

The Replicant project released version 4.2 0003 recently. I have been using Replicant on a Samsung SIII (I9300) for around 14 months now. Since I have blogged about issues with NFC and Wifi earlier, I wanted to give a status update after upgrading to 0003. I m happy to report that my NFC issue has been resolved in 0003 (the way I suggested; reverting the patch). My issues with Wifi has been improved in 0003, with my merge request being accepted. What follows below is a standalone explanation of what works and what doesn t, as a superset of similar things discussed in my earlier blog posts. What works out of the box: Audio, Telephony, SMS, Data (GSM/3G), Back Camera, NFC. 2D Graphics is somewhat slow compared to stock ROM, but I m using it daily and can live with that so it isn t too onerus. Stability is fine, similar to other Android device I m used to. Video playback does not work (due to non-free media decoders?), which is not a serious problem for me but still likely the biggest outstanding issue except for freedom concerns. 3D graphics apparently doesn t work, and I believe it is what prevents Firefox from working properly (it crashes). I m having one annoying but strange problem with telephony: when calling one person I get scrambled audio around 75% of the time. I can still hear what the other person is saying, but can barely make anything out of it. This only happens over 3G, so my workaround when calling that person is to switch to 2G before and switch back after. I talk with plenty other people, and have never had this problem with anyone else, and it has never happened when she talks with anyone else but me. If anyone has suggestion on how to debug this, I m all ears. Important apps to get through daily life for me includes K9Mail (email), DAVDroid (for ownCloud CalDav/CardDAV), CalDav Sync Adapter (for Google Calendars), Conversations (XMPP/Jabber chat), FDroid (for apps), ownCloud (auto-uploading my photos), SMS Backup+, Xabber (different XMPP/Jabber accounts), Yubico Authenticator, MuPDF and oandbackup. A couple of other apps I find useful are AdAway (remove web ads), AndStatus, Calendar Widget, NewsBlur and ownCloud News Reader (RSS readers), Tinfoil for Facebook, Twidere (I find its UI somewhat nicer than AndStatus s), and c:geo. A number of things requires non-free components. As I discussed in my initial writeup from when I started using Replicant I don t like this, but I m accepting it temporarily. The list of issues that can be fixed by adding non-free components include the front camera, Bluetooth, GPS, and Wifi. After flashing the Replicant ROM image that I built (using the fine build instructions), I m using the following script to add the missing non-free files from Cyanogenmod.

# Download Cyanogenmod 10.1.3 (Android 4.2-based) binaries:
# wget http://download.cyanogenmod.org/get/jenkins/42508/cm-10.1.3-i9300.zip
# echo "073a464a9f5129c490502c77374495c38a25ba790c10e27f51b43845baeba6bf  cm-10.1.3-i9300.zip"   sha256sum -c 
# unzip cm-10.1.3-i9300.zip
adb root
adb remount
adb shell mkdir /system/vendor/firmware
adb shell chmod 755 /system/vendor/firmware
# Front Camera
adb push cm-10.1.3-i9300/system/vendor/firmware/fimc_is_fw.bin /system/vendor/firmware/fimc_is_fw.bin
adb push cm-10.1.3-i9300/system/vendor/firmware/setfile.bin /system/vendor/firmware/setfile.bin
adb shell chmod 644 /system/vendor/firmware/fimc_is_fw.bin /system/vendor/firmware/setfile.bin
# Bluetooth
adb push cm-10.1.3-i9300/system/bin/bcm4334.hcd /system/vendor/firmware/
adb shell chmod 644 /system/vendor/firmware/bcm4334*.hcd
# GPS
adb push cm-10.1.3-i9300/system/bin/gpsd /system/bin/gpsd
adb shell chmod 755 /system/bin/gpsd
adb push cm-10.1.3-i9300/system/lib/hw/gps.exynos4.so /system/lib/hw/gps.exynos4.so
adb push cm-10.1.3-i9300/system/lib/libsecril-client.so /system/lib/libsecril-client.so
adb shell chmod 644 /system/lib/hw/gps.exynos4.so /system/lib/libsecril-client.so
# Wifi
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_apsta.bin_b1 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_apsta.bin_b2 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_mfg.bin_b0 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_mfg.bin_b1 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_mfg.bin_b2 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_p2p.bin_b0 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_p2p.bin_b1 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_p2p.bin_b2 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_sta.bin_b0 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_sta.bin_b1 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_sta.bin_b2 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_mfg.txt /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_mfg.txt_murata /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_mfg.txt_murata_b2 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_mfg.txt_semcosh /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_net.txt /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_net.txt_murata /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_net.txt_murata_b2 /system/vendor/firmware/
adb push cm-10.1.3-i9300/system/etc/wifi/nvram_net.txt_semcosh /system/vendor/firmware/

I hope this helps others switch to a better phone environment!

I moved back from the California Bay Area to Belfast a while back and for various reasons it looks like I m going to be here a while, so it made sense to have my belongings shipped over here. They haven t quite arrived yet, and I ll do another post about that process once they have, but I ve been doing various tweets prefixed with [shipping] during the process. Various people I ve spoken to (some who should know me better) thought this was happening manually. It wasn t. If you care about how it was done, read on. I d been given details of the ship carrying my container, and searching for that turned up the excellent MarineTraffic which let me see the current location of the ship. Turns out ships broadcast their location using AIS and anyone with a receiver can see the info. Very cool, and I spent some time having a look at various bits of shipping around the UK out of interest. I also found the ship s itinerary which give me some idea of where it would be calling and when. Step one was to start recording this data; it was time sensitive and I wanted to be able to see historical data. I took the easy route and set up a cron job to poll the location and itinerary on an hourly basis, and store the results. That meant I had the data over time, if my parsing turned out to miss something I could easily correct it, and that I wasn t hammering Marine Traffic while writing the parsing code. Next I wanted to parse the results, store them in a more manageable format than the HTML, and alert me when the ship docked somewhere or set off again. I ve been trying to learn more Python rather than doing my default action of turning to Perl for these things, and this seemed like a simple enough project to try out. Beautiful Soup seemed to turn up top for HTML parsing in Python, so that formed the basis. Throwing the info into a database so I could do queries felt like the right move so I used SQLite - if this had been more than a one off I d have considered looking at PostgreSQL and its GIS support. Finally Tweepy made it very easy to tweet from Python in about 4 lines of code. The whole thing weighed in at only 175 lines of code, mostly around pulling the info out of the HTML and then a little to deal with checking for state changes against the current status and the last piece of info in the database. The pieces of information I chose to store were the time of the update (i.e. when the ship sent it, not when my script ran), reported area, reported state, the position + course, reported origin, reported destination and eta. The fact this is all in a database makes it very easy to do a few queries on the data. How fast did the ship go?

sqlite> SELECT MAX(speed) FROM status;
MAX(speed)
21.9

What areas did it report?

sqlite> SELECT area FROM status GROUP BY area;
area
-
Atlantic North
California
Caribbean Sea
Celtic Sea
English Channel
Hudson River
Pacific North
Panama Canal

What statuses did we see?

sqlite> SELECT status FROM status GROUP BY status;
status
At Anchor
Moored
Stopped
Underway
Underway using Engine

Finally having hourly data lets me draw a map of where the ship went. The data isn t complete, because the free AIS info depends on the ship being close enough to a receiving station. That means there were a few days in the North Atlantic without updates, for example. However there s enough to give a good idea of just how well traveled my belongings are, and it gave me an excuse to play with OpenLayers. (Apologies if the zoom buttons aren t working for you here; I think I need to kick the CSS in some manner I haven t quite figured out yet.)

1. Big data will continue to fail to deliver for most companies.
   This has several reasons, including in particular: 1: lack of data to analyze that actually benefits from big data tools and approaches (and which is not better analyzed with traditional tools). 2: lack of talent, and failure to attract analytics talent. 3: stuck in old IT, and too inflexible to allow using modern tools (if you want to use big data, you will need a flexible "in-house development" type of IT that can install tools, try them, abandon them, without going up and down the management chains) 4: too much marketing. As long as big data is being run by the marketing department, not by developers, it will fail.
2. Project consolidation: we have seen hundreds of big data software projects the last years. Plenty of them on Apache, too. But the current state is a mess, there is massive redundancy, and lots and lots of projects are more-or-less abandoned. Cloudera ML, for example, is dead: superseded by Oryx and Oryx 2. More projects will be abandoned, because we have way too many (including much too many NoSQL databases, that fail to outperform SQL solutions like PostgreSQL). As is, we have dozens of competing NoSQL databases, dozens of competing ML tools, dozens of everything.
3. Hype: the hype will continue, but eventually (when there is too much negative press on the term "big data" due to failed projects and inflated expectations) move on to other terms. The same is also happening to "data science", so I guess the next will be "big analytics", "big intelligence" or something like that.
4. Less openness: we have seen lots of open-source projects. However, many decided to go with Apache-style licensing - always ready to close down their sharing, and no longer share their development. In 2015, we'll see this happen more often, as companies try to make money off their reputation. At some point, copyleft licenses like GPL may return to popularity due to this.

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.

A few days ago, the Free Software Foundation announced a new video explaining Free software in simple terms. The video named User Liberation is 3 minutes long, and I recommend showing it to everyone you know as a way to explain what Free Software is all about. Unfortunately several of the people I know do not understand English and Spanish, so it did not make sense to show it to them. But today I was told that English subtitles were available and set out to provide Norwegian Bokm l subtitles based on these. The result has been sent to FSF and made available in a git repository provided by Github. Please let me know if you find errors or have improvements to the subtitles.

Categories:

• Debian-Blog

Keywords:

• firmware
• battery

A few months ago I gave a lecture about systemd for the Linux Users of Victoria. Here are some of my notes reformatted as a blog post: Scripts in /etc/init.d can still be used, they work the same way as they do under sysvinit for the user. You type the same commands to start and stop daemons. To get a result similar to changing runlevel use the systemctl isolate command. Runlevels were never really supported in Debian (unlike Red Hat where they were used for starting and stopping the X server) so for Debian users there s no change here. The command systemctl with no params shows a list of loaded services and highlights failed units. The command journalctl -u UNIT-PATTERN shows journal entries for the unit(s) in question. The pattern uses wildcards not regexs. The systemd journal includes the stdout and stderr of all daemons. This solves the problem of daemons that don t log all errors to syslog and leave the sysadmin wondering why they don t work. The command systemctl status UNIT gives the status and last log entries for the unit in question. A program can use ioctl(fd, TIOCSTI, ) to push characters into a tty buffer. If the sysadmin runs an untrusted program with the same controlling tty then it can cause the sysadmin shell to run hostile commands. The system call setsid() to create a new terminal session is one solution but managing which daemons can be started with it is difficult. The way that systemd manages start/stop of all daemons solves this. I am glad to be rid of the run_init program we used to use on SE Linux systems to deal with this. Systemd has a mechanism to ask for passwords for SSL keys and encrypted filesystems etc. There have been problems with that in the past but I think they are all fixed now. While there is some difficulty during development the end result of having one consistent way of managing this will be better than having multiple daemons doing it in different ways. The commands systemctl enable and systemctl disable enable/disable daemon start at boot which is easier than the SysVinit alternative of update-rc.d in Debian. Systemd has built in seat management, which is not more complex than consolekit which it replaces. Consolekit was installed automatically without controversy so I don t think there should be controversy about systemd replacing consolekit. Systemd improves performance by parallel start and autofs style fsck. The command systemd-cgtop shows resource use for cgroups it creates. The command systemd-analyze blame shows what delayed the boot process and
systemd-analyze critical-chain shows the critical path in boot delays. Sysremd also has security features such as service private /tmp and restricting service access to directory trees. Conclusion For basic use things just work, you don t need to learn anything new to use systemd. It provides significant benefits for boot speed and potentially security. It doesn t seem more complex than other alternative solutions to the same problems. https://wiki.debian.org/systemd http://freedesktop.org/wiki/Software/systemd/Optimizations/ http://0pointer.de/blog/projects/security.html

Over Christmas I found the above puzzle at my parent's house. I don't know if it has a name but it seemed apt to name it after The Giant's Causeway. The idea is that you swap and/or rotate the outer tiles until the colours at the edges match. The center tile is fixed, or at least I assume it is as the wooden edges are deliberately less rounded. Of course, solving it manually would be boring so here's a dumb brute force solution. I actually admire how inefficient and stupid it is... This prints (after 5 minutes!): UPDATE: Seems like this puzzle is called "Circus Seven". Now to dust off my Prolog...

A brand new and shiny version of rfoaas is now on CRAN. The rfoaas package provides an interface for R to the most excellent FOAAS service--which provides a modern, scalable and RESTful web service for the frequent need to tell someone to f$#@ off. There are two (internal) changes of merit in this version. First off, as FOAAS was refactored upstream, we are now forced to supply an accept: text/plain http request header. Which, sadly enough, is not something the url() function in R can do---so we brought in more cavalry and now depend on the httr package by Hadley, and use its GET() method. A second change is that we added a (simple but effective enough) regression test which simply calls all foaas entry points available throug rfoaas, and compares this to the anticipated result. To run it, you need to set an environment variable RunFOAASTests=yes as eg out Travis script does. Finally, we aligned the version number with upstream to signal that we cover all available entry points of that version. As usual, CRANberries provides a diff to the previous release. Questions, comments etc should go to the GitHub issue tracker.

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

There was a regression in Linux 3.2.65, which unfortunately was included in this weekend's Debian stable point release (7.8) as I didn't point out the bug reports to the stable release team. At least some systems are now failing to resume after suspending to RAM; instead they reboot. I have tracked down the change that caused this, and it should be fixed as part of a security update soon. The change is in code specific to 64-bit x86 (i.e. the Debian amd64 architecture). If you need suspend/resume to work, you might wish to avoid upgrading the linux-image-3.2.0-4-amd64 package until that future update. Update: I have uploaded packages with the problematic changes reverted to people.debian.org. The version number is 3.2.65-1+deb7u1~test (lower than the next security update will be). Mail 774436@bugs.debian.org if this doesn't work for you.

I was browsing Eric Kim s street photography blog, when I stumbled across one article about the well-known Gear Acquisition Syndrome that plagues enthusiast photographers. Gear Acquisition Syndrome is the obsession that enthusiasts tend to have for new gear, new gadgets, new stuff, as an excuse for not developing their skills or taking action. You can recognize it by phrases like: If only I had that new gear, I would be better at what I do I can t do that project until I buy this gear My super expensive camera is not good for that, I need an even more expensive one (etc). The article, How to Be Grateful For What You Have is a funny and well argued look on why photographers, or artists in general, can get lost in what they don t have, instead of what they have. The article is a recommended read in itself and delivers the point whether you are into photography or not. That said, inside the article I found three nice links worth noting: The Tiny Collective
A group of photographers that use only their phones as their camera. It s inspiring to see a specific, curated, selection of images made with phones. It definitely makes you wonder why would you need anything but a phone to make great images (answer: phones work great, even old ones). A Guide to Practical Contentment
One of the most simple and effective messages about contentment that I have read. It s not about not wanting things or settling for whatever . It s all about taking a step back and realizing that life is not about absolutes. If you are not a billionaire, that doesn t mean you have failed in life. Perhaps you are just a millionaire, and that s fine :).

( ) if you start in this place of fixing what s wrong with you, you keep looking for what else is wrong with you, what else you need to improve. So maybe now feel like you don t have enough muscles, or six pack abs, or you think your calves don t look good, or if it s not about your body, you ll find something else. So it s this never-ending cycle for your entire life. You never reach it. If you start with a place of wanting to improve yourself and feeling stuck, even if you re constantly successful and improving, you re always looking for happiness from external sources. You don t find the happiness from within, so you look to other things. If you re externally looking for happiness, it s easy to get too into food, or shopping, or partying, or overwork, to try to be happy. If instead, you can find contentment within and not need external sources of happiness, then you ll have a reliable source of happiness.

So, instead of looking at sources of external happiness, why don t you look into sources of internal happiness? It s one of the hardest things to learn how to do, but I m personally slowly getting there. It s life changing. Bonus points: quotes on simplification and minimalism
For extra credit, here are some interesting quotes on the above topics, note that as every internet quote page it might be filled with false quotes. I happen to like the one attributed to Donald Horban, who apparently doesn t exist outside quote pages in the internet. Maybe that s the biggest minimalism? Not existing?

We don t need to increase our goods nearly as much as we need to scale down our wants. Not wanting something is as good as possessing it.

Anyway, take these with a grain of salt, and just read them as interesting phrases. Just take it easy :).

First weekend back home after being away for the holidays. That was a lot of fun, but it's also nice to be back home with all my stuff and my normal schedule. Apparently nice enough that today I went on a productivity binge and did lots of random chores that had been building up. Quite satisfying. This is a catch-up haul post for a few random things that popped up over the past few months apart from a full book order. Ibraheem Abbas and Yasser Bahjatt HWJN (sff)
Ibraheem Abbas and Yasser Bahjatt Somewhere! (Hunaak!) (sff)
Shannon Appelcline Designers & Dragons: The '70s (non-fiction)
Shannon Appelcline Designers & Dragons: The '80s (non-fiction)
Shannon Appelcline Designers & Dragons: The '90s (non-fiction)
Shannon Appelcline Designers & Dragons: The '00s (non-fiction)
Tor.com Some of the Best from Tor.com: 2014 (sff anthology) The Appelcline four-volume history of RPGs was a gift from a friend, and a lovely set of books. The first two were available for free on the Kindle (as was the last) as part of an effort to publicize Arab SF, and I always like to broaden my cultural reading horizons.

Time for another update on my work for UEFI improvements in Jessie! I've spent more time on the integration of 32-bit grub-efi with a 64-bit Debian system, and just published a new test image on pettersson. I've added:

• a patch to the Linux kernel to add a new /sys file which exposes the size of the underlying UEFI platform (32- or 64-bit).
• a patch to grub2 to read that new /sys file in grub-install to determine the right version of grub-efi to install by default
• a patch to grub-installer to do similar

These remove the manual steps that were necessary for a 64-bit installation with the previous build. I've just used this exact image (and a network mirror) to install a fully-functional 64-bit Gnome system on the X205TA, simply by selecting "64-bit install" from the GRUB menu and following prompts. Yay! Visit http://cdimage.debian.org/cdimage/unofficial/efi-development/jessie-upload3/ to download and test the image. Now, there's no guarantee that the kernel patch I've submitted to the linux-efi folks will be accepted in its current form, and even if it is I'll have to get it and the other code I've written accepted into the various packages and then into Jessie! But for now this image should work just fine for Bay Trail folks I hope! WARNING: this CD is provided for testing only. Use at your own risk! If you have appropriate (U)EFI hardware, please try this image and let me know how you get on, via the debian-cd and debian-boot mailing lists. For now, I'm going to pause development here. The core code I'm using to make these images is all in the debian-cd and d-i repos, and I'll push the other patches once I know they'll work with the kernel. But I've got a slew of other things that I need to work on in the next few weeks, in no particular order:

• RC bugs filed against abcde
• Sorting out Mac-only 32-bit netinst images (only EFI boot? without EFI?)
• Regular openstack image generation for Jessie
• Regular debian-live image generation for Jessie
• ...

I'm currently not planning to make all of Debian's amd64 images bootable using 32-bit UEFI like this image - I'm happy to leave this as just an option for our multi-arch i386/amd64 images (netinst or DVD only). I think that's a reasonable compromise here, and it's also the easiest thing for me to do with the current debian-cd build system. Finally, apologies if you've asked me questions about the earlier images in this series and I've not responded yet. Fixing that ASAP!

A maintenance release of RcppClassic, now at version 0.9.6, went out to CRAN today. This package provides a maintained version of the otherwise deprecated first Rcpp API; no new projects should use it. No changes were in user-facing code. The Makevars file was change to accomodate a request by the CRAN Maintainer to keep it free of GNU Make extensions. At the same time, we overhauled the look and feel of the (very short) vignette. Build instructions were updated both in the vignette and in the included example package. Other accumulated changes since the last release were updates to the DESCRIPTION and NAMESPACE file as well two namespace-related R code updates. Courtesy of CRANberries, there is the set of changes relative to the previous release. 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.