I ve spent some time thinking about how to properly audit packages for common mistakes. As part of this problem is how to store the issues found. All the tools I care about have different output formats, and I hate the idea of writing so many adapters for all the tools into some sort of common format. Has anyone come across this issue before? Anyone working on something similar?

I recently worked on the following RC bugs:

• #691125 ejabberd: package installation creates /root/.erlang.cookie
  I tracked down the cause of this and provided a patch. Now I also know how piuparts works in detail :-).
• #691180 connman: Connman won't run due to missing libxtables.so.7
  Since this bug does not affect testing and it doesn t look like iptables 1.4.16.3-1 (a new upstream release) will go into wheezy (no freeze unblock filed), I tagged this with wheezy-ignore. I hope this was right, if not, feel free to correct me.
• #684645 liblockfile1: Order of fcntl and dotlock in maillock
  I identified the piece of code which does locking the wrong way. Since I m not familiar enough with either sendmail or NFS-safe locking, I did not send a patch. In case you have experience with this, please have a look!

mbiebl has recently uploaded systemd 44-5 to Debian unstable. If you are already using systemd, you should definitely upgrade to this version, it fixes a lot of little annoyances. This is especially important if you are using libvirt >= 0.10.2-4 or if you experienced a hanging boot when your network cable is attached.

I work at the University of Oslo looking after the computers, mostly on the unix side, but in general all over the place. I am also a member (and currently leader) of the NUUG association, which in turn make me a member of USENIX. NUUG is an member organisation for us in Norway interested in free software, open standards and unix like operating systems, and USENIX is a US based member organisation with similar targets. And thanks to these memberships, I get all issues of the great USENIX magazine ;login: in the mail several times a year. The magazine is great, and I read most of it every time. In the last issue of the USENIX magazine ;login:, there is an article by Stuart Kendrick from Fred Hutchinson Cancer Research Center titled "What Takes Us Down" (longer version also available from his own site), where he report what he found when he processed the outage reports (both planned and unplanned) from the last twelve years and classified them according to cause, time of day, etc etc. The article is a good read to get some empirical data on what kind of problems affect a data centre, but what really inspired me was the kind of reporting they had put in place since 2000. The centre set up a mailing list, and started to send fairly standardised messages to this list when a outage was planned or when it already occurred, to announce the plan and get feedback on the assumtions on scope and user impact. Here is the two example from the article: First the unplanned outage:

Subject:     Exchange 2003 Cluster Issues
Severity:    Critical (Unplanned)
Start: 	     Monday, May 7, 2012, 11:58
End: 	     Monday, May 7, 2012, 12:38
Duration:    40 minutes
Scope:	     Exchange 2003
Description: The HTTPS service on the Exchange cluster crashed, triggering
             a cluster failover.
User Impact: During this period, all Exchange users were unable to
             access e-mail. Zimbra users were unaffected.
Technician:  [xxx]

Next the planned outage:

Subject:     H Building Switch Upgrades
Severity:    Major (Planned)
Start:	     Saturday, June 16, 2012, 06:00
End:	     Saturday, June 16, 2012, 16:00
Duration:    10 hours
Scope:	     H2 Transport
Description: Currently, Catalyst 4006s provide 10/100 Ethernet to end-
	     stations. We will replace these with newer Catalyst
	     4510s.
User Impact: All users on H2 will be isolated from the network during
     	     this work. Afterward, they will have gigabit
     	     connectivity.
Technician:  [xxx]

He notes in his article that the date formats and other fields have been a bit too free form to make it easy to automatically process them into a database for further analysis, and I would have used ISO 8601 dates myself to make it easier to process (in other words I would ask people to write '2012-06-16 06:00 +0000' instead of the start time format listed above). There are also other issues with the format that could be improved, read the article for the details. I find the idea of standardising outage messages seem to be such a good idea that I would like to get it implemented here at the university too. We do register planned changes and outages in a calendar, and report the to a mailing list, but we do not do so in a structured format and there is not a report to the same location for unplanned outages. Perhaps something for other sites to consider too?

