I don't think my bug reports appeared yet. So far I filed two bug reports and waiting for a while; BTS doesn't seem to accept my mails. Something changed?

Merging and testing. I've uploaded pbuilder and cowdancer with all NMUs included. I think the tests pass and things look reasonably good, and nothing should break because all the NMU diffs have been incorporated. In all of the NMUs I saw zero lines of test code change, so these aren't unit tested or regression tested, but manual tested. Something I want to see change is to see people having test code updated on every upload or bugfix.

Disclaimer: This post only describes what I ve been hacking on those days, and why. I haven t finished yet, and that might be too long of a story for a blog/planet. I m therefore duplicating the problem and the context, and mentioning the parts already documented on the page dedicated to that hack. Challenge: How to send commands to a computer without using an input device? Context: While it s not frequent, I sometimes run into situations where no input devices would work. That can happen because of a new X server with no compatible input devices; or while running a sample Wayland compositor on a console with X still running (not exactly sure what the problem was exactly); or because running gdb on X from within X is a bad idea; etc. Simple, non-bulletproof solutions:

• Obviously, sshing from another machine is the ideal situation. But that requires an extra machine, which might not be available during a train trip.
• Using a smartphone to do that would be nice, but would require buying such a phone.
• Having an extra input device, with an appropriate X configuration (i.e. not taking that input device into account) could also work. But that wouldn t really help with some weird situations involving console, Wayland compositor, and X.

Alternative, viable solution 1: Buying a tiny, open, programmable device, like the Arduino Nano, a few components like a selector and a push button might do the trick. Then, some bits of programming with the open source Arduino environment should make it possible to connect that device to a USB port using a mini-B cable. Some bits going through a serial console and a daemon listening on it would make it possible to trigger a predefined set of actions just by selecting a position and hitting the button. Tada! No drawback for that solution, except the need for thinking about bringing that device everywhere. :) Alternative, viable solution 2: While I m by no means a phone addict, I tend to have it with me more or less all the time, and it can be connected through a mini-B USB cable. Oh, but then, maybe I could turn it into a suitable device as described above? That s a Motorola RAZR V3, it runs Java applications, and there s a SDK available for Linux (32 bits) through the Motorola developer network. That might be enough, so I decided to jump through some hoops to see whether that s indeed feasible. Not because I like it much better than the Arduino-based solution, just because I can. My hack orola page explains how I went from the maybe it s possible idea to the yes, now I know how to build, upload, and run a custom application certitude. It still lacks the actual Java code running on the phone, as well as its Unix daemon counterpart, but for a good reason: they need be written! At the moment the following sections are available:

• Step 1: Enabling Java Application Loader
• Step 2: Getting the SDK
• Step 3: Toying with a trivial project
• Step 4: Getting ready to deploy

One slightly unexpected effect of all the travel I ve been doing recently is that I get a real, visceral sense of place from some slightly surprising places when I see them on the big screen. Having an idea of how the place really is, how people behave, how the air feels, how the food tastes, how it smells, a sense of what s around the corner and beyond the camera. A sense of memory, not of imagination or of an idea of what a place should be. San Francisco is one place this happens for and is perhaps not so surprising it is a pretty distinctive place after all and the imagery was already familiar from countless movies and TV shows before I ever went there. What was a bit more surprising was a random suburban area in South Korea; Korea has had a real building boom amid all the growth it s had which has resulted in a certain look and feel to the architecture and the cities being very common though not distinctive of any once place. That s the space where a lot of the more real world Korean films are set, and it s the one I recognise. Don t think I ve ever seen a film that ventured into Itaewon ( ), mind you. It s a much stronger feeling of recognition than I get with anywhere in the UK, I think purely due to the surprise factor. Having a good picture of Edinburgh isn t a great surprise, finding how quickly I ve built one up of places on other continents much more so.

Just been testing the upcoming lintian 2.5.2 vendor-profile branch for operations with packages processed by emdebian-grip, both for the emdebian-grip and the emdebian-baked vendors.

The good news is that instead of the problematic support from Lenny, lintian in Wheezy will have support for testing Emdebian packages using Emdebian Policy. All Debian tags are up for grabs, no more exceptions for checks which couldn't be disabled before (like the forced removal of manpages).

Also been able to work out how to sort out lintian checks for Emdebian Crush including adding the extra tags which haven't seen use since Lenny.

So that's outline lintian support for Grip, Baked and Crush. Thanks to Niels Thykier for the lintian support.

Last week I tried switching a library to Gtk3. The needed changes to the code are available through --with-gtk3. However this is generally not enough. Even if your symbol list doesn't change, the ABI changes implicitly. The library in question had a .symbols file, but that's not enough because the resulting GUI application will bail out at runtime if symbols of both Gtk2 and Gtk3 are found in the same address space. That's mostly because C symbols don't contain any signatures with return types and parameters.

So if your library upstream did not change the soname for the Gtk3 build, please encourage them to do so. Also keep in mind that this most likely means new pkg-config files specific to the Gtk3 build, too. At least if you want your reverse-depends to be able to build against either Gtk2 or Gtk3 in a predictable way.

An example is this change to gtk-vnc, which uses gtk-vnc-2.0 as the new API/pkg-config name for the Gtk3 build, gtk-vnc-1.0 remains the old Gtk2 one. The soname changes from libgtk-vnc-1.0.so.0 to libgtk-vnc-2.0.so.0.

(Thanks to Michael Biebl and Julien Cristau for pointing out the obvious to me.)

The goal of this lab is to setup a site-to-site IPsec VPN. This lab is similar to my first lab using UML. The major differences are:

• We only setup one VPN instead of two.
• Static routing is used in place of BGP for inter-site routing. Moreover, BIRD is used as a routing daemon.
• VPN are using an external network for Internet access.
• Both internal network and external network are redundant using one OSPF instance each.

