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

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

Changes in Rcpp API:

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

Changes in Rcpp Attributes:

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

Changes in Rcpp tests:

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

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

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

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

I do not believe any of the current reporting around the announced case has accurately described the issue; which I see as a much more subtle question of GPL use across API layers. Of course I don't know what the real issue is, because the case is sealed and I have no inside knowledge. I do have some knowledge of the vmkernel, however, and what I read does not match with what I know. An overview of ESXi is shown below There is no question that ESXi uses a lot of Linux kernel code and drivers. The question as I see it is more around the interface. The vmkernel provides a well-described API known as vmkapi. You can write drivers directly to this API; indeed some do. You can download a SDK. A lot of Linux code has been extracted into vmkLinux; this is a shim between Linux drivers and the vmkapi interface. The intent here is to provide an environment where almost unmodified Linux drivers can interface to the proprietary vmkernel. This means vendors don't have to write two drivers, they can re-use their Linux ones. Of course, large parts of various Linux sub-systems' API are embedded in here. But the intent is that this code is modified to communicate to the vmkernel via the exposed vmkapi layer. It is conceivable that you could write a vmkWindows or vmkOpenBSD and essentially provide a shim-wrapper for drivers from other operating systems too. vmkLinux and all the drivers are GPL, and released as such. I do not think there could be any argument there. But they interface to vmkapi which, as stated, is an available API but part of the proprietary kernel. So, as I see it, this is a much more subtle question than "did VMware copy-paste a bunch of Linux code into their kernel". It goes to where the GPL crosses API boundaries and what is considered a derived work. If nothing else, this enforcement increasing clarity around that point would be good for everyone I think.

The short answer is: using AppArmor in Debian is fairly straight forward. Installing and activating it though is not yet a very user friendly experience. One needs to install the apparmor package, then activate it in the kernel by editing a line in the GRUB bootloader and then reboot. The procedure is explained in detail here.
We are working on fixing Debian Bug #702030 which aims at making the installation process easier for normal users by activating the module automatically as soon as one installs the apparmor package. Once you have set this up though, you re good to go. Profiles for confining processes and programs should then be activated automatically. One can verify this through the sudo aa-status command which should output something like this:

apparmor module is loaded.
30 profiles are loaded.
30 profiles are in enforce mode.
 /usr/bin/evince
 /usr/bin/evince-previewer
 /usr/bin/evince-previewer//sanitized_helper
 /usr/bin/evince-thumbnailer
 /usr/bin/evince-thumbnailer//sanitized_helper
 /usr/bin/evince//sanitized_helper
 /usr/bin/irssi
 /usr/bin/pidgin
 /usr/bin/pidgin//launchpad_integration
 /usr/bin/pidgin//sanitized_helper
 /usr/bin/tlsdate
 /usr/bin/tlsdate-helper
 /usr/bin/torbrowser-launcher
 /usr/bin/totem
 /usr/bin/totem-audio-preview
 /usr/bin/totem-video-thumbnailer
 /usr/lib/cups/backend/cups-pdf
 /usr/lib/libvirt/virt-aa-helper
 /usr/sbin/apt-cacher-ng
 /usr/sbin/cups-browsed
 /usr/sbin/cupsd
 /usr/sbin/cupsd//third_party
 /usr/sbin/libvirtd
 /usr/sbin/ntpd
 /usr/sbin/tcpdump
 /usr/sbin/tlsdated
 gst_plugin_scanner
 system_tor
0 profiles are in complain mode.
8 processes have profiles defined.
8 processes are in enforce mode.
 /usr/bin/pidgin
 /usr/bin/torbrowser-launcher
 /usr/sbin/cups-browsed 
 /usr/sbin/cupsd
 /usr/sbin/libvirtd
 system_tor
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

As of today there are only a dozen packages which ship their own profile in Debian: bind9, clamav, cups-browsed & cups-daemon, libvirt-daemon-system, mysql-5.5, lightdm, obfsproxy, sssd, tlsdate, tor, torbrowser-launcher, vidalia. In order to confine other applications, like evince, irssi, ntpd, pidgin, totem or tcpdump, one can install the apparmor-profiles-extra package. All those profiles work very well in a Debian Wheezy environment or higher, from my own experience. (Only the torbrowser-launcher profile needs to be fixed in wheezy-backports, but works well in Jessie or higher I m working on it.) If you want to confine other applications and found a profile which you want to use on your system, you can copy that profile into /etc/apparmor.d/ and then run

aa-enforce /etc/apparmor.d/myprofile

And that s pretty much it!