I've just finished deploying automatic installability checking for Ubuntu's development release, which is more or less equivalent to the way that uploads are promoted from Debian unstable to testing. See my ubuntu-devel post and my ubuntu-devel-announce post for details. This now means that we'll be opening the archive for general development once glibc 2.16 packages are ready. I'm very excited about this because it's something I've wanted to do for a long, long time. In fact, back in 2004 when I had my very first telephone conversation with a certain spaceman about this crazy Debian-based project he wanted me to work on, I remember talking about Debian's testing migration system and some ways I thought it could be improved. I don't remember the details of that conversation any more and what I just deployed may well bear very little resemblance to it, but it should transform the extent to which our development release is continuously usable. The next step is to hook in autopkgtest results. This will allow us to do a degree of automatic testing of reverse-dependencies when we upgrade low-level libraries.

Seven years ago I wrote a quick ruby script called dsafilter which would verify the PGP signature on a Debian Security Advisory (DSA), determine which source package was mentioned in the mail, establish which binary packages are built from that source package and see whether any of them were installed on the current host. Future plans included ways of checking package lists for multiple hosts. Recently I had an enquiry about the script. I hadn't realised that the code had disappeared off the face of the web. I've now reinstated it and uploaded it to github. Hopefully people may find it useful!

• dsafilter

I ve been a wannabe GTD afficionado for some years. I ve wanted to do it, but managing lists has always been something that has too much friction, overhead, or whatever. Finally, though, I think I might have found a way to manage lists that works. My use-case isn t unique, although I will concede I m perhaps being more dogmatic than most. I want something that:

• Is electronic (yes, the hipster PDA is a cool idea, but my handwriting is beyond woeful and I already carry enough crap in my pockets as it is);
• Works offline (because I often do);
• Will work on both my phone and laptop (because I want to have my lists with me when I m not at my computer, but long-form data entry or manipulation on a phone is painful);
• Makes it easy to add, browse, modify, and above all remove items; and
• Is mine (no central databases I don t control, proprietary apps on my phone, etc).

My previous attempt was a tool I called tagnote it was a vim-outliner file full of hierarchically organised outliner entries, with tags inlined. It was a neat idea, but it wasn t smooth to add/browse/delete items, and didn t work with my phone at all (trying to use vim for any length of time on a bottom-of-the-range Android phone would kill me). The current iteration, as the title of this post suggests, is a list manager that entirely uses e-mail. It really is a perfect symbiosis:

• I want lists of text items with titles (Subject:), potentially other metadata (X-Whatever headers), and possibly some notes (the body of the e-mail);
• I need to be able to browse and remove completed items (that s what e-mail clients are for);
• Getting new items into the system is trivial (Anything I send to my PDA s e-mail address goes straight into the INBOX, which I can then process as time permits); and
• Syncing between my laptop and PDA is as simple as offlineimap and K-9 mail.

So what have I got, exactly? It s fairly straightforward:

• An IMAP account on my existing mail server;
• A slightly tweaked copy of mutt (different colours so I don t confuse myself, and a different layout of the index page to get rid of unnecessary columns);
• Another offlineimap account;
• Another K-9 mail account;
• Note2self (a neat little app to take a typed or voice-transcribed note and e-mail it to a pre-set address) on the phone, pre-programmed to e-mail any notes I write to the PDA s inbox; and
• A small shell script to make it trivial to create new lists (which has to be done on the IMAP server for reasons of offlineimap), add new items to a list, sync my lists (in other words, run offlineimap ), display my lists (in other words, run mutt ), and process my tickler file.

That last point is the one I m really happy I achieved. I ve always been a fan of hide it until you need it , but my previous system didn t let me do that. Now, though, I have a separate list called tickler, and all the items in there have an X-Tickle header, which specifies the date I want to see them. Each night a cronjob runs through the tickler and moves anything for today into the INBOX. An X-Tickle-Repeat header lets me have things that repeat over and over again. So in short, using entirely open-source tools and a couple of hours of my time doing things I enjoy anyway (shell scripts! woo!), I ve now got a list manager that doesn t get in my way more than it absolutely has to. We ll see how long I last this time before I feel the urge to improve my lists again.