The lab

The big picture The main point of this architecture is that you get two redundant networks for each site. The external ones are used when hosts need Internet access. The internal ones are used when they want to communicate with each other. Because we don t want hosts from the first site to communicate with hosts from the second site through the external network, we extend the internal network with the help of a site-to-site IPsec VPN. Each set of networks is using two layer-3 networks on top of two layer-2 networks. OSPF is used to provide redundancy and aggregation. For example, R1 has two routes through V1 to access R2 which is on the other site:

# ip route show 192.168.96.0/19
192.168.96.0/19  proto zebra  metric 10000 
        nexthop via 192.168.1.100  dev eth0 weight 1
        nexthop via 192.168.2.100  dev eth1 weight 1

Setting up the lab First, grab the source of the lab:

$ git clone https://vincentbernat@github.com/vincentbernat/network-lab.git
$ cd network-lab/lab-s2s-vpn

You may try to run ./setup directly. It may be safer to build an image of Debian inside inside a directory and use it as a base for the lab.

$ sudo debootstrap sid ../sid-chroot http://ftp.fr.debian.org/debian/
[...]
$ sudo chroot ../sid-chroot /bin/bash
# apt-get install iproute zsh rsyslog less makedev tcpdump
# apt-get install bird quagga racoon
# exit
$ ROOT=../sid-chroot ./setup

You still need a working UML kernel. On Ubuntu, the one provided in user-mode-linux does not contain the aufs.ko module. I did not find a simple workaround. You can just grab the package from Debian and install it on your Ubuntu with dpkg -i.

Use of BIRD With the previous lab, Quagga was used as an OSPF routing daemon. We still use it on R1, R2, E1 and E2. However, Quagga is not able to run multiple instances of OSPF. BIRD can. Therefore, we use it on V1 and V2 because we need two OSPF instances: one for the external network and one for the internal network. Since we also need ECMP, we need at least BIRD 1.3.0. BIRD allows the definition of multiple routing tables. Those tables are independant of the kernel routing tables. Each protocol will maintain its own set of routes and will allow to export (or import) routes from one of the routing table maintained by BIRD. In our setup, we use four protocols and only one routing table (the default one). The ospf EXTERNAL protocol is one of the two OSPF instances we use on V1. We import all the routes learned through the OSPF process into the internal BIRD routing table. We don t export any route from the BIRD routing table to this OSPF instance. Here is the configuration of this protocol:

protocol ospf EXTERNAL  
   ecmp yes;
   import all;
   export none;
   area 0.0.0.0  
      networks  
         203.0.113.0/26;
         203.0.113.64/26;
         203.0.113.150/32;
       ;
      interface "eth2";
      interface "eth3";
      interface "lo"  
        stub yes;
       ;
    ;
 

203.0.113.150/32 is defined on the loopback interface of V1. This is the IP of the local VPN endpoint. The ospf INTERNAL protocol is the second OSPF instance. We import all routes from this protocol to the BIRD routing table. We also want to advertise the route to the remote site. This route is defined in the static STATIC protocol and imported into BIRD routing table.

protocol static STATIC  
   import all;
   export none;
   route 192.168.96.0/19 via "lo";
 

Therefore, ospf INTERNAL protocol export all routes originating from the static STATIC protocol. This is done using filters:

protocol ospf INTERNAL  
   ecmp yes;
   import all;
   export filter  
     if proto = "STATIC" then accept;
     reject;
    ;
   area 0.0.0.0  
      networks  
         192.168.1.0/24;
         192.168.2.0/24;
       ;
      interface "eth0";
      interface "eth1";
    ;
 

The kernel protocol is managing one kernel routing table. By default, it handles the main table. We don t import any route from the kernel. However, we copy routes that come from other protocols, except the static route because we already have a default route and the static route is some kind of blackhole, we don t want to use it for real routing.

protocol kernel  
   persist;
   import none;
   export filter  
     if proto = "EXTERNAL" then accept;
     if proto = "INTERNAL" then accept;
     reject;
    ;
 

The filtering mechanism built inside BIRD is pretty powerful.

Testing After starting the lab, you need to wait a few seconds. You should then be able to ping R2 from R1:

R1# ping -c3 -I 192.168.15.1 192.168.115.1
PING 192.168.115.1 (192.168.115.1) from 192.168.15.1 : 56(84) bytes of data.
Warning: time of day goes back (-5435us), taking countermeasures.
64 bytes from 192.168.115.1: icmp_req=1 ttl=62 time=0.921 ms
64 bytes from 192.168.115.1: icmp_req=2 ttl=62 time=0.569 ms
64 bytes from 192.168.115.1: icmp_req=3 ttl=62 time=0.698 ms
--- 192.168.115.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2009ms
rtt min/avg/max/mdev = 0.569/0.729/0.921/0.147 ms

On V1, you can check BIRD internal routing table using birdc:

> show route 
0.0.0.0/0          multipath [EXTERNAL 19:43] * E2 (150/10/1) [0.0.0.11]
        via 203.0.113.1 on eth2 weight 1
        via 203.0.113.65 on eth3 weight 1
192.168.96.0/19    dev lo [STATIC 19:42] * (200)
192.168.1.0/24     dev eth0 [INTERNAL 19:42] * I (150/10) [0.0.0.100]
192.168.2.0/24     dev eth1 [INTERNAL 19:42] * I (150/10) [0.0.0.100]
192.168.15.0/24    multipath [INTERNAL 19:43] * I (150/20) [0.0.0.10]
        via 192.168.1.10 on eth0 weight 1
        via 192.168.2.10 on eth1 weight 1
203.0.113.0/26     dev eth2 [EXTERNAL 19:42] * I (150/10) [0.0.0.100]
203.0.113.64/26    dev eth3 [EXTERNAL 19:42] * I (150/10) [0.0.0.100]
203.0.113.150/32   dev lo [EXTERNAL 19:42] * I (150/0) [0.0.0.100]