After seeing what the Wildfly (formerly JBoss AS) and Liferay combo does to /tmp, and somewhat attempting to fix it, I saw JVM_TMP in the Debian tomcat7 init script and thought, oh no, not another one. Is that even safe, what they do here, or is that a possibility to instantly pwn? The net is full of literature for how to obtain temporary files and directories, but there is nothing about how to reliably obtain paths under /tmp or, more generally, directories not just writable for one single user (think the g+w thing that got FusionForge CVE-2013-1423). The scenario here is: I am root, and I want to start something as another user, and pass it a stable path, such as /tmp/liferay. So I can just mkdir /tmp/liferay die; chown thatuser /tmp/liferay and, in the stop process, rm -rf /tmp/liferay, right? (Of course not. Also, bad example, as the liferay thing can also be started as thatuser, and our devs regularily need to do that, the init script is there just for the admin convenience and reboot-safety. But I still am interested if there is a secure way to achieve this.) The tomcat7 scenario is trivial : on That Other Init System , it would just get its private /tmp declared in the .service file, and good is, no more hassle. That s one I have to give you. (No idea if this is actually shipped in jessie. Our production systems run wheezy anyway, so there is not even the slightest bit of temptation. Plus, it would not solve the liferay issue, see above. Still, a point for going into the right direction.) The idea here is the same. It creates a directory on start and tears it down on stop. If there was nothing to do on start, the init script could just use mktemp -d. Heck, maybe it still should, but it would need to note down, and communicate to the stop instance, the actual name used. What a drag This is something I see popping up from time to time. I want to use stable paths for SSH session multiplexing control sockets in my ssh_config(5) file, but have them on tmpfs (Linux) or mfs (BSD) so they get properly removed on reboot. No Unix traditionally has per-user temporary directories that are clean and created after reboot. (Adjusting the paths is trivial once you have them.) Android has it worse, what with not having a world-writable tmp directory, which the shell needs e.g. for here documents; there are two components here, to have a directory the current user can write to, and to know its location. Some fail at the first, some at the second, some at both, and the classic /tmp is not the cure, as we have seen. (But if you ever see mksh erroring out due to lack of write permissions somewhere (including /sqlite_stmt_journals which used to be it) as non-root on Android, or even as root, set TMPDIR to something writable; it s tracked, so the change gets active immediately.)

I am reminded by Gunnar's wonderful news that I have been very remiss in publishing my own. Mathilda Sophie Hands, our second daughter, was delivered on the 9th of January. Her arrival was a little more interesting than we'd have preferred (with Gunde being suddenly diagnosed with HELLP Syndrome), but all has turned out well, with Gunde bouncing back to health surprisingly quickly, and Mathilda going from very skinny to positively chubby in a few short weeks, so no harm done. Today Mathilda produced her first on-camera smile. It's lovely when they start smiling. It seems to signal that there's a proper little person beginning to take shape.

After meeting Niels M ller at FOSDEM and learning about his Ed25519 implementation in GNU Nettle, I started working on a simple-to-implement description of Ed25519. The goal is to help implementers of various IETF (and non-IETF) protocols add support for Ed25519. As many are aware, OpenSSH and GnuPG has support for Ed25519 in recent versions, and OpenBSD since the v5.5 May 2014 release are signed with Ed25519. The paper describing EdDSA and Ed25519 is not aimed towards implementers, and does not include test vectors. I felt there were room for improvement to get wider and more accepted adoption. Our work is published in the IETF as draft-josefsson-eddsa-ed25519 and we are soliciting feedback from implementers and others. Please help us iron out the mistakes in the document, and point out what is missing. For example, what could be done to help implementers avoid side-channel leakage? I don t think the draft is the place for optimized and side-channel free implementations, and it is also not the place for a comprehensive tutorial on side-channel free programming. But maybe there is a middle ground where we can say something more than what we can do today. Ideas welcome!