Review: Fables: Legends in Exile, by Bill Willingham, et al.

Series:	Fables #1
Penciller:	Lan Medina
Inker:	Steve Leialoha
Inker:	Craig Hamilton
Colorist:	Sherilyn van Valkenburgh
Letterer:	Todd Klein
Publisher:	Vertigo
Copyright:	2002
ISBN:	1-56389-942-6
Format:	Graphic novel
Pages:	127

The characters of human fairy tales are all real. Real, but hidden: they have been driven from their ancestral homelands by some force referred to here only as the Adversary, and have fled to the mundane world to escape his notice. Specifically, New York, where those characters who can pass as human blend into the streets of New York City, and those who can't (referred to only in passing in this story arc apart from one pig) stay at a farm upstate. That's the brilliant premise of Fables, an ongoing comic series from Vertigo that's up to 121 issues plus numerous spinoffs as of this writing. This is the first trade paperback, collecting issues 1 through 5 plus a prose story. Legends in Exile is, in underlying form, a murder mystery. It opens with Jack reporting a murder to Bigby Wolf, who is what passes for law enforcement among the Fables. Rose Red's apartment has been discovered covered in blood, and her body is missing. "No more happily ever after" is written on the wall in blood. Jack, despite being the one to report the crime, is Rose's lover and an obvious suspect. So is Snow White, the effective leader of the Fables (King Cole is a figurehead) and Rose's estranged sister. And, perhaps coincidentally, Prince Charming, Snow White's philandering and stunningly narcissistic ex-husband, has just turned up in town again. The basic plot plays out like a typical murder mystery, complete with a grand reveal in the last chapter and a reconstruction of events. It's diverting but nothing special in itself; it's primarily a hook on which to hang an introduction to the major characters and an exploration of Fables politics and history. And that part is excellent. Like most fractured fairy tales, the characters are more complex and nuanced than they are allowed to be in the canonical stories; unlike most fractured fairy tales, nearly all of that development is allowed to happen after the original stories. The original stories happened, largely as we all remember them, but then the characters kept living and changing. Wolf and his relationship with one of the three pigs is one of the highlights, but I think the odious Price Charming is the best bit of characterization. Willingham takes the idea of a charming seducer and layers in the rest of the womanizing associations that come to mind, while retaining a slick surface charm that is hard not to like at some level. I'm not the best at critiquing art. I read graphic novels for the story, with the art as a nice bonus if it's fairly good. But I can say that Medina's pencils tell the story well, with a few larger panels that were quite impressive. I particularly liked Snow White's office, early in the collection. Detail is reasonably good throughout, there aren't too many panels featuring only talking heads, and Medina does a wonderful job with the pig. (Significant credit probably also goes to Steve Leialoha and Craig Hamilton, the inkers. I'm not a good enough art critic to distinguish between the quality of the pencil work and what was added by subsequent inking.) The largest problem for me with Legends in Exile is my standard problem with graphic novels and the reason I don't buy many of them: the cover price is $10 for what is effectively a short story that builds an interesting world. If one really loves art in stories, graphic novels may be a good value. If, like me, one mostly cares about the story and would be almost as happy with straight prose, the value becomes questionable given the brief length of the material. That said, Legends in Exile does add a quite good prose short story by Willingham, "A Wolf in the Fold," which in several ways is better than the main story of the collection. It tells the story of the original exile and the covenant that settled all past grudges (mostly) from the perspective of the wolf. Willingham does a great job here both striking a more mythic tone than the main story but still tying it back to the sarcastic and practical tone of the rest of the collection. Although the main story itself is not particularly memorable, the background and concept make this one of the better graphic novels I've read. I can see why it's won so many awards, and I'll probably keep reading, despite the high graphic novel price tag. Followed by Fables: Animal Farm. Rating: 7 out of 10

This blog, together with Romain's, is one of the main homes of stories about how Rcpp can help with getting code to run faster in the context of the R system for statistical programming and analysis. By making it easier to get already existing C or C++ code to R, or equally to extend R with new C++ code, Rcpp can help in getting stuff done. And it is often fairly straightforward to do so. In this context, I have a nice new example. And for once, it is work-related. I generally cannot share too much of what we do there as this is, well, proprietary, but I have this nice new example. The other day, I was constructing (large) time series of implied volatilities. Implied volatilities can be thought of as the complement to an option's price: given a price (and all other observables which can be thought of as fixed), we compute an implied volatility price (typically via the standard Black-Scholes model). Given a changed implied volatility, we infer a new price -- see this Wikipedia page for more details. In essence, it opens the door to all sorts of arbitrage and relative value pricing adventures. Now, we observe prices fairly frequently to create somewhat sizeable time series of option prices. And each price corresponds to one matching implied volatility, and for each such price we have to solve a small and straightforward optimization problem: to compute the implied volatility given the price. This is usually done with an iterative root finder. The problem comes from the fact that we have to do this (i) over and over and over for large data sets, and (ii) that there are a number of callbacks from the (generic) solver to the (standard) option pricer. So our first approach was to just call the corresponding function GBSVolatility from the fOption package from the trusted Rmetrics project by Diethelm Wuertz et al. This worked fine, but even with the usual tricks of splitting over multiple cores/machines, it simply took too long for the resolution and data amount we desired. One of the problems is that this function (which uses the proper uniroot optimizer in R) is not inefficient per se, but simply makes to many function call back to the option pricer as can be seen from a quick glance at the code. The helper function .fGBSVolatility gets called time and time again:

R> GBSVolatility
function (price, TypeFlag = c("c", "p"), S, X, Time, r, b, tol = .Machine$double.eps, 
    maxiter = 10000) 
 
    TypeFlag = TypeFlag[1]
    volatility = uniroot(.fGBSVolatility, interval = c(-10, 10), 
        price = price, TypeFlag = TypeFlag, S = S, X = X, Time = Time, 
        r = r, b = b, tol = tol, maxiter = maxiter)$root
    volatility
 
<environment: namespace:fOptions>
R> 
R> .fGBSVolatility
function (x, price, TypeFlag, S, X, Time, r, b, ...) 
 
    GBS = GBSOption(TypeFlag = TypeFlag, S = S, X = X, Time = Time, 
        r = r, b = b, sigma = x)@price
    price - GBS
 
<environment: namespace:fOptions>

So the next idea was to try the corresponding function from my RQuantLib package which brings (parts of) QuantLib to R. That was seen as been lots faster already. Now, QuantLib is pretty big and so is RQuantLib, and we felt it may not make sense to install it on a number of machines just for this simple problem. So one evening this week I noodled around for an hour or two and combined (i) a basic Black/Scholes calculation and (ii) a standard univariate zero finder (both of which can be found or described in numerous places) to minimize the difference between the observed price and the price given an implied volatility. With about one hundred lines in C++, I had something which felt fast enough. So today I hooked this into R via a two-line wrapper in quickly-created package using Rcpp. I had one more advantage here. For our time series problem, the majority of the parameters (strike, time to maturity, rate, ...) are fixed, so we can structure the problem to be vectorised right from the start. I cannot share the code or more the details of my new implementation. However, both GBSVolatility and EuropeanOprionImpliedVolatility are on CRAN (and as I happen to maintain these for Debian, also just one sudo apt-get install r-cran-foptions r-cran-rquantlib away if you're on Debian or Ubuntu). And writing the other solver is really not that involved. Anyway, here is the result, courtesy of a quick run via the rbenchmark package. We create a vector of length 500; the implied volatility computation will be performed at each point (and yes, our time series are much longer indeed). This is replicated 100 times (as is the default for rbenchmark) for each of the three approaches:

xyz@xxxxxxxx:~$ r xxxxR/packages/xxxxOptions/demo/timing.R
    test replications elapsed  relative user.self sys.self user.child sys.child
3 zzz(X)          100   0.038     1.000     0.040    0.000          0         0
2 RQL(X)          100   3.657    96.237     3.596    0.060          0         0
1 fOp(X)          100 448.060 11791.053   446.644    1.436          0         0
xyz@xxxxxxxx:~$ 

The new local solution is denoted by zzz(X). It is already orders of magnitude faster than the RQL(x) function using RQuantLib (which is, I presume, due to my custom solution internalising the loop). And the new approach is a laughable amount faster than the basic approach (shown as fOp) via fOptions. For one hundred replications of solving implied volatilities for all elements of a vector of size 500, the slow solution takes about 7.5 minutes --- while the fast solution takes 38 milliseconds. Which comes to a relative gain of over 11,000. So sitting down with your C++ compiler to craft a quick one-hundred lines, combining two well-known and tested methods, can reap sizeable benefits. And Rcpp makes it trivial to call this from R.

During the Squeeze release cycle, Alexander Reichle-Schmehl used to blog every week about this. Let s try to continue the tradition. The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 916
  • Affecting wheezy: 464
    That s the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting wheezy and unstable: 327
      Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 77 bugs are tagged patch .
        Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 17 bugs are marked as done, but still affect unstable.
        This can happen due to missing builds on some architectures, for example. Help investigate!
      • 235 bugs are neither tagged patch, nor marked done.
        Help make a first step towards resolution!
    • Affecting wheezy only: 137
      Those are already fixed in unstable, but the fix still needs to migrate to wheezy. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.

Note: I m looking for someone to send this posts on a regular basis. All you need is a blog syndicated on Planet Debian (there s a secret UDD page that generates the HTML code for you ;) ). Contact me if you are interested. taken!

Review: Passion Play, by Sean Stewart

Publisher:	Ace
Copyright:	1992
Printing:	December 1993
ISBN:	0-441-65241-7
Format:	Mass market
Pages:	194

Diane is a shaper: an empath, a sort of telepath, who sees emotions and the actions of others in the form of patterns and stories that she is nearly compelled to follow. She uses that skill as an investigator, a semi-official adjunct to the police who can read crime scenes and motives and hunt down criminals with uncanny ability. That makes her almost socially acceptable, but a shaper is still not something it's safe to be, something best kept hidden. Diane's world is one of theocracy, of dominance by aggressive religion, and even shapers working with the police are not exactly okay. This is Sean Stewart's first novel. He's since gone on to write many other books, one of which I've read and quite enjoyed (Nobody's Son) and another (Galveston) that won several awards, although he's probably most famous for his work on the ilovebees ARG. Passion Play won a minor award itself: the Aurora for the best Canadian SF novel of the year. I found it surprising as a first novel, since it's sharp, focused, and very short. Usually first novels are stuffed to the gills with ideas and plot, as if material had built up for years and exploded in the first book. Passion Play doesn't have that problem; if anything, it errs on the side of telling too little. This is, at its heart, a mystery. A famous actor died in the middle of a play. It was possibly suicide, possibly an accident, and possibly murder; the events of the death are quite ambiguous. But the actor is very important in Redemptionist politics, which warrants an investigation, and then Diane's shaper instincts start finding a pattern and a story in the death. The rest of the cast and crew form the obvious set of suspects, and have the normal mystery novel variety of flaws, foibles, strong personalities, and possible motives. I'm not much of a mystery novel reader, and to be honest I had some trouble tracking all of the characters and remembering Diane's suspicions about each one. But the details of the mystery are less important to this book than Diane herself. Shapers are not exactly stable. The patterns they see are all-consuming, the experience of others' strong emotions acts like a sort of drug, and shapers can burn themselves out. They can fall into a spiral of seeking stronger and stronger emotions until they can't feel anything at all. That's the core conflict of the book: Diane is slowly losing herself. She has a tenuous existence at the outskirts of a society that has inculcated her with an inflexible set of religious beliefs and an uncompromising attitude towards law and justice, but it's not a stable existence, she knows it, and she doesn't know what to do about it. She knows that the pattern of this particular death is deep and powerful, but she can't stay away from it. This is an unusual, and sometimes disturbing, focus for a story. It's risky, unconventional, and doesn't quite work. I think some of the failure is because of first novel problems, but most of it is due to character problems. In the first novel problems category, Passion Play is a bit too choppy and a bit too disjointed. I think Stewart was trying hard to keep the story focused, fast-moving, and tight, but the introduction of the world background is not particularly smooth, and Diane's first-person account of her emotional state is a bit too labored. The plot wants to build in a smooth arc towards its climax, but the writing and scene-setting jerks and jumps instead of flowing. But the larger problem for me is that there aren't enough interesting characters in this book; specifically, there aren't enough to show all sides of Diane's character. Stewart tries, by introducing Jim early in the book to serve essentially as Diane's friend (and she's desperately in need of one), but he's too much of a non-entity. He serves some plot purposes, but he doesn't have a strong enough voice and character to hold his ground against Diane and balance her obsessive internal monologue. And, other than Jim, all the other characters in the book (with the possible exception of the murder victim) are playing bit roles. They're not bad characters, but they don't feel fully real to either Diane or to the reader. It's very easy to put them into boxes that they never break out of. This does support the feeling of narrative inevitability about some parts of the book, but I think it would have been stronger with more conflict, more open challenging of Diane's perspective. I would characterize Passion Play as interesting but flawed, and ultimately a minor work. I'm not sorry I read it, but neither would I have missed much if I'd gone through life without reading it. It has a few interesting ideas, and a bravely unconventional narrative resolution, but it felt choppy and off-balance. Unless you love Stewart's writing and want to read everything he wrote, or unless you (like me) has a quirk about reading all award winners, this is probably best skipped over in favor of Stewart's later work. Rating: 6 out of 10