The kernel routing table is similar except it does not contain the static route.

Adding more redundancy The first goal of this lab was to test multiple OSPF instances and ECMP with BIRD. It could be completed:

• Adding a redundant VPN is easy: this is just a matter of duplicating the setup of the existing VPN.
• Each router should be redundant by getting a sibling with the same configuration. In the case of R1 and R2, a VIP could be shared between the router and its sibling with VRRP to allow hosts behind to have a single gateway and not use a routing protocol.
• Because of the use of static routes instead of BGP, there is nothing to detect a VPN failure (which may be problematic if we setup a redundant VPN). Some VPN are able to invalidate a route when the associated VPN is down. This is not our case. Moreover, there may be some duplication in routing. This is not the case here because each site has its own internal network.

The goal of this lab is to setup a site-to-site IPsec VPN. This lab is similar to my first lab using UML. The major differences are:

• We only setup one VPN instead of two.
• Static routing is used in place of BGP for inter-site routing. Moreover, BIRD is used as a routing daemon.
• VPN are using an external network for Internet access.
• Both internal network and external network are redundant using one OSPF instance each.

The lab

The big picture The main point of this architecture is that you get two redundant networks for each site. The external ones are used when hosts need Internet access. The internal ones are used when they want to communicate with each other. Because we don t want hosts from the first site to communicate with hosts from the second site through the external network, we extend the internal network with the help of a site-to-site IPsec VPN. Each set of networks is using two layer-3 networks on top of two layer-2 networks. OSPF is used to provide redundancy and aggregation. For example, R1 has two routes through V1 to access R2 which is on the other site:

# ip route show 192.168.96.0/19
192.168.96.0/19  proto zebra  metric 10000 
        nexthop via 192.168.1.100  dev eth0 weight 1
        nexthop via 192.168.2.100  dev eth1 weight 1

Setting up the lab First, grab the source of the lab:

$ git clone https://vincentbernat@github.com/vincentbernat/network-lab.git
$ cd network-lab/lab-s2s-vpn

You may try to run ./setup directly. It may be safer to build an image of Debian inside inside a directory and use it as a base for the lab.

$ sudo debootstrap sid ../sid-chroot http://ftp.fr.debian.org/debian/
[...]
$ sudo chroot ../sid-chroot /bin/bash
# apt-get install iproute zsh rsyslog less makedev tcpdump
# apt-get install bird quagga racoon
# exit
$ ROOT=../sid-chroot ./setup

You still need a working UML kernel. On Ubuntu, the one provided in user-mode-linux does not contain the aufs.ko module. I did not find a simple workaround. You can just grab the package from Debian and install it on your Ubuntu with dpkg -i.

Use of BIRD With the previous lab, Quagga was used as an OSPF routing daemon. We still use it on R1, R2, E1 and E2. However, Quagga is not able to run multiple instances of OSPF. BIRD can. Therefore, we use it on V1 and V2 because we need two OSPF instances: one for the external network and one for the internal network. Since we also need ECMP, we need at least BIRD 1.3.0. BIRD allows the definition of multiple routing tables. Those tables are independant of the kernel routing tables. Each protocol will maintain its own set of routes and will allow to export (or import) routes from one of the routing table maintained by BIRD. In our setup, we use four protocols and only one routing table (the default one). The ospf EXTERNAL protocol is one of the two OSPF instances we use on V1. We import all the routes learned through the OSPF process into the internal BIRD routing table. We don t export any route from the BIRD routing table to this OSPF instance. Here is the configuration of this protocol:

protocol ospf EXTERNAL  
   ecmp yes;
   import all;
   export none;
   area 0.0.0.0  
      networks  
         203.0.113.0/26;
         203.0.113.64/26;
         203.0.113.150/32;
       ;
      interface "eth2";
      interface "eth3";
      interface "lo"  
        stub yes;
       ;
    ;
 

203.0.113.150/32 is defined on the loopback interface of V1. This is the IP of the local VPN endpoint. The ospf INTERNAL protocol is the second OSPF instance. We import all routes from this protocol to the BIRD routing table. We also want to advertise the route to the remote site. This route is defined in the static STATIC protocol and imported into BIRD routing table.

protocol static STATIC  
   import all;
   export none;
   route 192.168.96.0/19 via "lo";
 

Therefore, ospf INTERNAL protocol export all routes originating from the static STATIC protocol. This is done using filters:

protocol ospf INTERNAL  
   ecmp yes;
   import all;
   export filter  
     if proto = "STATIC" then accept;
     reject;
    ;
   area 0.0.0.0  
      networks  
         192.168.1.0/24;
         192.168.2.0/24;
       ;
      interface "eth0";
      interface "eth1";
    ;
 

The kernel protocol is managing one kernel routing table. By default, it handles the main table. We don t import any route from the kernel. However, we copy routes that come from other protocols, except the static route because we already have a default route and the static route is some kind of blackhole, we don t want to use it for real routing.

protocol kernel  
   persist;
   import none;
   export filter  
     if proto = "EXTERNAL" then accept;
     if proto = "INTERNAL" then accept;
     reject;
    ;
 

The filtering mechanism built inside BIRD is pretty powerful.

Testing After starting the lab, you need to wait a few seconds. You should then be able to ping R2 from R1:

R1# ping -c3 -I 192.168.15.1 192.168.115.1
PING 192.168.115.1 (192.168.115.1) from 192.168.15.1 : 56(84) bytes of data.
Warning: time of day goes back (-5435us), taking countermeasures.
64 bytes from 192.168.115.1: icmp_req=1 ttl=62 time=0.921 ms
64 bytes from 192.168.115.1: icmp_req=2 ttl=62 time=0.569 ms
64 bytes from 192.168.115.1: icmp_req=3 ttl=62 time=0.698 ms
--- 192.168.115.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2009ms
rtt min/avg/max/mdev = 0.569/0.729/0.921/0.147 ms