After starting with Joey Hess, we continue with Paul Wise. What makes his star to shine are many things such as being a DSA (Debian System Administrator), a helpful hand on mailings list, encouraging people to join Debian teams but most of all - he has encyclopedia knowledge on Debian as a whole which he gladly shares with anyone who asks (very fast response on IRC channels). It is almost impossible for any single person to count all Debian teams, work and places - to know most of those things, you can image the vast knowledge which Paul has. The legend says that his brain has better and faster search engine algorithm on Debian related queries than all other engines combined. So lets see what he has to share with world. me: Who are you? pabs: Paul Wise (pabs) and I have to say that I'm no-where near as knowledgeable as your intro suggests. me: How did you start programming? pabs: Messing around with fractals and graphics things in MS BASIC. me: How would you now advise others to start programming? pabs: Pick an issue in a tool you use, investigate how the tool works and how you can change it, fix that and contribute the change back to the project that created that tool. In the process you will learn skills, interact with the community and contribute to the project. me: Setup of your development machine? pabs: Lenovo Thinkpad with external monitor, Debian testing and some tweaks me What is your preferable language (for hacking)? Why? How do you compare it to other languages? pabs: I currently prefer Python for its readability. It still has some rough edges though the documentation covers them fairly well. I generally pick up new languages when working on projects written in them. Haskell is next on the horizon due to Nikki and the Robots. me: Describe your current most memorable situation as software developer/hacker? pabs: I had a great time creating fractals in BASIC, learning about the Mandelbrot set, L-systems and more. My days and nights of hacking on frhed (a GPLed hex editor for Windows) to help me cheat at Civilisation were pretty memorable. frhed led to my work on reverse engineering the CHM file format (a documentation format for Windows programs). A stand-out moment during my time with Debian was hacking on the derivates census patch generation code during the Debian UK BBQ weekend, surrounded by geeks playing Portal, cooking things, hacking on Debian and generally having a good time (thanks Steve!). me: Some memorable moments from Debian conferences? pabs: There are so many; meeting Debian folks, playing Mao once and then never again, late night games of werewolf, both delectably delicious and hideously disgusting cheeses, fried insects, day trips to beautiful landscapes, inspiring keynotes, exciting BoFs, secret IRC channels for planning surprise birthday parties, blue hair, wet air, blocks of fried cheese, a vast quantity of icecream, pants, geeks in the surf, volcanoes, hiking, a wonderful view, a uni-cycling stormtrooper & more. me: How do you see future of Debian development? pabs: I hope we will continue to exist and uphold our principles for the foreseeable future. I don't have any crystal balls though. me: You recently became member of Debian DSA - what is that like, what roles do you have and what tasks are in front of DSA? pabs: We wrote a bit of text about that for DPN recently. me: You have large knowledge on Debian and you share it with anyone who wants to know more. What motivates you to do so? pabs: I want the operating system I personally rely on to exist into the future, helping folks work on and join Debian can help with that. me: Why should developers and users join Debian community? What makes Debian a great and happy place? pabs: Every Debian contributor has different reasons for joining the community. Personally the Social Contract, the DFSG and the spirit and culture behind them are the main reason to be involved. I also like our many efforts towards technical excellence and correctness. Of course I've made a number of good friends over the years, especially as a result of attending DebConf every year since 2007. me: You are member of Debian publicity team which writes Debian news - do you need more people to join that team and how can they start? pabs: Since there is an infinite amount of work to do, pretty much every part of Debian always needs help, that includes the publicity team. We published a post about ways to help here. me: If someone wants to contribute to Debian in terms of packaging, can they do it anonymously (for example over Tor network, does Debian have .onion address)? pabs: Due to Debian's penchant for transparency it is harder but there are definitely package maintainers who have built up a reputation for good work under a pseudonym over the years and become Debian contributors as a result. I'm not aware of completely anonymous package maintainers but there are definitely people who file bugs using one-off pseudonyms, which is almost the same thing as anonymously. There are definitely Debian contributors and members who use Tor while contributing to Debian. In fact, as Debian is very highly dependent on OpenPGP and the best practices for OpenPGP include refreshing your keyring slowly over Tor, so probably quite a number of Debian contributors use Tor. As far as I know Debian itself does not run any Tor relays or onion services. me: What are places that non-packaging developers and people could join and help spread Debian even more? pabs: There are many ways to help Debian, including non-technical ones. Unfortunately our web page about helping Debian isn't quite up-to-date with all of them but a few more are to volunteer at DebConf, helo with artwork requests, speak about Debian at events or even come up with ideas for projects. Whatever skills you have, Debian can probably make use of them. If you aren't sure where to start, jump on the debian-mentors mailing list or IRC channel and we can probably guide you to the right place within Debian. Don't worry about not being skilled enough, everyone starts somewhere. me: How do you see Debian will manage webapps? pabs: Personally I prefer locally installed software, standard data formats and standard data transfer protocols to the wild webapps world but I understand they are becoming very popular to produce and use due to the ubiquity of the web browser platform. Antonio Terceiro is mentoring a project for this year's newcomer mentorship programs (outreachy/gsoc) that aims to improve support for installing web apps on Debian installations. I hope it succeeds as it could help make Debian more popular on servers and home servers in particular. me: How would you advise Debian (and other FLOSS users) to setup their machine in terms of security and anonymity? pabs: All technology has upsides and downsides. I would advise anyone to analyse their situation and protect themselves accordingly. For example if you have a bad memory, full disk encryption, which is based on pass-phrases might lead to data loss and physical security might be a better choice for protecting your data. The right choices around technology are very much a personal thing. me: Is it better to setup xmonad (because it is Haskell based WM) with small dependency chain or GNOME (because it is getting sandboxed apps) in term of security and privacy implications? pabs: Again, the right choices around technology are very much a personal thing. Due to the design of X11, both of these are approximately equivalent from a window-manager security properties point of view, that is to say, pretty bad. Wayland is one of the possible X11 successors and offers much better security properties. GNOME folks are working on switching to Wayland. Ultimately though it comes down to how each person uses their window manager and which software they run under it. me: Should Debian join Tor project as distro that installs Tor relays by default - should it offer that as option in installer in Debian 9? pabs: Running a Tor relay requires a reasonably fast and reliable Internet connection and should be a conscious decision on behalf of the sysadmin for a computer so Debian probably shouldn't install them by default. If tasksel gets support for installing tasks from Debian Pure Blends, then we could add a Tor relay task to the Debian Sanctuary Pure Blend. me: Have you ever considered joining initiatives such as FreedomBox? pabs: I was quite moved by Eben Moglen's talk at DebConf10 in New York and the resulting BoF. It seemed like a very ambitious project but I didn't really have the knowledge, skills or time to contribute yet. me: Are you a gamer? Valve Steam games are offered for free to Debian Developers - do you use steam and play Valve games? Your thoughts on Steam and non-free Linux gaming? pabs: I play computer games occasionally, all from Debian main or ones that I'm packaging. 0ad is my current go-to for a bit of gaming. I don't have any experience with Steam or non-free games on Linux. me: Is there something you would change in FLOSS ecosystem? pabs: Various folks have highlighted new and ongoing challenges for the FLOSS ecosystem in various places in recent years. Something that I would like to highlight that does not get talked about enough is the choices we make around our digital artefacts. This is the discussion around "preferred form for modification" or "source". The "source" for a particular digital artefact is a deliberate choice on behalf of the authors. Often generated files are distributed alongside the "source" without any instructions for reproducing the generated files from the "source". It sometimes happens that FLOSS contributors forget to distriute what they have chosen as "source", instead just distributing the generated files. This is a fairly well known issue but still happens. What isn't thought about quite as much is that the choice of "source" has consequences for future development possibilities of that "source". Some forms of "source" are more expressive than others, can be modified in a wider variety of ways and are better choices in general. Sometimes the consequences of choosing less expressive forms are mild and other times they are quite important. I hope more people will start to think about these choices. Some examples where, in my opinion, various people could have made better choices are listed in the mail I sent to the games team list last year. Another thing I would like to highlight is the work that organisations like Software Freedom Conservancy and Software in the Public Interest do to protect, defend, promote and support FLOSS projects. It is very important work that needs our interest and support. me: Can FLOSS world create great alternatives to Viber, Dropbox, WhatsUp, Facebook, Skype and other non-free services? pabs: I think that the FLOSS world has already created alternatives to all of those. The success of non-free services doesn't take these alternatives away but it does mean some of them are less useful because some of them are the kind of tools that become more useful with a larger amount of people using them. I don't know what it would take for the FLOSS alternatives to achieve similar success as network effects are hard to overcome. Hopefully mako is right and the network effects are overrated. me: Your thoughts and compare Cloud, IaaS, PaaS, SaaSS? To what should the FLOSS world pay more attention and energy? pabs: Initially I dismissed these as buzzwords and a threat to Free Software. These days I view them as potential opportunities for Free Software. Cloud-related technologies such as OpenStack and virtual machines can make private compute farm hardware more flexible and useful to their owners. IaaS providers can be used to run Debian more simply and cheaply and therefore bring Debian to more people than possible with hardware. PaaS providers can be used to run Free Software services. SaaSS can be based entirely on Free Software and respect users. Of course, just like running Free Software on hardware (proprietary or libre), cloud technology, IaaS, PaaS and SaaSS all come with downsides. The FLOSS world should aim to inform users of our software of these downsides. For example, the Debian installer could note that it is running on Intel CPUs with a proprietary BIOS and various proprietary software running, that it is running on a mobile phone with a locked bootloader, that it is running in a Xen VM on machines owned by Amazon. Free Software services could note they are running on Google App Engine etc. Free Software web browsers, chat clients etc could note when they are connecting to proprietary network services. All these notes could inform users about the downsides present in the particular situation encountered. There is also much work to be done making it easier to run Free Software on top of or use Free Software to connect to all manner of platforms from lowRISC to UEFI to VMware to Google App Engine to GitHub to Facebook. The more places Free Software can reach, the more people will be exposed to the philosophy behind it and the more potential there is for folks to join the community. While co-option of the FLOSS world is a dangerous certainty, co-option of proprietary platforms might be able to expand the reach of the philosophy behind Free Software. me: Your thoughts on Purism (the open hardware laptop initiative that got recently funded on CrowdSupply)? pabs: I don't know enough about that to comment but personally I am more interested in a laptop based on a libre CPU architecture. The RISC-V ISA and the lowRISC project seems to be one of the more promising possibilities at this point in time. me: Did you watch Citizenfour - comments on it? pabs: I've seen the trailer and look forward to watching it at some point, I read there might be a screening at DebConf15.