This week s issue of c't, one of Germany s largest and most influential computer magazine, has a six page introductory article about Haskell (c't 2012, Issue 23, pages 182-187). The author Harad B geholz demonstrates its features and strength by implementing a Slitherlink puzzle solver. As I have helped him a bit by checking the code and article for untypical Haskell code and general advice, I happen to be named at the end of the article nice.

Ever since my company moved offices back in June, I've been wanting to do this: organize a BSP. It just hadn't happened yet. Today, I decided that unless I start actually making this a concrete plan rather than some vague idea, it isn't going to happen. So, here we go: during the weekend of the 15th and 16th of December, I expect some people to show up and help stamping out those pesky RC bugs. If you've been wanting to help Debian somehow but don't know where to start, this is your chance! Don't worry about not knowing how all this works; there will be Debian Developers attending who can help you out (two DDs have told me that they'd like to attend, and of course I will be there too). If you've got some experience in Debian packaging, your help would of course be all the more appreciated. Even if you can't make it the whole weekend, that's fine too! Just be there for as long as you can, and help stamp out those pesky RC bugs. The more people help out, the better!

As the openSUSE Conference and all related events are over, it's time to share my thoughts how it was. This was actually first conference ever where I helped with organizing, so it was quite new experience for me. Week before it has happened I expected quite a lot of problems, but in the end everything went more or less smoothly. Having something like 700-800 visitors is IMHO great for first year of LinuxDays, even though it has been collocated with other conferences. Most people came on Saturday and there were less of them on Sunday. Maybe it was result of the party, which lasted for many of them till early morning (I've left around 1 AM and there were still lot of people drinking). Besides organizing stuff, I also had my own talk about Weblate. Unfortunately not much people has attended it, but those who did gave me some valuable feedback which will be reflected in next Weblate release. Anyway if you want to see my slides from this talk, they are now available on my website.