On V1, you can check BIRD internal routing table using birdc:

> show route 
0.0.0.0/0          multipath [EXTERNAL 19:43] * E2 (150/10/1) [0.0.0.11]
        via 203.0.113.1 on eth2 weight 1
        via 203.0.113.65 on eth3 weight 1
192.168.96.0/19    dev lo [STATIC 19:42] * (200)
192.168.1.0/24     dev eth0 [INTERNAL 19:42] * I (150/10) [0.0.0.100]
192.168.2.0/24     dev eth1 [INTERNAL 19:42] * I (150/10) [0.0.0.100]
192.168.15.0/24    multipath [INTERNAL 19:43] * I (150/20) [0.0.0.10]
        via 192.168.1.10 on eth0 weight 1
        via 192.168.2.10 on eth1 weight 1
203.0.113.0/26     dev eth2 [EXTERNAL 19:42] * I (150/10) [0.0.0.100]
203.0.113.64/26    dev eth3 [EXTERNAL 19:42] * I (150/10) [0.0.0.100]
203.0.113.150/32   dev lo [EXTERNAL 19:42] * I (150/0) [0.0.0.100]

The kernel routing table is similar except it does not contain the static route.

Adding more redundancy The first goal of this lab was to test multiple OSPF instances and ECMP with BIRD. It could be completed:

• Adding a redundant VPN is easy: this is just a matter of duplicating the setup of the existing VPN.
• Each router should be redundant by getting a sibling with the same configuration. In the case of R1 and R2, a VIP could be shared between the router and its sibling with VRRP to allow hosts behind to have a single gateway and not use a routing protocol.
• Because of the use of static routes instead of BGP, there is nothing to detect a VPN failure (which may be problematic if we setup a redundant VPN). Some VPN are able to invalidate a route when the associated VPN is down. This is not our case. Moreover, there may be some duplication in routing. This is not the case here because each site has its own internal network.