Follow me on Identi.ca or Twitter or Diaspora* Backup Checker is a command line software developed in Python 3.4, allowing users to verify the integrity of archives (tar,gz,bz2,lzma,zip,tree of files) and the state of the files inside an archive in order to find corruptions or intentional of accidental changes of states or removal of files inside an archive. The major feature of this new version is the ability of Backup Checker to use Unix streams. Using classic Unix tools like OpenSSH or wget, Backup Check is able to verify a remote tar. gz,bz2,xz archive. The following example verifies a tar.gz archive located on remote server through SSH: $ ssh -q server "cat /tmp/backup.tar.gz" ./backupchecker.py -c . -
Another short example with the FTP protocol, to verify a tar.bz2 archive located on a remote server through FTP:

$ wget --quiet -O - ftp://user:pass@server/backup.tar.gz   ./backupchecker.py -c . -

Moreover in this release, a new option configuration-name allows the user to define a custome name for the files generated by Backup Checker (default is defined from the name of the archive using the -g or -G options). It is a major step for Backup Checker. It is indeed easier and easier to use Backup Checker in your own scripts, allowing to fully automate your backup controls. Several companies now use Backup Checker to secure their backups. Let us know if we can help you. As usual, any feedback is welcome, through bug reports, emails of the author or comments on this blog.