Filed under: English Suse Weblate 0 comments Flattr this!

So, what happens if your root partition is full and you reboot your machine ? If it is really full, and in particular there is no space to write anywhere, you might be stuck with a no space on device. To avoid this problem, there exists a script /etc/init.d/mountoverflowtmp that runs a check to see if there is a minimum acceptable space on /tmp and if there is not, it mounts it overflow. It also checks for unneeded overflow tmpfs for /tmp and removes them if that is appropriate.(src). But if you do not reboot again, you might get stuck with a mini /tmp directory of 1Mb . This is a neat trick, but you need to know about it to avoid unpleasant and unexpected surprises.

I've had a few weeks with very little time spent on Debian. I did set aside some time to try to find and fix an RC bug, to help the release. Steven C commented to let me know about the UDD Developer's Dashboard which is a great way to find RC bugs relevant to a team. I sat down to try and fix #648272 in 'Abuse' but sadly I didn't manage, instead finding another possible RC bug #689457 on the way. I was curious as to how long the version 1 web services API for musicbrainz will be kept around, in case there was a strong likelyhood it would be turned off during the lifetime of wheezy. If that were the case, then it might have been worth requesting freeze exceptions to patch the last few WS1 clients to use WS2 instead. However, the musicbrainz developers have no plans to turn off WS1 as long as there are people still using it. This is a bit of a chicken and egg situation for wheezy, but probably not strong enough grounds to persue it any further. So last night was my first "Debian Day" in a while, and by chance I've had a number of enquiries for software and packages which I haven't touched in a while. For the prboom package, we rebuild the upstream tarball to remove some material we don't have the right to distribute. The code that does the repackaging lives in a script called debian/fix_upstream.sh. Prboom upstream release very infrequently, so the script hasn't been run in a while. Fabian Greffrath noticed some bashisms which meant it would not work reliably with a non-bash /bin/sh. He also noticed that we couldn't build the binary lump data/prboom.wad using only free software since some changes that were made to freedoom. One possible fix was to expand the deutex package to recognise freedoom.wad, which I've now applied. Fabian has fixed the bashism issue, but I suspect a more robust solution long-term would be to always rebuild data/prboom.wad during package build, so that code gets exercised more often. The prboom changes are in the Git repository but I haven't release them yet. I need to decide whether it's worth requesting a freeze exception for the orig tarball build issue. It's not an FTBFS but it's similar: you could not rebuild a binary distributed in the source tarball using software only in Debian, at least not without some workarounds. We've had another request to package Prboom+. I've never been particularly interested in doing this myself, but it would probably be very little work, you could more-or-less take the prboom packaging as it stands. One thing I thought would be interesting to try would be to set up a git repository for the packaging and import the upstream Subversion repository in its entirety via git svn, rather than just import the released tarballs. Sadly their repository layout is not quite ideal for this. game-data-packager continues to grow. Following hot on the heels of Hexen 2 support, Markus Koschany has written preliminary support for LGeneral, a game which has been in Debian, at least in part, on and off. Hopefully we'll have that merged soon, and finish of Hexen 2 support whilst we're at it. On that note, here's a lazyweb question: what's the most convenient way to determine the length (at microsecond resolution) of a PCM WAV file from the command-line? Finally, we've been building Debian-based virtual machines at work, which meant dusting off some old preseed files and tweaking them to have unattended installs. This took a lot longer than I thought. It's certainly a lot more painful than kickstart and Redhat-based systems, and it's very unlikely that a preseed file that worked for one version of Debian would fully work for another. I'm not certain but I think even different releases of d-i targetting the same release "break" assumptions you might make, particularly about which questions you need to answer via the kernel command line, rather than in the preseed file. That's one thing we really need to sort. It's crazy having to specify keyboard layouts in the command line for VMs which won't ever have a keyboard. The disparity between what the user is asked, what value is written to the debconf database at that point in the install process, and what ends up in the debconf database at the end of the process is also a real pain: answering a question about keyboard layout sets half a dozen different debconf values in a cascade that is probably sensitive to other things like priority or whether d-i is in expert mode, too. So working backwards from the debconf database of an installed machine is an exercise in frustration, and figuring out which questions are asked prior to the preseed file being read for any given d-i or Debian release is a slow trial and error process. I'm going to get in touch with the d-i folks and see what kind of continuous integration systems they have in place. It would be great to have commit-level notification that you've broken preseed builds. If not for the d-i folks, then certainly at work.