I had cause to try and get a core dump from a segfaulting process at work the other day, and I wanted to figure out if fiddling with /etc/security/limits.conf was going to do the trick (I didn't) or if I had to modify the initscript to include a ulimit -c unlimited call. Of course, on a modern system (>= 2.6.24), one would just take a look at /proc/PID/limits and get on with life, but unfortunately the system in question was running 2.6.18, so more fiddling around was required. I'd found something once before that told me how to do it with GDB, but all I could find this time around was a rather over-complicated Knol article, which made a bunch of assumptions (well mainly that the binary in question wasn't stripped). So with some help from the Knol article, I muddled through it. Disclaimer: I don't profess to be an expert on system internals like this, so if this eats your first-born, don't come crying to me. Firstly, you need to know that it's the getrlimit(2) system call that you want to be using, and then you need to figure out the number for the resource limit you want to retrieve. The man page for getrlimit(), tells you it's defined in /usr/include/sys/resource.h, but I've found that the actual useful bits end up being in /usr/include/bits/resource.h I wanted the resource limit for the maximum core dump size, which is RLIMIT_CORE and has a value of 4. Next, you need to know that the getrlimit() system call takes an integer and a pointer to an rlimit structure as arguments. We've just figured out the value for the integer, but we're also going to need to pass a pointer as the second parameter. A pointer to enough memory to hold an rlimit structure. Fortunately, the rlimit structure is pretty simple:

struct rlimit  
    rlim_t rlim_cur;  /* Soft limit */
    rlim_t rlim_max;  /* Hard limit (ceiling for rlim_cur) */
 ;

After a bit of grepping around in /usr/include, I determined that an rlim_t is essentially an unsigned long int, so we need to allocate a pointer big enough to hold two of them. Note that if we had an unstripped binary, we could have saved a lot of faffing around by just going

print sizeof(struct rlimit)

in GDB (assuming that the binary has the getrlimit symbol in it) The sure-fire way of figuring out how much memory we need for this pointer is to go

print sizeof(unsigned long int)

in GDB, and then double that (since we want two of them). On my system an unsigned long int is four bytes, so I'm going to want to allocate enough memory for 8 bytes. Now it's time to attach GDB to the offending process and see what the resource limit currently is. (gdb -p PID)

(gdb) print malloc(8)
$1 = 152186904
(gdb) print getrlimit(4, $1)
$2 = 0
(gdb) x/2xw $1
0x9123018:	0x00000000	0x7fffffff
(gdb) quit

So in this particular case, we've retrieved the soft and hard limits of the RLIMIT_CORE resource limit, and you can see that the soft limit is zero, and the hard limit is unlimited. Note that the getrlimit() function returns an integer as its return code, which is what the $2 = 0 is above. Now it's just a case of altering the the resource limits via the preferred mechanism, restarting the process and then repeating this GDB examination of the process to check they were changed successfully. Circumstances where this can all fall down would appear to be ones where the getrlimit symbol isn't present in the binary, or the binary is compiled as a position-independent executable. I'd think that in the latter case, the system is probably modern enough to be running a kernel that supports directly examining the resource limits via the /proc filesystem.

Looking at accumulated NMUs. There have been 4 NMUs to pbuilder and 2 NMUs to cowdancer (or rather, qemubuilder built from the same source tree). First task to resume work is to merge those changes back in to the git tree.

Conrad Sanderson released version 1.99.5 of Armadillo yesterday. This provides the fifth release candidate en route to version 2.0.0. He was even kind enough to post on rcpp-devel about it too as it entails some minor API changes. His version 1.99.5 has been integrated into RcppArmadillo version 0.2.23 which is now on CRAN. By way of background, Armadillo is a templated C++ library for linear algebra---which RcppArmadillo brings to R based on our Rcpp library. A minor internal change was the rearrangement of arguments for the (mostly internal) function fastLmPure so that it is closer to the R function lm.fit which it mimics. The user-facing function for fastLm, using either the formula method or the default method, have not changed. The short NEWS file extract follows below. I also include the entry for the bugfix release 0.2.22 (based on Armadillo 1.99.4) which preceded it, and which does not seem to have gotten its own blog post.

0.2.23  2011-05-23
    o   Upgraded to Armadillo release 1.99.5 "v2.0 beta 5"
          * Forms of chol(), eig_sym(), eig_gen(), inv(), lu(), pinv(),
	    princomp(), qr(), solve(), svd(), syl() that do not return a bool
	    indicating success now throw std::runtime_error exceptions when
	    failures are detected 
          * princomp_cov() has been removed; princomp() in conjunction with
	    cov() can be used instead
          * set_log_stream() & get_log_stream() have been replaced by
	    set_stream_err1() & get_stream_err1()
          * det(), inv() and solve() can be forced to use more precise
	    algorithms for tiny matrices (  4x4)
          * Added loading & saving of matrices as CSV text files 
    o   fastLmPure() now uses same argument order as R's lm.fit()
    o   Export and document S3 methods in NAMESPACE and manual page as such
0.2.22  2011-06-06
    o   Upgraded to Armadillo release 1.99.4 "v2.0 beta 4" 
          * fixes for handling of tiny matrices

Courtesy of CRANberries, here is the diff to the previous release.

 RcppArmadillo-0.2.22/RcppArmadillo/inst/include/armadillo_bits/fn_princomp_cov.hpp        only
 RcppArmadillo-0.2.22/RcppArmadillo/inst/include/armadillo_bits/op_princomp_cov_bones.hpp  only
 RcppArmadillo-0.2.22/RcppArmadillo/inst/include/armadillo_bits/op_princomp_cov_meat.hpp   only
 RcppArmadillo-0.2.23/RcppArmadillo/ChangeLog                                                 21
 RcppArmadillo-0.2.23/RcppArmadillo/DESCRIPTION                                               10
 RcppArmadillo-0.2.23/RcppArmadillo/NAMESPACE                                                 14
 RcppArmadillo-0.2.23/RcppArmadillo/R/fastLm.R                                                22
 RcppArmadillo-0.2.23/RcppArmadillo/inst/NEWS                                                 22
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo                                     3
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/Cube_meat.hpp                 12
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/Mat_bones.hpp                  2
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/Mat_meat.hpp                 150 +++-
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/arma_version.hpp               4
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/auxlib_bones.hpp              15
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/auxlib_meat.hpp              352 +++++-----
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/config.hpp                     8
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/debug.hpp                    224 ++++--
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/diskio_bones.hpp              12
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/diskio_meat.hpp              301 +++++++-
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/field_meat.hpp                18
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/fn_chol.hpp                   30
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/fn_eig.hpp                    84 +-
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/fn_inv.hpp                    36 -
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/fn_log_det.hpp                10
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/fn_lu.hpp                     33
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/fn_misc.hpp                   12
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/fn_pinv.hpp                   33
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/fn_princomp.hpp               49 +
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/fn_qr.hpp                     11
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/fn_rank.hpp                   13
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/fn_solve.hpp                  13
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/fn_svd.hpp                    25
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/fn_syl_lyap.hpp               18
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/forward_bones.hpp              3
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/glue_join_meat.hpp            71 +-
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/glue_solve_meat.hpp           13
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/lapack_bones.hpp              95 ++
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_chol_meat.hpp               6
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_inv_bones.hpp               6
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_inv_meat.hpp               39 -
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_max_meat.hpp               50 -
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_median_meat.hpp           115 +--
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_min_meat.hpp               50 -
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_misc_bones.hpp             14
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_misc_meat.hpp              46 -
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_pinv_meat.hpp              39 -
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_princomp_bones.hpp         20
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_princomp_meat.hpp         248 ++-----
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_prod_meat.hpp              34
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_stddev_meat.hpp            38 -
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_sum_meat.hpp               36 -
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/op_var_meat.hpp               38 -
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/running_stat_meat.hpp          4
 RcppArmadillo-0.2.23/RcppArmadillo/inst/include/armadillo_bits/running_stat_vec_meat.hpp      4
 RcppArmadillo-0.2.23/RcppArmadillo/inst/unitTests/runit.fastLm.R                              8
 RcppArmadillo-0.2.23/RcppArmadillo/man/fastLm.Rd                                             32
 RcppArmadillo-0.2.23/RcppArmadillo/src/fastLm.cpp                                            15
 57 files changed, 1695 insertions(+), 886 deletions(-)

More information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

Due to two totally different bugs in tip22 the d-i netinstall images for IP22 (SGI Indy) and IP32 (SGI O2) won't boot the installer correctly. Tip22 is responsible for merging a minimal loader, kernel and initramfs into a single ELF or ECOFF binary, depending on the architecture. This can then be fetched by the machine's ARC PROM via tftp. A fixed tip22 has been uploaded to unstable and updated images are available from here until we can get this fixed via stable-proposed-updates. This blog is flattr enabled.

00:32 < AbsintheSyringe> I'm with one of the users, that registered and he registered as "sponsored" however now he has no category and of course when he tries doing "sponsored" it doesn't work 00:32 < AbsintheSyringe> is this the way it's suppoused to be 00:33 < nattie> who is this? 00:36 < AbsintheSyringe> he's one of the volunteers, he'll be doing everything that has to do with the sound and concerts and so on, regarding concerts and everything else, in real life he's machinist constructor and works as a dj, very popular and good one 00:36 < nattie> that's not the point. we need the name so we can check his penta logs 00:37 < darst> (and not name publically, preferably) 00:37 < AbsintheSyringe> Mirza Alibalic (nickname: masta)

While I'm keenly interested in where mobile phone technology is going, I've never been much for living on the cutting edge of new and expensive phones. I originally wrote Hecl for the humble Nokia 3100, and got a Nokia 6210 classic a few years ago. For the first time in... probably something like 10 years, I got something that wasn't a Nokia: a new Samsung phone with Android. I find it interesting because my own, small purchase appears to very closely mirror a broader trend in the market. Since more or less the day it came out, Android jumped out at me as the place to be for an open source guy like me, and indeed, I'm quite happy with the phone, even though it's towards the low end of the Android range. It does everything I need though - music, GPS, photos, email, Kindle, etc... etc.... To tell the truth, even though it's a cheaper phone (around 140 euros) than the Nokia, it does far more. To some degree, that's of course to be expected, because the Nokia is at this point something like 3 years old, but going from the traditional rocker switch to a touch screen is really a night-and-day difference. Many of you are probably saying "duh" at me and wondering what sort of luddite I am, but like I said, I started hacking on Android when it came out, but it took me a while to finally get one. For a few things like making calls, the Nokia experience is in some ways still superior. It's got 'call' buttons that you can hit and be talking to people in short order, but for most of the rest of the applications and software are just night and day better on the Android phone. Gmail and Maps both strike me as something I could use more readily, rather than the hacky, slow Gmail that ships for Symbian. And of course, with a slightly bigger screen, the web is also a bit better. More than anything, it feels a lot more like a 'system' rather than a very, very solid core phone/sms system with some other junk bolted on.

Sam Hartman is a Debian developer since 2000. He has never taken any sort of official role within Debian (that is besides package maintainer), yet I know him for his very thoughtful contributions to discussions both on mailing lists and IRL during Debconf. Until I met him at Debconf, I didn t know that he was blind, and the first reaction was to be impressed because it must be some tremendous effort to read the volume of information that Debian generates on mailing lists. In truth he s at ease with his computer much like I am although he uses it in a completely different way. Read on to learn more, my questions are in bold, the rest is by Sam. Raphael: Who are you? Sam: I m Sam Hartman. I m a 35-year-old software engineer. I am a principal consultant and co-owner of a small consulting company, called Painless Security. I started using Debian in the mid 1990 s around the time of the bo release. I ended up deciding to join the project as a developer in 2000. Raphael: You re blind and yet you re using your computer as effectively as I am. Can you explain us how you setup your computer ? Sam: I gave a talk at Debconf9 on how my computer is set up; you can watch the video for full details. My main laptop runs Debian. I use the gnome-orca package as my primary screen reader. It speaks the Gnome desktop. It does a relatively good job of speaking Iceweasel/Firefox and Libreoffice. While it does speak gnome-terminal, it s not really good enough at speaking terminal programs that I am comfortable using it. So, I run Emacs with the Emacspeak package. Within that, I run the Emacs terminal emulator, and within that, I tend to run Screen. For added fun, I often run additional instances of Emacs within the inner screens. Raphael: Are there important problems in Debian in terms of accessibility to blind people? KDE documentation talks a lot about accessibility, but at least for blind users, the code completely fails to deliver. That means there are a lot of good packages a blind user cannot use. The non-free Adobe Flash player has some accessibility, but it could be a lot better. The free alternatives have none. The free PDF readers have basically no accessibility. You can use pdftotext, but you cannot actually read a PDF in a graphical application. It s way too easy for a misbehaving program to lock up the entire accessibility infrastructure. Gnash is a big culprit here: if my Iceweasel starts Gnash, there s a good chance that either Iceweasel or the entire desktop will appear to hang from an accessibility standpoint. Other programs, including gksu tend to fail in this way. Some of the more dynamic website features like pop up menus or selection lists are really difficult to find and click without causing them to disappear. This gets better and worse over time as the accessibility support in Iceweasel changes and as websites change. Raphael: What s your biggest achievement within Debian? Sam: I decided to be a Debian developer because I thought that in 2000, Debian support for using enterprise security and infrastructure software was lacking. Back then, any software that included crypto functionality was segregated into a special non-us archive. Some of the software was missing; I started by packaging MIT Kerberos for Debian. Other software had security or enterprise features disabled in the packages. At the height of working on this, I was maintaining krb5, some SASL modules, PAM, some PAM modules,OpenAFS, a version of and Ssh with Kerberos support. I was also involved in the effort to resolve the legal issues so that we could move security software into the main archive. I think this work has been a huge success. In fact, it s been such a success that other people are now doing most of the work. I still maintain the krb5 package. When I started I felt like I was pushing against the flow trying to get people to add patches, sometimes even having to fork a package. However, now, I can maintain just one component and there are enough others who shared my original goal that the work continues. These days, I m working on something that s an evolution of this enterprise security work. I m packaging Project Moonshot for Debian and Ubuntu. Project Moonshot is a response to the wide variety of identity management systems such as OpenID, Oauth, SAML, and the like. Moonshot works to create an identity management approach that works well both for the web and for client-server and other applications. The project is a lot of fun, but the role of Debian in the project is also interesting. One of the things we want to show with Moonshot is how our technology can be effective when it is integrated throughout a platform. To really show the potential it needs to work with as many applications in a given platform as possible. The open and collaborative nature of the Debian community makes it possible to introduce a new technology and have that technology evaluated based on its merits. We don t need huge business relationships or marketing deals to integrate our technology: we need some combination of doing the work ourselves and showing others the benefits of working with us. For someone trying to do innovative work, the Debian model is powerful. Raphael: If you could spend all your time on Debian, what would you work on? Sam: I d really love to work with the embedded Debian folks. The vision of a single source base that could be the stack from devices from small embedded devices all the way up to high-end servers is very appealing. Doing that with Debian involves a number of challenges. However with the right people working on meeting these challenges full-time, I think we could offer something promising. I d also love to have the time to contribute to project infrastructure: working on the release team, helping ftpmaster, that sort of thing. However I don t. I m just happy that so much of my consulting practice involves working on open-source software. Raphael: What s the biggest problem of Debian? Sam: There s something really not right about how we transition libraries from unstable to testing. Every time I get involved in a library transition I m shocked at how complicated it is and how disruptive it is both to testing and unstable. We need to look at technology and processes to break up the dependency snarles. For example we don t have good archive tools for keeping old versions of libraries around to ease transitions. If you haven t thought about this issue you ll probably say that I m being overly picky and this can t be the major problem for Debian. However, if you think about how much this impacts our ability to introduce things into unstable around the times of the freeze or about how much it slows the release process, you may begin to appreciate how big of an issue this is. Raphael: Is there someone in Debian that you admire for their contributions? Sam: There are a number of people who have been role models for me over the years. Anthony Towns really helped me understand a lot of what drives free-software projects and what needs to be true for positive motivation. Joey Hess showed us all that sometimes, social problems do have technical solutions. If the tools are so good that doing the right thing is far easier than any other course of action, quality improves.

---

Thank you to Sam for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

5 comments Liked this article? Click here. My blog is Flattr-enabled.

My DebConf trip will involve 7 days of travel spanning ten countries, plus the conference. I'll be part of a three car convoy, all across Europe to B&H, with a bunch of speed-loving brits. I'm sure there will be many references to Top Gear, and probably some multicar wifi. Luckily I'm prepared, since Overfiend (aka Debian's own Stig) introduced me to the show two years ago. This will be a great way to see a lot of Europe, fast, and for pretty cheap all told, even with the hotel in Luxembourg. I'm sure DebConf 11 will spark a lot more ideas of things to do. For that matter, I still have todo items leftover from Debconf 10. I'm not planning to give any talks, but who knows?

If you've been following new releases you'll see there is a new Firefox browser out, version 5.0. This will almost certainly make its way into Debian's experimental tree soon, but that doesn't help users of the Debian Stable release. The only sane option for those users (such as myself), without a backport, is to install locally. So I did the obvious thing, I made /opt/firefox then installed the binary release into it. Then I found that it was good, lovely and fast. Unfortunately the system firefox and the local firefox are not really compatible. Run the local one, then click on a link in the gnome terminal and it wants to open the system one. Ho hum. The solution:

• Remove your local firefox & iceweasel packages.
• Create the shell scripts /usr/bin/firefox & /usr/bin/iceweasel to exec the one stored beneath /opt.
• Rejoice.

Of course this being Debian we don't want to do that. So instead here is a package that will let you do that:

• http://firefox.repository.steve.org.uk/file

Download. Build. Install. If you install your local package to a location different than /opt/firefox update the configuration file /etc/firefox/firefox.conf to point to it. Possibly useful? ObQuote: "I could help you cross your yard." - Up

I finally got around to book my (train) trip back from Zagreb. The hotline of Deutsche Bahn was interesting. The booking system crashed and I was called back. But in the end it worked and I can print it the next time I get near a vending machine.

I'm worried how I manage to get there from Banja Luka on my own. And the travel to Zagreb together with Joachim Breitner won't be as comfortable as it should be. But meh, I'm going to DebConf again! \o/

I read something about dh_make again a while ago, which made me wonder, besides dh_make, how do people generally bootstrap new Debian packages. I don't think I've ever actually used dh_make for anything but experimenting. For the longest time, copying over the packaging files from some similar package worked pretty well.

Recently, however, I have applied a completely new strategy: I start with nothing, call debuild, fix the error, retry, until it works. This might sound pretty bizarre, but it works pretty well and enhances your understanding of how the packaging tools work.

Here is about how it works:

Start with nothing, call debuild, it complains:

cannot find readable debian/changelog anywhere!

Call dch --create, which says:

Cannot find debian directory!

OK, mkdir debian, call dch --create again, fill in the template. Call debuild again, now it says:

but there's no debian/rules there!

Create a debian/rules, that's easy to do by heart nowadays, at least as a start:

#!/usr/bin/make -f

%:
        dh $@

Call debuild again, now dpkg-buildpackage actually starts, but stops with:

dpkg-source: error: cannot read mypackage/debian/control: No such file or directory

At this point I'm too lazy to figure out what is necessary to put into debian/control, so let's just keep it simple and touch debian/control. At this point dpkg-source gets into a bit of trouble:

Use of uninitialized value $sourcepackage in sprintf at /usr/bin/dpkg-source line 290.

So let's put that in and also follow the subsequent advice to add debian/source/format and the Maintainer and Standards-Version fields. So far we have:

Source: mypackage
Maintainer: Peter Eisentraut <petere@debian.org>
Standards-Version: 3.9.2

The next hint of a message is:

dh: No packages to build.

This means we need a binary package stanza, so I'll just add

Package: mypackage
Architecture: any

Now debhelper complains:

dh: Compatibility levels before 5 are deprecated.

Not sure why it didn't complain about that earlier. Let's stick 8 in there.

At this point I had to do actual work and mess around with debian/rules a bit to get the package to actually build, but a few minutes later I had a functioning provisional package.

The next step is to clean up the warnings from the various dpkg-* workers:

dpkg-gencontrol: warning: missing information for output field Description
dpkg-gencontrol: warning: package mypackage: unused substitution variable $ shlibs:Depends 
dpkg-deb: warning: parsing file 'debian/mypackage/DEBIAN/control' near line 6 package 'mypackage': missing description
dpkg-genchanges: warning: missing Section for binary package mypackage; using '-'
dpkg-genchanges: warning: missing Priority for binary package mypackage; using '-'
dpkg-genchanges: warning: missing Section for source files
dpkg-genchanges: warning: missing Priority for source files

So we add Description, Depends, Section, and Priority.

And finally we have a list of complaints from Lintian to address:

W: mypackage source: debhelper-but-no-misc-depends mypackage
E: mypackage source: package-uses-debhelper-but-lacks-build-depends
W: mypackage source: package-needs-versioned-debhelper-build-depends 8
W: mypackage source: debhelper-overrides-need-versioned-build-depends (>= 7.0.50~)
E: mypackage source: temporary-debhelper-file debhelper.log
E: mypackage: no-copyright-file

The only things I added manually after that were Vcs-*, Homepage, and Enhances.

Now the only things left to do are running the thing through cowbuilder a few times and putting in all the necessary build dependencies, and writing a nice changelog entry.

Note, this method does not replace putting in some thought. But it's an interesting way to get a relatively clean package.

So I got my hands on that new machine, somewhere, somehow, and I had to make myself comfortable on it. The biggest difference in that machine and the ones I used before is the RAID controller, an Adaptec 5405, instead of the 3ware ones I used to have before. That means getting used to new tools, messages and all these things which I ll try to document here.Step 1: does vendor deliver?Well, yes, mostly. There is (mainline) kernel support for the controller, Squeeze s kernel will boot up just fine and I just throw my junk into /dev/sda and it will handle the whole raidy thingy itself. But what is when I want to check the health of the disks, to add a spare or modify the caching? Ask the mighty vendor and it will answer Yes, you can! .So I downloaded that asm_debian_x86_x64_v6_50_18570.tgz, unpacked and faced two debs, one i368 and one amd64. Yes, you could have saved half of the bandwidth if someone would have asked for the arch before, but who cares for some additional 60MiB today? So let s see what it does. Oh no, wait, there is a README ASM_IUG_for_Debian_and_Ubuntu.txt:

1. Make sure to be in root level access.
2. Install the ASM storman .deb package. For example, if the package is storman_6.50-18570_i386.deb,
   then install it using the following command dpkg -i storman_6.50-18570_i386.deb
3. Adaptec Storage Manager will get installed at /usr/StorMan
4. Add the line /usr/StorMan to /etc/ld.so.conf. Then run "ldconfig". This is needed for the arcconf
   utility to find the path of the libstdc++.so.5 library

Well, 1 is obvious, so is 2.
For 3: hum, /usr/StorMan? Ever heard of FHS? Don t think so.
For 4: WTF?! I prefer to get libstdc++5 from my local Debian mirror instead.But at least they provide a .deb, right? Uhm, no, it s an RPM converted via alien :( And don t dare to look at preinst, postinst and postrm (it extracts an own copy of Sun JRE 1.6u16, chmods around wildly on install and does rm -rf something on uninstall, did I see that some days ago on the webs?). Let s get rid of that package as soon as possible, I decided, and just keep arcconf (which will be described later), esp because StorMan itself seems to include some call-home functionality which I d like not to have:

cp -a /usr/StorMan/arcconf /usr/local/sbin/
apt-get remove --purge storman

Step 2: does community deliver?You can, by the way, get (better) packages at http://hwraid.le-vert.net/wiki/DebianPackages from Adam C cile (Le_Vert). I didn t test those much, but I currently use the arcconf package from there, which seems to be exactly what I need: proper dependencies and just the arcconf binary, no Java sh*t.Step 3: monitor the controllerAs this post is about monitoring, not ranting, let s continue. As mentioned before, I only have arcconf installed, which is just a cli to do stuff with the controller. If I understood the docs right, the actual StorMan is able to send notification mails when a disk dies or the controller gets eaten by aliens, but as I don t have StorMan, I have to do things myself.Adam has a aacraid-status package in his repository, which includes some minimalistic shell-daemon to monitor the output of arcconf. It didn t perfectly fit my needs (and had some hickups with my disks which refuse to report a vendor, whyever), so I decided to write something myself (slightly based on what Adam has done in aacraid-status, though).The result is on GitHub: https://github.com/evgeni/aacraidAs you can see the code contains (at the time of writing) exactly ZERO comments and there is no README either, but it s actually quite usable already.

• aacraid.py is the main magic inspired by Adam s aacraid-status, basically just parsing arcconf output
• aacraid-status prints all useful info about all controllers, arrays and disks (the output is pretty much like Adam s)
• aacraidd is a small daemon which will monitor all controllers every (per default) 5 minutes and mail you in case of status-change

I am now running aacraidd and get happy mails when something breaks :) [running = running from /etc/rc.local, no init script yet :)]Step 4: monitor the disks via smartmontoolsThere is one little problem I have with arcconf: it s closed source and does magic to the controller.With the old 3ware controller I was able to monitor the disks with smartmontools/smartd using something like this:

/dev/twa0 -d 3ware,0 -a -s L/../../2/01 -m root
/dev/twa0 -d 3ware,1 -a -s L/../../2/03

This is possible with Adaptect controllers too (not through /dev/twaX obviously). You have to have the sg module loaded, which will result in /dev/sg[012] on my machine, with sg0 being the controller itself and sg1/sg2 the both disks attached to it. Having sg loaded, one can now use smartd with:

/dev/sg1 -d sat -a -s L/../../7/01 -m root
/dev/sg2 -d sat -a -s L/../../7/02 -m root

(-d sat is the important option here!)Thanks to Thomas Krenn Wiki: Smartmontools mit Adaptec RAID Controller for the basic info and ostlogd.spenneberg.net: Adaptec-Raid-Controller S.M.A.R.T.-Healthstatus monitoren for the pointer to the sg module!Step 5: relaxYupp, 4 steps are enough, go relax until the next disk dies (you will be doing something REALLY important that moment according to Murphy).

0 comment(s) this blog is flattr enabled