I've been playing around with Debian and Docker a little bit. I found Joey Hess' post about Docker trust interesting reading, in particular this advice:

I'd recommend only trusting docker images you build yourself. I have some docker images published somewhere that are built with 100% straight debootstrap with no modifications (...) But I'm not going to link to them, because again, you should only trust docker images you built yourself.

On that advice, I did exactly that. I've pushed the basic scripts I used to build my images to github:jmtd/debian-docker. Suggestions welcome! However, I am planning to share the images I build, at least for my own convenience, on the Docker repository. I'm hoping to publish some PGP-signed sums somewhere so you could verify the binary images on the Docker registry if you so wish. The three images I'm currently maintaining are:

• jmtd/debian:buildd: a sid image, variant buildd, to use as the base for package builds
• jmtd/debian:wheezy: a minbase wheezy
• jmtd/debian:wheezy-i386: a minbase wheezy, i386

(note: I haven't pushed them all yet.) With docker 1.5.x at least, the i386 image works fine on amd64 hosts. I've used it as the basis for running wine and Windows binaries. I might push a wine image if I generalise it enough to be more useful. The Docker folks recommend using Debian as a base image because it's a small size (approx. 163M for my base image, 85.01M for the semi-official one: See Joey's blog for some of the differences) but with a good set of tools. I wondered whether I could leverage the efforts of the Emdebian project to get an even smaller base image. Unfortunately, the Emdebian project discontinued their 'Grip' project midway through last year. A basic Emdebian grip install is a fair bit smaller than the equivalent wheezy image, but once you've applied security updates most of the difference is lost. I suspect that some of Emdebian's minimisation techniques would be useful and applicable for shrinking Docker base images.

Mom and Debian is an awesome combination. :)

I just released NBD 3.9 When generating the changelog, I noticed that 3.8 happened two weeks shy of a year ago, which is far too long. As a result, the new release has many new features:

• AF_UNIX support
• New "treefiles" mode, which exports a gazillion of page-sized files; useful for exporting things which are stored on an SSHFS or amazon AWS (trough FUSE) or similar, where every write causes an upload to the backend storage
• New "cowdir" option, allowing to specify where copy-on-write files are written.
• Minor changes so that nbd-client can now also be compiled for the Android platform. This required removal of the -swap command line option, which requires the mlockall() system call, unavailable on Android.
• Protocol update: a reserved bit is used to avoid sending the 124 bytes of useless data at the beginning of the negotiation. The change is implemented so that things will still work with clients not supporting this option, however.
• gznbd is now built by the same build system, rather than a separate one. Note however that gznbd is still unmaintained; it should be considered a "contrib" feature.
• "nbd-server -V" will now output the nbd-server version number.
• Fixed test suite on non-GNU getopt() implementations
• Various fixes found through Coverity and the clang static analyzer, and lots of other minor things too small to mention here.

Get it at the usual place.

I've been using distributed version control systems for a good while, started with TLA back in 2001, when it was still a bunch of shell scripts and was simply called "Arch". I jumped the Git bandwagon quite early too, sometime around May 2005, I believe, though it was only something to test and play with on the side: I didn't migrate my projects over yet. There are many reasons why I preferred these over the systems I used in the past (RCS and CVS; never considered Subversion an option), most of those reasons have been discussed at length over the years, and there's no reason to do so again.The reason for this post, is because I read a blog post about why Git and the other DVCSes fall short. There are a number of things in that article that I find... well, lets just say misinformed. I'll try to explain why.But here's the rub

I have wanted to have the full history while offline a grand total of maybe about six times. And this is merely going down over time as bandwidth gets ever more readily available. If you work as a field tech, or on a space station, or in a submarine or something, then okay, sure, this is a huge feature for you. But for the rest of us, I am going to assert that this is not the use case you need to optimize for when choosing a VCS.

