require("utils-grep")
local intel = grep_program_output("VGA.*Intel","lspci")
file.file( "/tmp/garbage" ,  
    ensure = "present",
    owner = "root",
    group = "root",
    mode = "755",
    source = file.cosmotemplate("/tmp/silly.cosmo", intel)
 )

# On $systeminfo hostname, we might have used the following information
# to populate this config file.
#
# We did not.
$map $v 1 [[# $it]]

• a seminal conversation on identi.ca
• a couple of blog posts by Lars, discussing the general problem of how to use TDD in distribution development and to a lesser extent its instantiation to Debian
• a separate post by Daniel stressing the specific TDD advantage of increasing the confidence of maintainers in making far reaching changes

• Build time package testing. Several packages run their build-time test suites during package build. This aspect is somewhat supported by the Debian policy; we also do a best effort attempt to run build-time test suites via debhelper (starting from version 7). At the same time we could probably campaign more to encourage maintainers to look for build-time test suites which do not follow common Makefile target naming or, fwiw, which don't rely on make at all. TodoList.add("investigate and possibly file bug report against policy to encourage maintainers to run build-time test suites")
TodoList.add("investigate and possibly file bug report against lintian to spot the presence of [non-invoked] build-time test suites")
• Runtime package testing (AKA "as-installed package testing"). Some kinds of test-suites are difficult to run at build-time (e.g. complex applications that don't offer easy way to re-configure on the fly their filesystem paths) and some others are plainly impossible to run without having the packages to be tested properly setup (e.g. running services that are accessible only through the network) or an isolated, throw-away testbed (e.g. bootloaders, kernels, etc.). TTBOMK this kind of testing is not currently in use neither in Debian nor, indirectly, in any of its derivatives. autopkgtest (AKA DEP8) is a step in this direction; I will get back to it later on in this post.
• Integration testing. When applied in the context of distributions, integration testing is about testing package combinations, task (as in tasksel) combinations, basic system functionalities, automated installations, etc. This is the aspect that Lars has discussed the most (and in which he seems to be interested the most) so I don't feel like adding much. Still, it's interesting to note that on this front Debian has an important potential to exploit. The large base of its developers and the fact that the average Debian user is technical savvy mean that we can potentially collect a lot of test cases. It's "just" (with well-deserved double quotes) a matter of deciding a standard interface for test case submissions and developing a most likely virtualized test runner. At that point a continuous integration service that periodically run and publishes results can be setup independently from the rest of the Debian infrastructure and offered to interested eyes, such as Release Team's. Any taker?
• Automated code analysis and in particular automated bug finding is something which is becoming more and more common and finally, after decades of research viable. Successful proprietary tools and businesses are aplenty (a nice and very fun read on the subject is the story of Coverity), as well as FOSS solutions. For instance, the Linux kernel is routinely using Coccinelle to automatically find bugs and even produce the corresponding patches. Add to the above the fact that Debian is one of the largest software collection in existence (and quite probably the largest collection of Free software in existence) and is upstream of the packaging of that software for the most part. That turns Debian into a very peculiar platform for large scale automated code analyses. Not that we can aim at fixing all the bugs we are going to find, or even hope to tame all the false positives we are going to find. But we can offer an important service to the whole ecosystem of Free software and use it to pinpoint important class of bugs from a distribution point of view, such as nasty security bugs (as long as they can be automatically found ). DACA is a very good step in the right direction, even though it is still in its infancy.

1. README.package-tests provides a standard format to declare per-package tests using the new debian/tests/control file. Tests come as executable files which will be run by the adt-run tool in a testbed where the package(s) to be tested is already installed. This part of the specs has been reified as DEP8 which I'm (supposedly) co-driving with Iustin Pop and Ian (for well-deserved credits).
2. README.virtualisation-sever describes the interface among the test runner and the testbed. A nice separation is provided among the runner and the testbed, enabling different testbed environments with a varying degree of isolation: you can have a "null" testbed which runs tests on your real machines (needless to say, this is highly discouraged, but is provided by the adt-virt-null tool), a chroot testbed (adt-chroot), or a XEN/LVM based testbed (adt-virt-xenlvm).

• The usage of python-apt needs to be ported to recent API, as several used methods and attributes are now gone.
• Porting from dchroot to schroot is needed for the adt-virt-chroot backend.
• A kvm backend for the test runner would be nice.

% ssh root@192.168.2.15
root@192.168.2.15's password: 
BusyBox v1.19.0.git (Maemo 3:1.19-7+0m6) built-in shell (ash)
Enter 'help' for a list of built-in commands.
RM680-22-6_PR_RM680:~# cat /proc/cpuinfo 
Processor       : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 298.32
Features        : swp half thumb fastmult vfp edsp neon vfpv3 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc08
CPU revision    : 2
Hardware        : Nokia RM-680 board
Revision        : 1124
Serial          : 0000000000000000
SoC Info        : OMAP3630 ES1.2-hs
        IDCODE  : 2b89102f
        Pr. ID  : 00000000 00000000 000000cc cafeb891
RM680-22-6_PR_RM680:~# uname -a
Linux RM680 2.6.32.39-dfl61-20112201 #1 PREEMPT Wed Jun 1 18:17:45 EEST 2011 armv7l GNU/Linux
RM680-22-6_PR_RM680:~# dpkg --version   head -n 1
Debian  dpkg' package management program version 1.15.8.8 (armel).
RM680-22-6_PR_RM680:~# apt-get --version   head -n 1
apt 0.7.25.3 for armel compiled on Mar 28 2011 23:31:47

1. Install pbuilder with your favourite package manager, e.g. aptitude: aptitude install pbuilder
2. Become root
3. Configure pbuilder. Have a look at /etc/pbuilderrc, /usr/share/doc/pbuilder/examples/pbuilderrc and the manual page for pbuilderrc for reference. If you want to change some settings made in /etc/pbuilderrc, create a /root/.pbuilderrc and override any settings you don't like.
4. Create the base.tgz (the chroot environment for your builds). In the easiest case all your settings are made in the configuration files and you just need to run pbuilder --create, which creates the base.tgz in /var/cache/pbuilder, unless you changed the configuration.
   You should also note, that you can override certain settings, like the distribution or the path to (and name of) the base.tgz file created. See the manual page for pbuilder for all options and when they can be used.

1. Download the source package, you want to build. No matter how you fetch them (dget, apt-get source, ), you should end up with three files, one of them ending in .dsc.
2. Become root.
3. Update your base.tgz file: pbuilder --update. Again, see the manual page for further options. (You can skip this step, if you just created the base.tgz or you just updated it for another build.)
4. Build the source package: run pbuilder --build /path/to/source-package.dsc (obviously you need to replace the last argument with a real path)
5. If you haven't changed the configuration of pbuilder in that regard, then your binaries end up in /var/cache/pbuilder/result. Install the binaries, you want, from there (with dpkg -i).

• New Maintainer: I helped a lot of people join Debian. It s great to help someone join the project and then see how they contribute. Of course, some people join Debian and then quickly become inactive or retire you never know in advance how it will work out. But I had the pleasure to help some truly outstanding contributors to join Debian.
• Quality Assurance: I helped improve QA processes within Debian. In particular, I realized a few years ago that a lot of packages had maintainers who were inactive and that nobody did anything about it. I started to write to those maintainers to see what could be done. It s hard because you don t know the circumstance of someone they may be inactive because of an illness or for other good reasons so you have to be friendly, but yet persistent. Fortunately, most maintainers I contacted were truly inactive and so they couldn t complain when I took their packages away.
• DPL: I acted as the Debian Project Leader for two years. I m particularly proud of this because Debian is a great project and it was an honour to represent it. I performed important organizational and coordination tasks. I also traveled to a lot of conferences and had the pleasure to meet many Debian Developers as well as users of Debian. It s very motivating to meet users and to hear how they use Debian and how we can further improve it.
• Debian on NAS: Debian is without the doubt the Linux distro with the best support for NAS (Network Attached Storage) devices. I was always impressed by what the OpenWRT folks have done to support wireless routers and wanted to do something similar for Debian. Unfortunately, wireless routers just don t have enough storage for a full distro. But then NAS devices came along and they obviously have enough space since they are meant for storage.

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

• Port ghc to armhf
• Fix u-boot so u-boot-tools once again builds on all architectures
• i18n:izing paprass
• Getting lambdabot into better shape
• Adding DuckDuckGo as a search engine option on my phone

1. Total distance travelled: 1466.8 km
2. Average driving speed: 95.9 km/h [0]
3. Total number of kilometers wasted on 'oh, crap, we forgot something': 10 (approx) [1][2]
4. Total amount of fuel used: 81.3l
5. Average fuel consumption rate: 5.5l/100km [3]
6. Total amount of kilometers spent behind the wheel by Jeremy: 50 (approx)
7. Total amount of kilometers spent behind the wheel by Wouter: the rest.[4]
8. Time of departure: 2011-07-16 21:00
9. Time of departure after point three and making sure we had everything: 2011-07-16 22:00
10. Time of arrival: 2011-07-17 15:15 (approx) [5]
11. Outside temperature at departure: 12 celcius
12. Outside temperature at arrival: 35 celcius
13. Longest (voluntary) break: 1 hour (approx; breakfast, tanking, bathroom visit, watching the sun rise)
14. Longest (involuntary) break: 45 minutes (approx; customs check) [6]
15. Last fueling stop: 4 AM.
16. Amount of kilometers left to go before the car said bleep, you need to tank soon: less than one.
17. Most tense moment: on crossing the slovenia->croatia border, confusing the border police officer ("no, I'm Wouter, that is Jeremy" yes, we both had photo-ID), who then promptly holds on to our documents, asks the car's papers, and tells us to please park over there and wait a moment while he gets us to be handled by guy in a somewhat more military-looking uniform.[7]
18. Biggest "uh-oh" moment: after crossing the croatia->bosnia and herzegovina border, watching the very, very, very, very, very[8] long line of trucks queueing to cross the border. In the other direction. And then realizing that you probably need to go through that very same queue on the way back
19. Largest single toll fee: 15 [9]
20. Last bit of time spent asleep before this trip: the minutes surrounding 2011-07-16 05:00:00 [10]
21. Time wasted writing this blog post when I really should've gone to bed instead: 45 minutes
22. Time now: 21:02:54

       Size  Used Avail Use% 
before 5.4T  2.6T  2.6T  51% 
after  5.4T  892G  4.3T  18% 

          Inodes    IUsed     IFree IUse%
before 732577792 77645915 654931877   11%
after  732577792 16871789 715706003    3%

Kai, thanks for your vimrc lines:

	:highlight TrailWhitespace ctermbg=red guibg=red
	:match TrailWhitespace /\s\+$\  \+\ze\t/
 

Automatic removal is harmful, though I just fell into the trap since jupprc contains needed whitespace at EOL but manual removal (bound to ^K] in jupp) rocks. And I like that your solution uses such strong a colour vim users are the single most represented offender group for actually leaving the redundant whitespace at EOL there, and it should hurt their eyes. (Sadly there is some vehement disagreement preventing them from inclusion in grml-etc-core but that s why I re-post them here.) Ah, and jupp can of course display whitespace visibly (although it uses / , replacing the arrow with if no UTF-8, not ), accessible with ^Ov. Steve, want to put up a checklist for sites? We can crowdsource the testing to maybe get some interesting results Some other people would get more comments if they were idling in IRC (Freenode) or allow comments on their blog, specifically without too high an entrance barrier OpenID is ok, but many other things, and ECMAscript, are not; but I can t really say that loud because our wlog is static HTML compiled from a flat plaintext data source so it doesn t allow such either. I often forget what I wanted to add if I can t get it out quickly enough (especially at work). Sowwy Me like the cat picture postings (Amayita, Tiago, Gracias!).

• For pure HA, replicate at the disk level using DRBD. You lose some of the supposed benefits of MySQL replication ( you can do dump backups off the slave! Woooooo! ), but you at least get consistency.
• If you think you need a harem¹ for load purposes, use some other way of scaling MySQL that doesn t involve throwing an update to an amorphous blob of servers and hoping it sticks in the right places. Sharding can work, as can aggressive caching (intelligent storage of precalculated query results in memcached can work wonders) or just buying a bigger machine.
• If you want to do anything fancy (my tree-replication scheme falls into this category), just don t. MySQL replication isn t the answer to these sorts of situations, it s the question. The answer is No! .

• Optimising your queries;
• Optimising your MySQL configuration;
• Using a k/v store for really non-relational data (sessions, I m looking at you)
• Sharding your data

f(x,y) = k x^2 exp( -x y^2 - y^2 + 2y - 4x)

f(x y) = (x^2)*exp(-x*(4+y*y))               ## a Gamma density kernel
f(y x) = exp(-0.5*2*(x+1)*(y^2 - 2*y/(x+1))  ## a Gaussian kernel

## Here is the actual Gibbs Sampler
## This is Darren Wilkinsons R code (with the corrected variance)
## But we are returning only his columns 2 and 3 as the 1:N sequence
## is never used below
Rgibbs <- function(N,thin)  
    mat <- matrix(0,ncol=2,nrow=N)
    x <- 0
    y <- 0
    for (i in 1:N)  
        for (j in 1:thin)  
            x <- rgamma(1,3,y*y+4)
            y <- rnorm(1,1/(x+1),1/sqrt(2*(x+1)))
         
        mat[i,] <- c(x,y)
     
    mat
 

## We can also try the R compiler on this R function
RCgibbs <- cmpfun(Rgibbs)

## Now for the Rcpp version -- Notice how easy it is to code up!
gibbscode <- '

  using namespace Rcpp;   // inline does that for us already
  // n and thin are SEXPs which the Rcpp::as function maps to C++ vars
  int N   = as<int>(n);
  int thn = as<int>(thin);
  int i,j;
  NumericMatrix mat(N, 2);
  RNGScope scope;         // Initialize Random number generator
  // The rest of the code follows the R version
  double x=0, y=0;
  for (i=0; i<N; i++)  
    for (j=0; j<thn; j++)  
      x = ::Rf_rgamma(3.0,1.0/(y*y+4));
      y = ::Rf_rnorm(1.0/(x+1),1.0/sqrt(2*x+2));
     
    mat(i,0) = x;
    mat(i,1) = y;
   
  return mat;             // Return to R
'
# Compile and Load
RcppGibbs <- cxxfunction(signature(n="int", thin = "int"),
                         gibbscode, plugin="Rcpp")

gslgibbsincl <- '
  #include <gsl/gsl_rng.h>
  #include <gsl/gsl_randist.h>
  using namespace Rcpp;  // just to be explicit
'
gslgibbscode <- '
  int N = as<int>(ns);
  int thin = as<int>(thns);
  int i, j;
  gsl_rng *r = gsl_rng_alloc(gsl_rng_mt19937);
  double x=0, y=0;
  NumericMatrix mat(N, 2);
  for (i=0; i<N; i++)  
    for (j=0; j<thin; j++)  
      x = gsl_ran_gamma(r,3.0,1.0/(y*y+4));
      y = 1.0/(x+1)+gsl_ran_gaussian(r,1.0/sqrt(2*x+2));
     
    mat(i,0) = x;
    mat(i,1) = y;
   
  gsl_rng_free(r);
  return mat;           // Return to R
'
## Compile and Load
GSLGibbs <- cxxfunction(signature(ns="int", thns = "int"),
                        body=gslgibbscode, includes=gslgibbsincl,
                        plugin="RcppGSL")

edd@max:~/svn/rcpp/pkg/Rcpp/inst/examples/RcppGibbs$ r RcppGibbs.R
Replication # 1 complete 
Replication # 2 complete 
Replication # 3 complete 
Replication # 4 complete 
                    N=1000 N=5000 N=10000 N=20000
Elasped Time (R)     0.124  2.650  10.511  41.773
Elasped Time (RC)    0.081  1.916   7.594  30.280
Elapsed Time (Rcpp)  0.003  0.076   0.306   1.221
Elapsed Time (Rgsl)  0.002  0.049   0.196   0.784
SpeedUp Rcomp.       1.530  1.380   1.380   1.380
SpeedUp Rcpp        41.330 34.870  34.350  34.210
SpeedUp GSL         62.000 54.080  53.630  53.280
               test replications elapsed  relative user.self sys.self
4  GSLGibbs(N, thn)           10   7.845  1.000000      7.84        0
3 RcppGibbs(N, thn)           10  12.218  1.557425     12.22        0
2   RCgibbs(N, thn)           10 312.296 39.808286    311.98        0
1    Rgibbs(N, thn)           10 420.953 53.658764    420.59        0

Updated 2011-07-16: Darren has just updated his comparison; fixed two typos here too.