There have been a few interesting discussions going on in parallel about my slaughter sysadmin tool. I've now decided there will be a 2.0 release, and that will change things for the better. At the moment there are two main parts to the system:

Downloading polices

These are instructions/perl code that are applied to the local host.

Downloading files

Polices are allowed to download files. e.g. /etc/ssh/sshd_config templates, etc.

Both these occur over HTTP fetches (SSL may be used), and there is a different root for the two trees. For example you can see the two public examples I have here:

• http://www.steve.org.uk/slaughter/policies/
• http://www.steve.org.uk/slaughter/files

A fetch of the policy "foo.policy" uses the first prefix, and a fetch of the file "bar" uses the latter prefix. (In actual live usage I use a restricted location because I figured I might end up storing sensitive things, though I suspect I don't.) The plan is to update the configuration file to read something like this:

transport = http
#
# Valid options will be
#    rsync   http   git   mercurial   ftp
#
#
# each transport will have a different prefix
#
prefix = http://static.steve.org.uk/private
# for rsync:
#  prefix=rsync.example.com::module/
#
# for ftp:
#  prefix=ftp://ftp.example.com/pub/
#
#  for git:
#  prefix=git://github.com/user/repo.git
#
#  for mercurial
#  prefix=http://repo.example.com/path/to/repo
#

I anticipate that the HTTP transport will continue to work the way it currently does. The other transports will clone/fetch the appropriate resource recursively to a local directory - say /var/cache/slaughter. So the complete archive of files/policies will be available locally. The HTTP transport will continue to work the same way with regard to file fetching, i.e. fetching them remotely on-demand. For all other transports the "remote" file being copied will be pulled from the local cache. So assuming this:

transport = rsync
prefix    = rsync.company.com::module/

Then the following policy will result in the expected action:

if ( UserExists( User => "skx" ) )
 
    # copy
    FetchFile(
            Source => "/global-keys",
              Dest => "/home/skx/.ssh/authorized_keys2",
             Owner => "skx",
             Group => "skx",
              Mode => "600" );
 

The file "/global-keys" will refer to /var/cache/slaughter/global-keys which will have been already downloaded. I see zero downside to this approach; it allows HTTP stuff to continue to work as it did before, and it allows more flexibility. We can benefit from knowing that the remote policies are untampered with, for example, via the checking built into git/mercurial, and the speed gains of rsync. There will also be an optional verification stage. So the code will roughly go like this:

• 1. Fetch the policy using the specified transport.
• 2. (Optionally) run some local command to verify the local policies.
• 3. Execute policies.

I'm not anticipating additional changes, but I'm open to persuasion.

I get a lot of spam. Most of it, thankfully is blocked by dspam but occasionally i get some through the filter. One that particularly caught my eye was interesting not so much what it was advertising (I don t read that part of the email) but where it came from and goes to. Normally there are two service providers involved in spam. The email comes from (or via) one and then the spamvertised website is another. The interesting thing is for this spam both of these were the same service provider. The email came from 174.34.168.85 and the spamvertised website was 70.32.40.194. Both of these addresses are owned by nobistech.net. I punted the email to spamcop and it said that they re not interested in spam reports. A few google queries shows that these guys seem quite happy to have spam sources and destinations and have been doing it for years. They either appear as nobistech.net or unbiquity servers but they are one and the same organisation, or at least related. I won t bother to send anything to them, it seems this has been done many many times by others with no results. Instead some CIDR blocks will be put into my blacklist.

Lately I've been spending some time checking the Debian archive for bashisms in preparation of the release of Debian wheezy. This requires running checkbashisms against every /bin/sh script, checking the results by hand to discard some false positives, and filing bug reports of bashisms.
And of course, fixing and improving checkbashisms; some of that work to be published soon.

It is fun that when one fixes some parsing errors it leads to regressions in the form of false negatives due to other parsing errors... oh well.

However, while looking around the web for references about checkbashisms, I noticed that somebody created a sourceforge project under that same name. It is a fork of an old version of checkbashisms, and hasn't seen an update in over a year. It even appears that a FreeBSD port is based on it.

If you are looking for the latest checkbashisms, please get it either from the latest version of devscripts, or from devscripts' git repository.