I'm neither a field tech, nor do I work on a space station or a submarine. Yet, having the full history available locally has been crucial for my work for at least the past six years. Initially, I worked offline primarily, because my internet connection was incredibly limited (slow, expensive and unreliable), yet, I had a habit of committing small changes often. I needed a full clone to work effectively, and conveniently. Throw-away branches and all that - I needed them local, I didn't have the resources to push them online every time I wanted a merge.But now that I have fast and reliable internet, why do I need the full history on my own computer? I do, because I do much more research than I do development. The vast majority of my work between 2010 and 2012 involved reading histories, cherry picking and so on. About six hours a day, I was reading the past. Having the full history locally is a terrific aid when your job involves digging through it.Between 2013 and 2014, the amount of history reading dropped significantly, but I still worked with long-lived branches a lot, branches where history matters, where having easy and fast access to them is indispensable. I still had to find changes based on content (not commit message, branch, date or anything - content) on a daily basis. Hitting the network for each and every search would have wasted not only tremendous bandwidth and processing power on the server, but also a significant amount of time.If you do more maintenance and research, or follow a good number of branches (or forks), with the intent to merge and cherry-pick actively from them, having all the histories available locally is a huge improvement. I'm happy to pay the price of "wasting" disk space to have this available. I couldn't work otherwise. Without full, local history, the things I did for syslog-ng would not have been possible. No maintenance, none of the features I implemented, none of the fixes I found. Why? Because I rely on the project's history to aid me in learning the whys, not just the hows.Thank you, but - perhaps unlike others - I like to learn from the past, and prefer doing it efficiently.Say goodbye to blobs (or your sanity (and sometimes both))

You know what kind of external binary asset management system works really well? Subversion. Turns out it works tolerably for source control, too. Maybe you should take a look at it.

Sure, some systems are better at managing binary assets. Git - and usually DVCSes - are terrible at it. There's nothing stopping anyone from using two systems: one for source, another for data. Mind you, I am extremely happy with git-annex. I disagree with Subversion being tolerable for source control. I'd turn this assertion around instead: You know what kind of system works really well for source code? Git. Turns out it works tolerably as an external binary assest management system, too. Maybe you should take a look at it.But then, I rarely need to work with blobs, so I'm likely not the best person to disagree here.Say goodbye to sane version synchronizationOkay, so this part of the article is ill-titled, I believe. Large repositories and version synchronisation are two different, not necessarily related topic. Granted DVCSes may not be the best fit for large repositories, but neither are centralised version control systems, based on my past experience. I had the misfortune of working with a roughly 3-4Gb (checked out) project, with extensive history, managed with a centralised version control system, without local history. It was terrible (and blame was so slow and expensive that we were told never to use it, because it crashed the server). While the system allowed us to have a reasonable overview over the whole project, but it utterly failed at allowing us to work at the component level. How do I see which version of component X we had in project release A? Or the version of component Y we had two weeks ago? Or what if we have component M, made up from components J and K, and belonging to component Z? Good luck managing that in a single repository.With TLA, we had configs, which were a bit cumbersome to use, but captured most of the essential parts of managing component bundling and hierarchical versioning far better than any other solution I've seen so far. I've yet to find an acceptable solution, but I'm convinced it will not have anything to do with centralised systems. You can't capture the delicate relations there.Say what again, I dare you, I double dare you

All of the above might be almost tolerable if DVCSes were easier to use than traditional SCMs, but they aren t.

I'm sorry, but have you tried managing a decently sized project, with a large history, built from multiple components with a traditional SCM? Because that is a colossal pain in the backside.Does Git's UI suck? Yes. But so did CVS's and Subversion's. If you rely on the command-line tools, you're going to feel the pain. That is why you use the IDE integration you surely have, which makes the most common tasks a breeze. That may sound like a git-apology, but remember, we did the same with every other version control system, because smart people prefer integration, and want the computer to work for them.

And yet, when someone dares to say that Git is harder than other SCMs, they inevitably get yelled at, in what I can only assume is a combination of Stockholm syndrome and groupthink run amok by overdosing on five-hour energy buckets.

If you feel the need to understand the innards of Git - then yes, it is harder than traditional SCMs. It is distributed, and different than what you're used to. If you do not have prior knowledge though, the difference in learning the internal working of Git and - say - Subversion all that different. And if you do not care how it works down below (and I dare say, a lot of developers should not, and do not care), then there is nothing to learn, apart from your IDE integration, which ain't different from a traditional SCM's.Mind you, I found it both interesting, and beneficial to learn Git's inner workings. Not only because it allowed me to make better use of my VCS, but because it taught me a bunch of things I could make use of elsewhere. I learned nothing from traditional SCMs.Do you hear the people sing, singing the song of angry men

There is one last major argument that I hear all the time about why DVCSes are superior, which is that they somehow enable more democratic code development.

The reason Git and other tools make code contribution easier is not GitHub pull requests (although, for drive-by contributions those are pretty useful too). The reason they make contribution easier is because you have your own copy of the full history. You can create your own branches easily, you can work with it as if you were the owner. For one-off contributions, that is no real advantage, I'll give you that. It takes more effort to fork & do a PR on GitHub, than to send a patch, I'll also agree with that.But once you start working with a project for more than a few patches, when you want to work with its history too, once you have long-lived branches, the local copy quickly becomes a great asset. Once you want to submit more than a few changes, you won't have to repeat a all steps. And not only that: since you have the full history, merging upstream changes (or just cherry picking from them), rebasing your work, and many other tasks become simpler.That is what it buys you, that is why it makes contribution easier. GitHub pull requests are an icing over the cake at best (and there are a good number of cases where the icing is completely unnecessary, because it doesn't go well with the cake).In closingIn closing, I'd like to highlight that different projects have different requirements. For example, I understand why Facebook, Google and a number of others use a single, huge repository. I happen to hate that setup, and would find working in such an environment horrible. But luckily, I don't work for those companies, and they don't listen to me, either, so everyone's happy. That does not mean I would go out and tell them they're wrong to use such a centralised, single-repository setup. For their use, in their situation, for their requirements, that may be the better option. For mine, not so much.In the end, what we need to realise is that there is no single tool that will fit all needs. There are tasks where Git is a terrible choice, but that does not make it terrible for all cases. Similarly, there are cases where Subversion is superior (I assume - I didn't have the misfortune of meeting with such a case).Instead of bashing the DVCS world, and assuming the Big Company use cases are all that matter, and that everyone uses the tools the same way, accept that some use it to achieve things you didn't think of, jobs you didn't consider.

Gammu 1.35.0 has been just released. This is just bugfix release to fix some major issues introduced in 1.34.0. Full list of changes:

• Fixed encoding of UTF-8 for higher code points.
• Improved provided udev rules.
• Fixed possible lock while getting network status in SMSD.
• Various localization updates.

You can download it from http://wammu.eu/download/. 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 Flattr this!

Last year for the DebConf edition that took place in Portland, we had some invited speakers that helped bring a different point of view to the matters discussed during the conference. This year we would like to do this again. If you would like to suggest inviting someone that would not regularly attend DebConf, the DebConf Content Team encourages you to do that now. We will stop accepting new suggestions on 10 March 2015. You can follow the simple procedure described on the Inviting Speakers page in the DebConf s Wiki Please keep in mind that we don t promise to bring to Heidelberg everyone that is suggested. The final list of invited speakers will depend on the speakers availability and our limited budget.

Recently, the Google protobuf developers announced a migration of their project's source code from an svn repository to a git repository. Up until this point, the Debian protobuf package repository had only tracked upstream development by embedding upstream release tarballs using gbp import-orig with pristine-tar. It would be nice to smoothly migrate the packaging repository to additionally make use of the --upstream-vcs-tag option to gbp import-orig, the advantages of which have been well described by Russ Allbery. This turned out to be harder than expected, so for reference I documented the steps I took below. Note that this packaging repository uses the default gbp import-orig repository layout, where upstream sources are placed on a branch named upstream, and the Debian branch is named master. Add an upstream remote configured to track the upstream repository's master branch and tags.

$ git remote add --tags --track master upstream https://github.com/google/protobuf.git

The upstream remote shouldn't be confused with our upstream branch. Note that git-remotes are local to the repository, so the upstream remote should probably be documented in the debian/README.source file. Fetch the upstream branch and tags.

$ git fetch upstream
warning: no common commits
remote: Counting objects: 5210, done.
remote: Compressing objects: 100% (861/861), done.
remote: Total 5210 (delta 3869), reused 5194 (delta 3855)
Receiving objects: 100% (5210/5210), 3.57 MiB   1.43 MiB/s, done.
Resolving deltas: 100% (3869/3869), done.
From https://github.com/google/protobuf
 * [new branch]      master     -> upstream/master
 * [new tag]         v2.6.0     -> v2.6.0
$

We now have a git-remote upstream, a remote-tracking branch upstream/master which corresponds to the master branch that upstream makes releases from, and a release tag v2.6.0. Note that the remote-tracking branch upstream/master shouldn't be confused with our master branch. Up until this point, our upstream branch has been synthetically generated by importing upstream's release tarballs with gbp import-orig. We need to merge this synthetic history with upstream/master. Unfortunately, I couldn't find a way to do this without using a temporary branch.

$ git checkout -b tmp upstream/master
Branch tmp set up to track remote branch master from upstream.
Switched to a new branch 'tmp'
$ git merge -s ours -m \
  "Merge the original 'upstream' branch with upstream's new master branch" upstream
Merge made by the 'ours' strategy.
$ git checkout upstream
Switched to branch 'upstream'
Your branch is up-to-date with 'origin/upstream'.
$ git merge --ff-only tmp
Updating 7ed940b..9ba221e
Fast-forward
 CHANGES.txt                                                          49 +-
 COPYING.txt => LICENSE                                                0
 Makefile.am                                                          64 +-
 Makefile.in                                                        1041 --
 README.txt => README.md                                              49 +-
[...many more lines...]
$ git branch -D tmp
Deleted branch tmp (was 5f18f02).
$

There are now an additional 400 or so commits on our upstream branch, corresponding to the new git repository history published by upstream. Import the 2.6.0 release tarball against the upstream v2.6.0 tag, using the --upstream-vcs-tag option.

$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
$ gbp import-orig -u 2.6.0 --upstream-vcs-tag=v2.6.0 ~/debian/tarballs/protobuf_2.6.0.orig.tar.gz
gbp:info: Importing '/home/edmonds/debian/tarballs/protobuf_2.6.0.orig.tar.gz' to branch 'upstream'...
gbp:info: Source package is protobuf
gbp:info: Upstream version is 2.6.0
pristine-tar: committed protobuf_2.6.0.orig.tar.gz.delta to branch pristine-tar
gbp:info: Merging to 'master'
gbp:info: Successfully imported version 2.6.0 of /home/edmonds/debian/tarballs/protobuf_2.6.0.orig.tar.gz
$

The upstream branch now contains a mixture of the original series of release tarball content imported by plain gbp import-orig and the upstream/master branch as published by upstream. Updating the Debian packaging repository when new upstream releases occur only requires a git fetch to pull down upstream's updated git history and release tag and using the --upstream-vcs-tag option when importing the release tarball with gbp import-orig.

A few weeks ago we introduced the drat package. Its name stands for drat R Archive Template, and it helps with easy-to-create and easy-to-use repositories for R packages. Two early blog posts describe drat: First Steps Towards Lightweight Repositories, and Publishing a Package. A new version 0.0.2 is now on CRAN. It adds several new features:

• beginnings of native git support via the excellent new git2r package,
• a new helper function to prune a repo of older versions of packages (as R repositories only show the newest release of a package),
• improved core functionality in inserting a package, and adding a repo.

Courtesy of CRANberries, there is a comparison to the previous release. More detailed information is on the drat 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.

FTP assistant Processing the new queue got off the ground again. This month I marked 154 packages for accept and rejected 20 packages. Some emails I got were rather funny and people are very creative when trying to interpret the license of upstream. But hey, most of the time upstream has a reason to choose a specific wording. You can try to interpret those words, but don t waste your time. Better ask upstream about their intention and whether this fits into the world of Debian. It only sounds strange when upstream publishes their stuff under licenseA and wants to distribute their files under licenseB but insists on keeping the wording of licenseA. That s life! Squeeze LTS This was my eighth month that I did some work for the Squeeze LTS initiative, started by Raphael Hertzog at Freexian. This month I got assigned a workload of 14.5h and I spent these hours to upload new versions of:

• [DLA-145-2] php5 regression update
• [DLA 146-1] krb5 security update
• [DLA 150-1] unzip security update
• [DLA 151-1] libxml2 security update
• [DLA 162-1] e2fsprogs security update

For whatever reason, the DLA-145-2 didn t reach debian-lts-announce. As the listmaster didn t find any reason for this (at least the other emails all appeared), I think there has been some extraterrestrial influence ( The Truth Is Out There ). Anyway, I also worked on an upload for binutils, but one patch is a real 100kB-beast. Meanwhile I am down to only one regression in one source file, so I hope that there will be an upload in March. I also uploaded one DLA for libgtk2-perl ([DLA 161-1] libgtk2-perl security update although no LTS sponsor indicated any interest. Other packages I didn t do any work on other packages, but looking at the bug count, the number of bugs has increased. So, sorry, if you sent in a bug report and I didn t answer. It is not forgotten. Donations After adding some micro payment buttons to my blog in January, I already got a donation of 20 in February. I really appreciate this and I feel vindicated that my contributions to Debian are still useful.

This was my third month working on Debian LTS, and the first where I actually uploaded packages. I also worked on userland packages for the first time. In the middle of February I finished and uploaded a security update for the kernel package (linux-2.6 version 2.6.32-48squeeze11, DLA 155-1). I decided not to include the fix for CVE-2014-9419 and the large FPU/MMX/SSE/AVX state management changes it depends on, as they don't seem to be worth the risk. The old patch system used in linux-2.6 in squeeze still frustrates me, but I committed a script in the kernel subversion repository to simplify adding patches to it. This might be useful to any other LTS team members working on it. In the past week I uploaded security updates for cups (version 1.4.4-7+squeeze7, DLA 159-1) and sudo (1.7.4p4-2.squeeze.5, DLA 160-1). My work on the cups package was slowed down by its reliance on dpatch, which thankfully has been replaced in later versions. sudo is a more modern quilt/debhelper package, but upstream has an odd way of building manual pages. In the version used in squeeze the master format is Perl POD, while in wheezy it's mandoc, but in both cases the upstream source includes pre-generated manual pages and doesn't rebuild them by default. debian/rules is supposed to fix this but doesn't (#779363), so I had to regenerate 'by hand' and fold the changes into the respective patches. Finally, I started work on addressing the many remaining security issues in eglibc. Most of the patches applied to wheezy were usable with minimal adjustment, but I didn't have time left to perform any meaningful testing. I intend to upload what I've done to people.debian.org for testing by interested parties and then make an upload early in March (or let someone else on the LTS or glibc team do so). Update: I sent mail about the incomplete eglibc update to the debian-lts list.