Search Results: "xam"

19 June 2014

Joey Hess: what does docker.io run -it debian sh run?

When you type docker.io run -it debian sh, it goes off and gets "debian" and runs it. But what is in this "debian" image? How was it built? The docker hub does not really say. All it tells us is this is a "(Semi) Official Debian base image" and that its sources.list uses http.debian.net for geolocation. There's a link to https://github.com/dotcloud/stackbrew/blob/master/library/debian which in turn uses a very strange git repository, owned by Debian maintainer Tianon Gravi, that contains compressed tarballs of Debian: http://github.com/tianon/docker-brew-debian "Git is not a fan of what we're doing here." The "source", such as it is, that is used to build this image consists of:
FROM scratch
ADD rootfs.tar.xz /
CMD ["/bin/bash"]
and
mkimage.sh -t tianon/debian:wheezy -d . debootstrap --variant=minbase --components=main --include=inetutils-ping,iproute wheezy http://http.debian.net/debian
I don't know where mkimage.sh is. [Update: Probably /usr/share/docker.io/contrib/mkimage-debootstrap.sh or a modified version] And anyway, I have no reason to trust that this image is built the way it claims to be built. So, the question remains: What is in this image? To find out, I did a debootstap --variant=minbase stable and diffed the entire docker debian image against it. The diff was 6738 lines, from which I found the following interesting differences. added packages The image has iputils-ping and netbase and iproute added. These are not in a minbase debootstrap, but are in a regular debootstrap. It's rather weird that the docker image is based on a minbase debootstrap, since this means they have to add back important stuff like this on an ad-hoc basis.
If the expectation is that an experienced Unix person who found it missing would say "What on earth is going on, where is 'foo'?", it must be an 'important' package. -- Debian Policy
apt hooks
DPkg::Post-Invoke   "rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin   true";  ;
APT::Update::Post-Invoke   "rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin   true";  ;
Dir::Cache::pkgcache "";
Dir::Cache::srcpkgcache "";
Acquire::Languages "none";
These are some strange modifications to apt's config. The intent is clearly to avoid wasting disk space, even at the expense of making apt slower (by disabling caches) and losing translations. I am curious if apt might ever invoke the DPkg::Post-Invoke twice in an upgrade in which it runs dpkg twice. I'm also curious whether deleting /var/cache/apt/archives/lock could cause a problem. unsafe-io dpkg is configured to use unsafe-io. motd
Linux viper 3.12.20-gentoo #1 SMP Sun May 18 12:36:24 MDT 2014 x86_64
Yes, that's "gentoo". Presumably this tells us something about the build host. policy-rc.d /usr/sbin/policy-rc.d contains "exit 101", which prevents daemons from being automatically started after they are installed. This may or may not be desirable, depending on what you're doing with docker. It notably also prevents restarting running daemons in this container if they're upgraded for eg, a security fix. It would almost certianly be better if this script allowed restarting running daemons. diversions /sbin/initctl is diverted and replaced with /bin/true. This is a workaround for a bug in sysvinit; when upgraded inside a docker container it hangs while trying to run initctl. missing devices Some versions of the debian image are missing things in /dev. See this bug. (I had listed some device files that I thought were missing, but I was wrong.) some gpg thing is different
Binary files pure-debootstrap/etc/apt/trustdb.gpg and from-docker/etc/apt/trustdb.gpg differ
Oh well, that can't be important.. Or can it? I did not check. conclusions I would hardly consider this to be an "(Semi) Official Debian image". Some of the changes are quite dubious. The build environment is not Debian. There is no guarantee you'll get the same image I examined. Diffing thousands of lines of filesystem changes is not particularly fun or reliable way to spot accidental or malicious changes. I'd recommend only trusting docker images you build yourself. I have some docker images published somewhere that are built with 100% straight debootstrap with no modifications (and even an armel image that can be used on an x86 system thanks to qemu). But I'm not going to link to them, because again, you should only trust docker images you built yourself. To help increase your mistrust of me, I present this IRC snippet:
<joeyh> I'll bet I could publish an image that just did a killall5 as root on startup and get plenty of people to nuke their container hosts
Here are some ideas for things Debian could do to improve this: PS, if this wasn't enough fun, just consider the tweaks made to the "Debian" images on all the VPS hosts out there.

Russell Coker: Phone Car Accessories

Tree Frog Dashboard Mat phone stuck to fridge I ve been given some more MobileZap products to review. The first is the Tree Frog anti-slip dashboard mat [1]. This is designed to allow a phone to stick to an angled surface of the inside of the car without slipping. The pictures on the web site show a phone stuck to a curved angular surface of a car dash. To test this I stuck my phone to my fridge, the flat metal surface of the fridge and the almost flat plastic surface of the gel case of my phone are pretty much ideal surfaces for the sticky mat to adhere to. But even so keeping my phone stuck to a vertical surface is impressive. This mat is cheap enough that it could be used for many other tasks than securing a phone in a car, for example it could be used to stick a phone to the wall of your office. It s apparently washable and can be expected to keep gripping things if washed regularly. One thing that could be improved in the mat would be to have some holes in it. When I detached my phone from the fridge some large air bubbles developed between the mat and the fridge, this would be a problem if I wanted to regularly stick my phone to a flat surface such as an office wall. When in my car it didn t work nearly as well. The pattern on the surface of the car dash which is designed to avoid glare when driving is difficult to stick to, it s a bit like trying to attach sticky-tape to unpainted wood for similar reasons. A phone will still remain in place on a 30 degree angle from the horizontal (which is significant) but the mat grips much more tightly to the phone than the dash, which is a little inconvenient as the mat stays attached to the phone when you remove it from the dash. Sorry for the boring picture, it s black and flat so there s not much scope for making it interesting. 3.1A USB Car Charger AA battery charger and 3.1A car charger Above is a picture of a 3.1A USB car charger and a AA battery charger. The car charger isn t particularly exciting, but providing 3.1A through two USB sockets is noteworthy it can charge one device at 2.1A (the maximum any device draws) or two devices for a total of up to 3.1A [2] (with protection against over-current). Previously in my car I used the 2.1A charger that shipped with my Galaxy Note 2 and an inverter to provide 240VAC as the devices I had to charge a phone from a car socket didn t provide enough current. This new device uses less space and also allows charging two phones at once. One problem with this device was finding USB cables that could handle the current, for benchmarking I used a phone that was running Ingress and acting as a Wifi access point. I discovered that the cables that Samsung ships with their recent devices (Galaxy Note 2 and Galaxy Note 10.1 tablet) seem to work best and support charging my Galaxy Note 2 or my wife s Nexus 5 while playing Ingress and running as a Wifi AP. Most of the other cables that I have in my collection won t even allow a phone to remain at the same charge level while playing Ingress. AA Emergency Phone Charger The AA phone charger is best suited for emergency use only, it takes one AA battery and has limited current capacity [3]. A NiMh rechargeable battery has a nominal Voltage of 1.2V, to provide 5V to charge a phone the Voltage has to be boosted by a factor of 4.16 which would reduce the current by a factor of 4.16 if the charger was 100% efficient. As 100% efficiency is impossible the current would be reduced even more. It seems unlikely that a AA battery would be able to sustain a current of 2A so the supply from that charger would be less than 500mA IE less than the least capable PC USB port or mains powered phone charger. A test with a Nexus 5 showed the phone charge level decreasing while being very lightly used (mostly just checking whether the charge level was increasing) when a NiMH battery was connected. A test with an alkaline battery and the same Nexus 5 showed the phone charge level increasing when lightly used but it probably wouldn t do so while playing Ingress. It seems that a single NiMH AA battery can only be used for charging a phone in a real emergency situation (IE an act of god type disaster not a need to level up in Ingress). If mains power was out then you could charge a phone while it s turned off (AFAIK all Android phones support this) and then use it once it s charged. This charger supports a wide range of phones (including LG phones from 5+ years ago and Nokia from ~10 years ago) so it could be good for charging an old phone in an emergency. Older phones need less power to charge and generally last longer between charges. With an alkaline battery the charger works a lot better, but it s still for emergency use as I generally only use rechargeable batteries. This is a device I might put in the bottom of my case when travelling, not a device that I ll use regularly. I don t think that this is a deficiency in the product, it s just a limit of what can be done with the power requirements of modern phones and the capabilities of AA batteries. If you want a battery to use while playing Ingress you definitely need something a lot larger. This charger is good for emergencies but not suitable for my main use (charging phones while playing Ingress) so I ll give it to my parents, they do a lot of hiking and camping and my father often goes fishing. Taking a few AA batteries to charge a phone would be much more convenient for such use than taking one of the larger batteries I use for Ingress. Also as the charger is relatively cheap there s less potential financial loss if you drop it in sea-water. 20800mAh Battery picture of 20800mAh USB battery Above is a picture of a 20800mAh battery pack that MobileZap sent me [4]. I haven t yet discovered what it s capacity is, during the recent Interitus anomaly it kept my Galaxy Note 2 and my wife s Nexus 5 adequately charged for 5 hours of intensive Ingress playing (we alternated between phones). Without an external battery it would be unusual for either of those phones to last for 2 hours. The battery has two ports labeled 1A and 2.1A which implies that it can supply a total of 3.1A. I am a little dubious of that implication. After the Interitus anomaly my wife and I had dinner with some friends and I let a friend charge her Samsung Galaxy S5 on the battery at the same time as my Note 2 (which claimed to be 2% charged). When I connected my friend s phone my phone instantly shut itself down due to lack of charge, so I presume that the supply on the 2.1A port is reduced when a demanding device is connected to the 1A port. The next day my wife and I went to the city again to play Ingress and attend a protest against some of the awful things that the Abbott government is doing. As an experiment I didn t charge this battery to see how it would go for two days of use charging two phones. Again there was no problem and it still claimed to be half charged when we got home. So far the only problem I ve found with this battery is that it never reports being fully charged, not even if I leave it on charge for days. That doesn t seem to be a great problem to me, if I disconnect it before it s fully charged then that won t hurt the battery life (unlike NiCd batteries that have to be fully charged every time) and even if it s not fully charged it will still charge phones for a long time. The battery is about 19cm long. I have jeans with unusually large pockets to fit large phones [5] so I can fit this battery in my pocket while a USB cable is connected to charge my phone. I also have a new winter jacket from Scottwear which has pockets that can fit the battery (and lots of other things). Anyone who doesn t have such clothing should plan to use a backpack, handbag, or some other bag this type of battery won t fit in the pockets in most clothing. MobileZap also has some other interesting Nexus 5 accessories [6].

18 June 2014

Aurelien Jarno: Debian is switching (back) to GLIBC

Five years ago Debian and most derivatives switched from the standard GNU C Library (GLIBC) to the Embedded GLIBC (EGLIBC). Debian is now about to take the reverse way switching back to GLIBC, as EGLIBC is now a dead project, the last release being the 2.19 one. At the time of writing the glibc package has been uploaded to experimental and sits in the NEW queue. EGLIBC is dead for a good reason: the GLIBC development has changed a lot in the recent years, due to two major events: Ulrich Drepper leaving Red Hat and the GLIBC development, and the GLIBC steering committe self-dissolving. This has resulted in a much more friendly development based on team work with good cooperation. The development is now based on peer review, which results in less buggy code (humans do make mistakes). It has also resulted in things that were clearly impossible before, like using the same repository for all architectures, and even getting rid of the ports/ directory. Before we used to have two sets of architectures, the main ones in the glibc repository with architectures like x86, SuperH or SPARC, and the secondary ones in the glibc-ports repository with architectures like ARM or MIPS. As you can see the separation was quite arbitrary, and often leaded to missing changes on the secondary architectures. We also got real stable branches, with regular fixes. The most important EGLIBC features have been merged to GLIBC, including for example the use of non-bash but POSIX shell, or the renaming of reserved keywords. The notable exception is the support for configurable components, which we originally planned to use for Debian-Installer, by building a smaller flavor using -Os and without NIS and RPC support. At the end we never worked on that, and it seems that the hardware targeted by Debian has grown faster than the GLIBC size, so that is not really a big loss. At the end, we ended up with only 5 missing patches from the EGLIBC tree: The package names are unchanged (except the source package and the binary package containing the sources) so the transition is fully transparent for the users. I would like to thank all the CodeSourcery employees who worked on EGLIBC, with a special thank to Joseph Myers who spent countless hours to merge the most important EGLIBC changes back to GLIBC, and sent regular emails about the merge status. I would also like to thanks all the people on the GLIBC side that made the change to happen, and all persons participating in the GLIBC development.

17 June 2014

Petter Reinholdtsen: From English wiki to translated PDF and epub via Docbook

The Debian Edu / Skolelinux project provide an instruction manual for teachers, system administrators and other users that contain useful tips for setting up and maintaining a Debian Edu installation. This text is about how the text processing of this manual is handled in the project. One goal of the project is to provide information in the native language of its users, and for this we need to handle translations. But we also want to make sure each language contain the same information, so for this we need a good way to keep the translations in sync. And we want it to be easy for our users to improve the documentation, avoiding the need to learn special formats or tools to contribute, and the obvious way to do this is to make it possible to edit the documentation using a web browser. We also want it to be easy for translators to keep the translation up to date, and give them help in figuring out what need to be translated. Here is the list of tools and the process we have found trying to reach all these goals. We maintain the authoritative source of our manual in the Debian wiki, as several wiki pages written in English. It consist of one front page with references to the different chapters, several pages for each chapter, and finally one "collection page" gluing all the chapters together into one large web page (aka the AllInOne page). The AllInOne page is the one used for further processing and translations. Thanks to the fact that the MoinMoin installation on wiki.debian.org support exporting pages in the Docbook format, we can fetch the list of pages to export using the raw version of the AllInOne page, loop over each of them to generate a Docbook XML version of the manual. This process also download images and transform image references to use the locally downloaded images. The generated Docbook XML files are slightly broken, so some post-processing is done using the documentation/scripts/get_manual program, and the result is a nice Docbook XML file (debian-edu-wheezy-manual.xml) and a handfull of images. The XML file can now be used to generate PDF, HTML and epub versions of the English manual. This is the basic step of our process, making PDF (using dblatex), HTML (using xsltproc) and epub (using dbtoepub) version from Docbook XML, and the resulting files are placed in the debian-edu-doc-en binary package. But English documentation is not enough for us. We want translated documentation too, and we want to make it easy for translators to track the English original. For this we use the poxml package, which allow us to transform the English Docbook XML file into a translation file (a .pot file), usable with the normal gettext based translation tools used by those translating free software. The pot file is used to create and maintain translation files (several .po files), which the translations update with the native language translations of all titles, paragraphs and blocks of text in the original. The next step is combining the original English Docbook XML and the translation file (say debian-edu-wheezy-manual.nb.po), to create a translated Docbook XML file (in this case debian-edu-wheezy-manual.nb.xml). This translated (or partly translated, if the translation is not complete) Docbook XML file can then be used like the original to create a PDF, HTML and epub version of the documentation. The translators use different tools to edit the .po files. We recommend using lokalize, while some use emacs and vi, others can use web based editors like Poodle or Transifex. All we care about is where the .po file end up, in our git repository. Updated translations can either be committed directly to git, or submitted as bug reports against the debian-edu-doc package. One challenge is images, which both might need to be translated (if they show translated user applications), and are needed in different formats when creating PDF and HTML versions (epub is a HTML version in this regard). For this we transform the original PNG images to the needed density and format during build, and have a way to provide translated images by storing translated versions in images/$LANGUAGECODE/. I am a bit unsure about the details here. The package maintainers know more. If you wonder what the result look like, we provide the content of the documentation packages on the web. See for example the Italian PDF version or the German HTML version. We do not yet build the epub version by default, but perhaps it will be done in the future. To learn more, check out the debian-edu-doc package, the manual on the wiki and the translation instructions in the manual.

11 June 2014

Daniel Pocock: Protest or Uber marketing stunt?

London's taxi "strike" today has been so successful that Uber claims to have had an 850% increase in new customer registrations this week. Well, that is a big success if you believe the strike may have been a guerrilla marketing tactic organised by Uber itself. No sympathy Personally, I have no sympathy for the taxi drivers. There is no city I have ever visited where I haven't encountered at least one taxi driver who tried to overcharge me. Honest drivers who give their customers value for money have less to fear from new technology than those who are unscrupulous. When I broke a leg a few years ago and was getting about on crutches for 6 weeks we decided to go out for dinner one night. This was the first time I went anywhere after having a long stint in hospital followed by a period of time I was confined to the house. The taxi driver deliberately skipped two turns leading directly to the restaurant, went another 1km past it and then followed a small street that winds back and forth and eventually demanded I pay him double what the fare should have been. This is exactly the type of abusive and despicable practice that is being eradicated by Uber's live GPS mapping technology. Although not every driver behaves so shamefully, this type of abuse of the weak or vulnerable is replicated in one way or another the world over. For example, in Melbourne, Australia, wheelchair taxis that have worked out they can make more money collecting families with suitcases at the airport leave genuine wheelchair users without a ride. Will Google be targeted next week? Google has just announced a step-change in plans to build their own self driving cars. Will Google offices around the world, including London be targetted by these crude blockades too? Political protest or anti-competitive mischief? Why were taxi drivers not arrested for their protest today? Given that the roads are the place where taxis and their competitors do business, can this blockade really be considered a political protest or is it an anti-competitive practice in blatant disregard of the law? Weapons of mass destruction Before even having breakfast you could probably find 10,000 cyclists in central London willing to sign a petition declaring taxis are a weapon of mass destruction. Once again, while there are honest drivers, there is a more than trivial number of taxi drivers who are a genuine danger to the lives of cyclists, scooters, motorcycles and occasionally pedestrians. I have personally experienced one of these thugs ramming my bicycle from behind (his hard-nosed insurer eventually paid up but without admitting liability). The police who attended the incident even told me they had seen so many accidents like this they wouldn't dare cycle themselves. The web is full of examples that appear to show malicious and criminal behavior by taxi drivers, thanks to Youtube and helmet cams: Will hotels protest about AirBNB? Now the taxi drivers have had their chance to cause mayhem, will hotel operators be next? What could they do though? Will they seek out AirBNB apartments and try to obstruct them somehow? Making mischief outside somebody's home is not a good way to make a point. Chances are, they would be prosecuted or served with restraining orders. So why do the taxi drivers get to jam up whole cities and get away with it? The Uber taxi meter loophole Will the courts decide that the Uber app is a taxi meter? This is actually a tough question. Even if courts rule against apps that perform live metering, Uber could simply remove all metering functions from the app itself and perform the metering calculations in the cloud. The app would just send start and finish locations to the cloud and the cloud would send a message back to the phone confirming the charge. The phone is then nothing more than a communication and positioning device. Remember the elevator man? When the automobile was first invented, laws were made requiring every car to be accompanied through public streets by a man carrying a flag. That job, like many others, no longer exists. elevator attendant In the good old days, every elevator had a man or woman who would sit on a stool and press buttons to operate the doors and motors. Some up-market department stores and hotels still have an elevator man to add a touch of nostalgia. The vast majority, however, have eliminated these jobs thanks to automatic elevators. Now, even aircraft can land automatically on a ship at sea. Look at all those people manning the deck in the video and contemplate how many of them might potentially be out of a job too in 50 years time as Terminator-style automated battleships patrol the seas. Technology, like the Terminator, is not going to stop.

9 June 2014

Daniel Pocock: reSIProcate v1.9 with WebRTC now available for Fedora 20 users

reSIProcate v1.9 has now moved from testing to stable and is available for Fedora 20 users. Version 1.9.7 has also propagated to Debian testing and wheezy-backports, delivering improved stability as discussed in my previous blog. Ready to try WebRTC? The quickest way to set up your own WebRTC trial is to install the repro (reSIProcate SIP proxy) packages for your preferred Linux distribution and then copy JSCommunicator into a directory on your web server. My earlier blog get WebRTC going faster gives specific examples of entries needed in repro.config.. WebRTC Calling from Android I've continued to have success making and receiving calls with both the Firefox and Chrome apps on Android. This is a great way to reach out to friends and family using free software for communication. More details and some screenshots are available in my earlier blog on Android WebRTC.

7 June 2014

Russ Allbery: Summer haul

More books. More reading is not yet happening, but I have hope. This particular set is quite random, mostly an excuse to pad out an order since My Real Children came out. Philip Ball Bright Earth (non-fiction)
Anthony Doerr All the Light We Cannot See (mainstream)
Leslie Jamison The Empathy Exams (non-fiction)
Dava Sobel Longitude (non-fiction)
Gore Vidal Julian (historical)
Jo Walton My Real Children (sff)
Markus Zusak The Book Thief (sff, sort of) My immediate inclination is to mark any book in which Death appears as a literal character as at least fantasy, but The Book Thief comes out of the mainstream genre, so we'll see what I think about the genre after reading it.

Vasudev Kamath: Exposing function in python module using entry_points, WSME in a Flask webapp

The heading might be ambiguous, but I couldn't figure out better heading so let me start by explaining what I'm trying to solve here.
Problem I have a python module which contains a function which I want to expose as a REST web service in a Flask application. I use WSME for Flask application, which actually needs signature of function in question and problem comes to picture because function to be exposed is foreign to Flask application, it resides in separate python module.
Solution While reading Julien Danjou's Hackers Guide To Python book I came across the setuptools entry_points concept which can be used to extend existing feature of a tool like plug-ins. So here I'm going to use this entry_points feature from setuptools to provide function in the module which can expose the signature of function[s] to be exposed through REST. Of course this means I need to modify module in question to write entry_points and function for giving out signature of function to be exposed. I will explain this with small example. I have a dummy module which provides a add function and a function which exposes the add functions signature.
def add(a, b):
    return a + b
def expose_rest_func():
    return [add, int, int, int]
This is stored in dummy/__init__.py file. I use pbr tool to package my python module. Below is content of setup.cfg file.
[metadata]
name = dummy
author = Vasudev Kamath
author-email = kamathvasudev@gmail.com
summary = Dummy module for testing purpose
version = 0.1
license = MIT
description-file =
  README.rst
requires-python = >= 2.7
[files]
packages =
  dummy
[entry_points] =
myapp.api.rest =
  rest = dummy:expose_rest_func
The special thing in above file is entry_points section, which defines function to be hooked into entry_point. In our case entry_point myapp.api.rest is used by our Flask application to interact with modules which expose them. The function which will be got accessing the entry_point is expose_rest_func which gives the function to be exposed its arg types and return types as a list. If we are looking at only supporting python3 it was sufficient to know function name only and use function annotations in function definition. Since I want to support both python2 and python3 this is out of question. Now, just run the following command in virtualenv to get the module installed.
PBR_VERSION=0.1 python setup.py sdist
pip install dist/dummy_module-0.1.tar.gz
Now if you want to see if the module is exposing entry_point or not just use entry_point_inspector tool after installing you will get a command called epi if you run it as follows you should note the dummy_module in its output
epi group list
+-----------------------------+
  Name                         
+-----------------------------+
  cliff.formatter.completion   
  cliff.formatter.list         
  cliff.formatter.show         
  console_scripts              
  distutils.commands           
  distutils.setup_keywords     
  egg_info.writers             
  epi.commands                 
  flake8.extension             
  setuptools.file_finders      
  setuptools.installation      
  myapp.api.rest               
  stevedore.example.formatter  
  stevedore.test.extension     
  wsme.protocols               
+-----------------------------+
So our entry_point is exposed now, we need to access it in our Flask application and expose the function using WSME. It is done by below code.
from wsmeext.flask import signature
import flask
import pkg_resources
def main():
   app = flask.Flask(__name__)
   app.config['DEBUG'] = True
   for entrypoint in pkg_resources.iter_entry_points('myapp.api.rest'):
       # Ugly but fix is only supporting python3
       func_signature = entrypoint.load()()
       app.route('/' + func_signature[0].__name__, methods=['POST'])(
           signature(func_signature[-1],
               *func_signature[1:-1])(func_signature[0]))
   app.run()
if __name__ == '__main__':
    main()
entry_point myapp.api.rest are iterated using the pkg_resources package provided by setuptools, when I load the entry_point I get back the function to be used which is called in same place to get function signature. Then I'm calling Flask and WSME decorator functions (yeah instead of decorating I'm using them directly over function to be exposed). The code looks bit ugly at the place where I'm accessing list using slices but I can't help it due to limitation of python2 with python3 there is new packing and unpacking stuff which makes code look bit more cooler see below.
from wsmeext.flask import signature
import flask
import pkg_resources
def main():
    app = flask.Flask(__name__)
    app.config['DEBUG'] = True
    for entrypoint in pkg_resources.iter_entry_points('silpa.api.rest'):
        func, *args, rettype = entrypoint.load()()
        app.route('/' + func.__name__, methods=['POST'])(
        signature(rettype, *args)(func_signature[0]))
    app.run()
if __name__ == '__main__':
    main()
You can access the service at http://localhost:5000/add depending on Accept header of HTTP you will get either XML or JSON response. If you access it from browser you will get XML response.
Usecase Now if you are wondering what is the reason behind this experience, this is for SILPA Project. I'm trying to implement REST service for all Indic language computing module. Since all these module are independent of SILPA which is a Flask web app I had to find a way to achieve this, and this is what I came up with.
Conclusion I'm not sure if there is any other approaches to achieve this, if there I would love to hear about them. You can write your comments and suggestion over email

6 June 2014

Robert Edmonds: BIND and GCC 4.9

ISC has issued an operational notification advising the use of the -fno-delete-null-pointer-checks flag when compiling current versions of BIND with GCC 4.9:
Beginning with GCC 4.9.0, code optimization in GCC now includes (by default) an optimization which is intended to eliminate unnecessary null pointer comparisons in compiled code. Unfortunately this optimization removes checks which are necessary in BIND and the demonstrated effect is to cause unpredictable assertion failures during execution of named, resulting in termination of the server process. Future versions of BIND will be modified so that the optimizer does not incorrectly remove necessary checks when building from source, and until those versions are available multiple immediate workarounds are available.
According to the GCC documentation, -fdelete-null-pointer-checks performs the following optimization, and is enabled by default even when compiling with -O0:
Assume that programs cannot safely dereference null pointers, and that no code or data element resides there. This enables simple constant folding optimizations at all optimization levels. In addition, other optimization passes in GCC use this flag to control global dataflow analyses that eliminate useless checks for null pointers; these assume that if a pointer is checked after it has already been dereferenced, it cannot be null.
This optimization dates back to 1999 but it recently became more aggressive in the GCC 4.9 release:
GCC might now optimize away the null pointer check in code like:
int copy (int* dest, int* src, size_t nbytes)  
  memmove (dest, src, nbytes);
  if (src != NULL)
    return *src;
  return 0;
 
The pointers passed to memmove (and similar functions in <string.h>) must be non-null even when nbytes==0, so GCC can use that information to remove the check after the memmove call. Calling copy(p, NULL, 0) can therefore deference a null pointer and crash. The example above needs to be fixed to avoid the invalid memmove call, for example:
if (nbytes != 0)
  memmove (dest, src, nbytes);
It's interesting that the ISC operational advisory labels this an "incorrect" optimization. I wonder if this is a similar case to the Glibc optimization which exposed incorrect usage of memcpy() in many applications, including BIND. Fortunately, few users should be affected by this bug, since GCC 4.9 is fairly new. (The upcoming Fedora 21 release will probably be the first mainstream distribution to ship with GCC 4.9 as the default compiler.) Update: Debian bug #750760 filed.

5 June 2014

Johannes Schauer: botch updates

My last update about ongoing development of botch, the bootstrap/build ordering tool chain, was four months ago and about several incremental updates. This post will be of similar nature. The most interesting news is probably the additional data that bootstrap.debian.net now provides. This is listed in the next section. All subsequent sections then list the changes under the hood that made the additions to bootstrap.debian.net possible.

bootstrap.debian.net The bootstrap.debian.net service used to have botch as a git submodule but now runs botch from its Debian package. This at least proves that the botch Debian package is mature enough to do useful stuff with it. In addition to the bootstrapping results by architecture, bootstrap.debian.net now also hosts the following additional services: Further improvements concern how dependency cycles are now presented in the html overviews. While before, vertices in a cycle where separated by commas as if they were simple package lists, vertices are now connected by unicode arrows. Dashed arrows indicate build dependencies while solid arrows indicate builds-from relationships. For what it's worth, installation set vertices now contain their installation set in their title attribute.

Debian package Botch has long depended on features of an unreleased version of dose3 which in turn depended on an unrelease version of libcudf. Both projects have recently made new releases so that I was now able to drop the dose3 git submodule and rely on the host system's dose3 version instead. This also made it possible to create a Debian package of botch which currently sits at Debian mentors. Writing the package also finally made me create a usable install target in the Makefile as well as adding stubs for the manpages of the 44 applications that botch currently ships. The actual content of these manpages still has to be written. The only documentation botch currently ships in the botch-doc package is an offline version of the wiki on gitorious. The new page ExamplesGraphs even includes pictures.

Cross By default, botch analyzes the native bootstrapping phase. That is, assume that the initial set of Essential:yes and build-essential packages magically exists and find out how to bootstrap the rest from there through native compilation. But part of the bootstrapping problem is also to create the set of Essential:yes and build-essential packages from nothing via cross compilation. Botch is unable to analyze the cross phase because too many packages cannot satisfy their crossbuild dependencies due to multiarch conflicts. This problem is only about the dependency metadata and not about whether a given source package actually crosscompiles fine in practice. Helmut Grohne has done great work with rebootstrap which is regularly run by jenkins.debian.net. He convinced me that we need an overview of what packages are blocking the analysis of the cross case and that it was useful to have a crossbuild order even if that was a fake order just to have a rough overview of the current situation in Debian Sid. I wrote a couple of scripts which would run dose-builddebcheck on a repository, analyze which packages fail to satisfy their crossbuild dependencies and why, fix those cases by adjusting package metadata accordingly and repeat until all relevant source packages satisfy their crossbuild dependencies. The result of this can then be used to identify the packages that need to be modified as well as to generate a crossbuild order. The fixes to the metadata are done in an automatic fashion and do not necessarily reflect the real fix that would solve the problem. Nevertheless, I ended up agreeing that it is better to have a slightly wrong overview than no overview at all.

Minimizing the dependency graph size Installation sets in the dependency graph are calculated independent from each other. If two binary packages provide A, then dependencies on A in different installation sets might choose different binary packages as providers of A. The same holds for disjunctive dependencies. If a package depends on A C and another package depends on C A then there is no coordination to choose C so to minimize the overall amount of vertices in the graph. I implemented two methods to minimize the impact of cases where the dependency solver has multiple options to satisfy a dependency through Provides and dependency disjunctions. The first method is inspired by Helmut Grohne. An algorithm goes through all disjunctive binary dependencies and removes all virtual packages, leaving only real packages. Of the remaining real packages, the first one is selected. For build dependencies, the algorithm drops all but the first package in every disjunction. This is also what sbuild does. Unfortunately this solution produces an unsatisfiable dependency situation in most cases. This is because oftentimes it is necessary to select the virtual disjunctive dependency because of a conflict relationship introduced by another package. The second method involves aspcud, a cudf solver which can optimize a solution by a criteria. This solution is based on an idea by Pietro Abate who implemented the basis for this idea back in 2012. In contrast to a usual cudf problem, binary packages now also depend on the source packages they build from. If we now ask aspcud to find an installation set for one of the base source packages (I chose src:build-essential) then it will return an installation set that includes source packages. As an optimization criteria the number of source packages in the installation set is minimized. This solution would be flawless if there were no conflicts between binary packages. Due to conflicts not all binary packages that must be coinstallable for this strategy to work can be coinstalled. The quick and dirty solution is to remove all conflicts before passing the cudf universe to aspcud. But this also means that the solution does sometimes not work in practice.

Test cases Botch now finally has a test target in its Makefile. The test target tests two code paths of the native.sh script and the cross.sh script. Running these two scripts covers testing most parts of botch. Given that I did lots of refactoring in the past weeks, the test cases greatly helped to assure that I didnt break anything in the process. I also added autopkgtests to the Debian packaging which test the same things as the test target but naturally run the installed version of botch instead. The autopkgtests were a great help in weeding out some lasts bugs which made botch depend on being executed from its source directory.

Python 3 Reading the suggestions in the Debian python policy I evaluated the possibility to use Python 3 for the Python scripts in botch. While I was at it I added transparent decompression for gzip, bz2 and xz based on the file magic, replaced python-apt with python-debian because of bug#748922 and added argparse argument parsing to all scripts. Unfortunately I had to find out that Python 3 support does not yet seem to be possible for botch for the following reasons:
  • no soap module for Python 3 in Debian (needed for bts access)
  • hash randomization is turned on by default in Python 3 and therefore the graph output of networkx is not deterministic anymore (bug#749710)
Thus I settled for changing the code such that it would be compatible with Python 2 as well as with Python 3. Because of the changed string handling and sys.stdout properties in Python 3 this proved to be tricky. On the other hand this showed me bugs in my code where I was wrongly relying on deterministic dictionary key traversal.

Matthew Palmer: An SSL Certificate Cooperative?

I ve been pondering co-ops, and their value in the world, lately. The thought has come to mind that a co-op which ran a Certificate Authority seems like an absolute no-brainer the members each contribute to the operational costs (servers, software, and the eye-watering auditing expenses) and in return get to issue all the domain-verified certificates they like (and pay reasonable rates for organization-verified certificates, and perhaps even EV certs). I know there are some superficially similar examples of this idea out there already. StartSSL captured my heart with their policy of only charging for what costs money (so you can get free DV certificates for personal use), but they made me sad when they charged for revocations (yes, I know revocations cost money to serve the CRL, but OCSP ain t free either ). CACert tickle my Free Software Fan-bone, being all about the freedom and community involvement, but lose some practicality points on the fact that they ve been trying to get their root certs into the browsers for a long time and haven t really gotten anywhere. So, assuming that DNSSEC (and hence DANE) doesn t become universally available any time soon, leaving the CA business model dead, buried, and worm-eaten, is the idea of a cooperative certificate authority of interest to anyone? Surely anyone who wished to have more control over their SSL certificates than you get with a reseller relationship, but couldn t justify becoming a root certificate holder themselves, would see the value of something of this nature?

4 June 2014

Dirk Eddelbuettel: Introducing RPushbullet

A new package of mine appeared on CRAN today: RPushbullet. A few days ago, I had tweeted about a first version available via its GitHub repo. The package is now on CRAN which will make it easier to install for many. You still need an API key (free, after registration at Pushbullet) and one or more target devices to message to: an modern smartphone (Android, iPhone, ...) or a Chrome browser provided you also installed the corresponding app. I also set up a short web page on my server with some more information and an example. So pushbullet away...

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

3 June 2014

Vasudev Kamath: Using WSME with Flask microframework

After reading Julien Danjou's I found out WSME (Web Service Made Easy) a Python framework which allows us to easily create Web Services in Python. For SILPA we needed a REST like interface and I thought of giving it try as WSME readily advertised the Flask integration, and this post was born when I read the documentation for Flask integration. First of all Flask is a nice framework which will right way allow development of REST api for simple purposes, but my requirement was bit complicated where I had to expose function in a separate python modules through SILPA. I think detailed requirement can be part of another post, so let me explain how to use WSME with Flask app. WSME integration with Flask is done via decorator function wsmeext.flask.signature which expects you to provide it with signature of function to expose. And here is its documentation, basically signature of signature function is
wsmeext.flask.signature(return_type, *arg_types, **options)
Yeah thats all docs have sadly. So basically exposing is the only thing WSME handles for us here, routing and other stuffs need to be done by Flask itself. So lets consider a example, simple function to add as shown below.
def add(a, b):
    return a + b
For providing REST like service, all you need below code.
from flask import Flask
from wsmeext.flask import signature
app = Flask(__name__)
@app.route('/add')
@signature(int, int, int)
def add(a, b):
    return a + b
if __name__ == '__main__':
       app.run()
So first argument to signature is return type of function and rest arguments are the argument to function to be exposed. Now you can access the newly exposed service by visiting http://localhost:5000/add but don't forget to pass the arguments either via query string or through post. You can restrict methods of access via Flask's route. So what's the big deal of not having docs right?.. Well fun part began when we use bit more complex return type like dictionaries or lists . Below is modified code I'm using to demonstrate problem I faced during using dict as return type.
from flask import Flask
from wsmeext.flask import signature
app = Flask(__name__)
@app.route('/add')
@signature(dict, int, int)
def add(a, b):
    return  "result": a + b 
if __name__ == '__main__':
    app.run()
Basically I'm returning a dictionary containing result now, for demonstration purpose. When I run the application boom python barked at me with following message.
Traceback (most recent call last):
File "wsme_dummy.py", line 7, in <module>
 @signature(dict, int, int)
File "c:\Users\invakam2\.virtualenvs\wsmetest\lib\site-packages\wsmeext\flask.py", line 48, in decorator
 funcdef.resolve_types(wsme.types.registry)
File "c:\Users\invakam2\.virtualenvs\wsmetest\lib\site-packages\wsme\api.py", line 109, in resolve_types
 self.return_type = registry.resolve_type(self.return_type)
File "c:\Users\invakam2\.virtualenvs\wsmetest\lib\site-packages\wsme\types.py", line 739, in resolve_type
 type_ = self.register(type_)
File "c:\Users\invakam2\.virtualenvs\wsmetest\lib\site-packages\wsme\types.py", line 668, in register
 class_._wsme_attributes = None
TypeError: can't set attributes of built-in/extension type 'dict'
After going through code from files involved in above traces this is what I found
  1. wsmeext.flask.signature inturn uses wsme.signature which is just alias of wsme.api.signature.
  2. Link in documentation in sentence See @signature for parameter documentation is broken and should actually link to wsme.signature in docs.
  3. wsme.signature actually calls resolve_type to check on types of return and arguments. This function checks if types are instance of dict or list in such cases it creates instances of wsme.type.DictType and wsme.type.ArrayType respectively with values from the argument.
  4. When I just passed built-in type dict the control went to else part which just passed the type to wsme.type.Register.registry function which tries to set the attribute _wsme_attribute which actually raises TypeError as we can't set attribute for built-in types.
So by inspecting code of wsme.type.Registry.resolve_type and wsme.type.Registry.register its clear that what signature expects when arguments or return type is dictionary/list is instance of dictionary/list with type of value in it. May be sentence is bit vague but I'm not sure how to put it more clearly, as an example in our case add function returns dictioanry with key as string and value as int, so return type argument for signature will be str: int . Similarly if you return array with int values it will be [int]. With above understanding our add function now looks like below.
@signature( str: int , int, int)
def add(a, b):
   return  'result': a + b 
and now code worked just fine!. What I couldn't figure out here is there is no way to have tuple as return value or argument, but I guess that is not big deal. So immidiate task for me after finding this is fix the link in documentation to point to wsme.signature and probably put some note some where in documentation about above finding.

Daniel Pocock: Click to dial for mobile users of your web sites

If there was a trivial way to let mobile phone users call you from your web site, just by adding a single HTML element to the page, would you do it? In fact, there is. It doesn't even require a mobile WebRTC browser. It works for virtually any smartphone and a growing number of desktops too. Introducing the tel: URI The tel: URI is defined in RFC 3966. For most mobile phone users, if they click a link to a tel: URI, their browser will copy the link into their dialer for convenience. To protect users against calls to 0900 premium rate numbers, the user still has to make one more click to confirm they want to dial. Examples Here is a tel: URI:
tel:+44-20-7135-7070
Here is how to create a link with it: <a href="tel:+44-20-7135-7070">020 7135 7070 (from abroad: +44 20 7135 7070)</a> and here is how it looks on the page:
Call me on 020 7135 7070 (from abroad: +44 20 7135 7070)
(Note: some planet aggregation sites block the link in the example) and here is what appears on the mobile device after a user clicks the tel: URI link: For desktop users too Many desktop users can also benefit from tel: URIs. If they have a modern telephone system in their office, the system administrator may have already added a tel: URI handler to their desktop. Anyone with a software PBX or a SIP account can also potentially use the TBDialOut extension for Thunderbird to help convert address book phone numbers into tel: or sip: URIs or even URLs for some bespoke dialer. For those who want extra convenience, the Telify extension for Firefox will look for phone numbers in any HTML page and display them as tel: URIs so you can click them even if the web developer overlooked this.

2 June 2014

B lint R czey: I Can Hear Music again (thanks to forked-daapd/Debian)

When I started looking for a lightweight solution of serving a music library over LAN I did not expect so many complications. I expected it not to be a unique need to have something running on a SheevaPlug straight from the Debian repository. Apparently it kind of was. Debian used to have mt-daapd (popcon: 165), but now it is available from oldstable only and upstream is dead. There is tangerine (popcon: 98) with its Mono dependencies and GUI which seemed to me overkill and more like a demo of a networked application written in Mono than a music library server. The most promising candidate was forked-daapd (popcon: 220) but it was far from being a true winner. First, it had a series of dead upstreams. At the beginning it was forked from mt-daapd (hence the name) by Julien Blache who also served as the prior Debian maintainer. Then the code base was forked and converted to use Grand Central Dispatch. Then the GCD fork died off slowly as well a few years ago. When I found the package it had been unmaintained for a few years and was based on the GCD branch which prevented building it on many architectures and the server itself was crashing or quitting occasionally. Luckily there still existed a fork thanks to Espen J rgensen which was well maintained and could serve as a way out but examining it closely it turned out that it had switched to libevent from GCD but to a version (1.4) which is present only in oldstable! And some say Debian s software versions are ancient ;-). Moreover it was not simply libevent 1.4-based, but it included some heavily patched parts of it. Espen also liked the idea of packaging his version in Debian and we extracted the patches to libevent and slowly got them accepted to libevent s master. Forked-daapd s master works best with libevent 2.1.4-alpha, but thanks to Espen the development branch now also works with libevent 2.0.x giving up some performance and a little feature. This was a long journey, but finally Espen s forked-daapd became ready for being used as a new upstream of the Debian package thus please welcome 20.0+git20140530+gc740e6e-1, the first version of forked-daapd building on all architectures for a very long time and a prime candidate for being the music library server in Jessie (and wheezy-backports, soon)! Testing, bug reports are always welcome! From the package description:
 forked-daapd is an iTunes-compatible media server, originally intended
 as a rewrite of Firefly Media Server (also known as mt-daapd).
 It supports a wide range of audio formats, can stream video to iTunes,
 FrontRow and other compatible clients, has support for Apple's Remote
 iPhone/iPod application and can stream music to AirTunes devices like
 the AirPort Express.
 It also features RSP support for Roku's SoundBridge devices.
 Built-in, on-the-fly decoding support enables serving popular free music
 formats like FLAC, Ogg Vorbis or Musepack to those clients that do not
 otherwise support them.

Russ Allbery: Review: Debt

Review: Debt, by David Graeber
Publisher: Melville House
Copyright: 2011, 2012
Printing: October 2012
ISBN: 1-61219-129-0
Format: Trade paperback
Pages: 453
You probably remember this story from introductory economics. Originally, people exchanged things through barter. I needed grain but had a cow. You had a farm but needed milk. I gave you milk for your grain. But this was tedious and awkward, and required finding the right combination of people who needed something the other person had on hand. Then, people invented money: small objects with an agreed-upon value that you could keep and use later when you needed something else. In other words, both a medium of exchange and a store of value. And that improved matters for a long time, although war-torn societies or societies that collapsed (the supposed "Dark Ages" often raises its head) would sometimes "revert to barter" for some period of time until things were stable enough for currency to reappear. Following that story was usually some story about the emergence of money based on credit: goldsmith shops that started a side business in storing other people's coins and giving them receipts, leading to the receipts trading like the coins since the shops were trustworthy, and from there into the Bank of England and eventually the fractional reserve banking system, fiat money, and all the modern machinery of finance. All of this was dated from the early Enlightenment and the development of modern finance in Europe. It's a very neat story, and it makes a great deal of intuitive sense. That barter system does feel like what you'd have to do without money, but one can immediately see how obnoxious and limiting it would be. These stories play into our intuitive sense of history: people started with emergent properties of the physical world (different people have different goods and different skills and want to exchange them) and then develop layers of abstraction on top of them, eventually leading to the sophistication of modern societies. However, David Graeber is not an economist. He's an anthropologist: the profession devoted to understanding how people actually do things rather than how we've reconstructed our history based on our modern perspective. And, as he points out, engagingly and comprehensively, in chapter two of Debt, there is no evidence that this story about economic history has anything whatsoever to do with reality. And quite a bit of evidence that it does not. As best as we've been able to determine, not only is there no society in the world that deals with routine, day-to-day needs like grain and milk through barter, there never has been such a society in human history. Instead, history and anthropology shows that credit is, in a sense, older than currency: the earliest recorded economic transactions were built on a rich system of credit, but in the form of purchases from shopkeepers on credit, or credit clearinghouses through the local government or temple. Those credit records were often denominated in some standardized commodity so many cattle or bushels of grain that could create the impression that the economy worked on barter. But the anthropological evidence indicates that this was more an accounting technique than a practical currency. People rarely brought the named commodity to the temple to pay off some debt. Rather, there was an agreed conversion from various other goods to that standardized commodity, and its primary purpose was consistent bookkeeping. Specie minted coins appear to come later, and wax and wane throughout history depending on local circumstance. For example, Europe did not "revert to barter" after the collapse of the Roman Empire, but the inhabitants did stop using specie and returned to a system of credit and record-keeping... records that continued to be denominated in Roman currency, even though few people still used the actual coins. That's one fascinating observation with which Graeber begins this book. The other is the question of why we have such a strong social and moral belief that people must pay their debts. This moral belief is ever-present in discussions about the 2008 financial collapse, and more broadly in discussions about the modern economy, but it's not as obvious of a belief as it might appear on the surface. After all, the banking and investment system is founded on the principle that not everyone will repay their debts, and therefore lenders receive a risk premium based on the likelihood that the debt won't be repaid. But, despite building the possibility of non-repayment into the system, debt forgiveness or intentional default is almost unthinkable and considered a huge moral problem. To this, Graeber brings the perspective of historical anthropology: human societies have struggled with the problems of debt and repayment from the beginning of recorded history, and have attempted a wide variety of solutions to those problems, including massive debt forgiveness. The jubilee described in the Bible was not novel; rather, it reflected a common practice to keep abuses of debt under control in ancient Sumer. The subtitle of Debt is The First 5,000 Years, and this book is a historical survey. But Graeber puts off the history to first lay an intellectual groundwork for our understanding of debt, and I found that preliminary discussion extremely valuable. Most memorable was the way Graeber divides human economic relationships into communism (in the old sense, not the political sense), exchange, and hierarchy. Capitalism has consumed our economic analysis to such a degree that exchange is the only economic basis that gets much discussion, but the other two are both obvious and pervasive once Graeber points them out. Human civilization could not exist without all three. And Graeber also points out one aspect of exchange-based economics that had not previously occurred to me: it's the economic relationship that one creates with strangers. Debt has the unique characteristic that it can be discharged, at which point the relationship ceases. This has far more complex and far-reaching moral and social implications than one might initially realize, and Graeber did a wonderful job opening my eyes to some of the subtleties. Debt is clearly a scholarly work, but Graeber's writing is clear and engaging. I found most of this book to be surprisingly easy reading. The hardest going was Graeber's discussion of societies that use a form of currency to arrange relationships between people (marriages, births, and deaths, primarily), but not day-to-day economic transactions. I suspect this area is closer to Graeber's areas of personal research and field work, which resulted in more technical detail. I'm still not sure I completely grasp the principles that Graeber was trying to communicate. But I was struck by the observation of alienation's role in turning a human being into a commodity, and how that links with debt's role as the economic transaction one has with strangers. Graeber covers slavery only glancingly, but makes some memorable points about the use of violence to rip someone out of their social context, and how that is necessary in human cultures before humans can be reduced to a commodity. There's a lot here, and I've only scratched the surface. I haven't mentioned, for example, the fascinatingly elegant theory that coining money and then requiring taxes be paid in the same money is a simple and highly effective way of funding armies, an explanation for specie that is largely unproven but that I find more compelling than the ones I've previously heard. Approaching debt from an anthropological instead of economic perspective is surprisingly enlightening. Debt is primarily a historical and cultural discussion rather than a set of proposed solutions, but Graeber does effectively show that debt as a moral obligation is not an unquestionable moral stance, but rather has a long history as one side of a two-sided political debate. I also came away from this book more conscious of the social implications and costs of debt-structured interactions, and wanting to push more of the language of debt out of my day-to-day dealings. Graeber is well known as one of the supporters of Occupy Wall Street, and Debt, while a well-defended academic work, certainly does advocate a position. But the academic analysis is more prominent than the advocacy, and I found his positions well-defended and well-argued. I do need to give the caveat that I don't have the anthropological background to distinguish the statements from Graeber that are well-established common knowledge in anthropology from the ones that are more controversial, and I would be a bit leery of taking this book as the final word on the topic. But it fully deserves its popularity and reputation as a thought-provoking and valuable contribution to the conversation. It's another book that I want to re-read someday to digest further, and the sort of book whose observations keep occurring to me in subsequent discussions or news stories. If you're at all interested in the way in which we construct the morality around economics and debt, I think this is a book that you should read. It's thoughtful, challenging, and surprising, and it passes my acid test for books of this sort with flying colors: after reading it, you realize that many things are more complicated, more historical, and less novel than you had originally thought. Highly recommended. Rating: 9 out of 10

1 June 2014

Antonio Terceiro: An introduction to the Debian Continuous Integration project

Debian is a big system. At the time of writing, looking at my local package list caches tells me that the unstable suite contains 21306 source packages, and 42867 binary packages on amd64. Between these 42867 binary packages, there is an unthinkable number of inter-package dependencies. For example the dependency graph of the ruby packages contains other 20-something packages. A new version of any of these packages can potentially break some functionality in the ruby package. And that dependency graph is very small. Looking at the dependency graph for, say, the rails package will make your eyes bleed. I tried it here, and GraphViz needed a PNG image with 7653 10003 pixels to draw it. It ain t pretty. Installing rails on a clean Debian system will pull in another 109 packages as part of the dependency chain. Again, as new versions of those packages are uploaded the archive, there is a probability that a backwards-incompatible change, or even a bug fix which was being worked around, might make some funcionality in rails stop working. Even if that probability is low for each package in the dependency chain, with enough packages the probability of any of them causing problems for rails is quite high. And still the rails dependency chain is not that big. libreoffice will pull in another 264 packages. gnome will pull in 1311 dependencies, and kde-full 1320 (!). With a system this big, problems will arrive, and that s a fact of life. As developers, what we can do is try to spot these problems as early as possible, and fixing them in time to make a solid release with the high quality Debian is known for. While automated testing is not the proverbial Silver Bullet of Software Engineering, it is an effective way of finding regressions. Back in 2006, Ian Jackson started the development of autopkgtest as a tool to test Debian packages in their installed form (as opposed to testing packages using their source tree). In 2011, the autopkgtest test suite format was proposed as a standard for the Debian project, in what we now know as the DEP-8 specification. Since then, some maintainers such as myself started experimenting with DEP-8 tests in their packages. There was an expectation in the air that someday, someone would run those tests for the entire archive, and that would be a precious source of QA information. Durign the holiday break last year, I decided to give it a shot. I initially called the codebase dep8. Later I renamed it to debci, since it could potentially also run other other types of test suites in the future. Since early January, ci.debian.net run an instance of debci for the Debian Project. The Debian continuous Integration will trigger tests at most 4 times a day, 3 hours after each dinstall run. It will update a local APT cache and look for packages that declare a DEP-8 test suite. Each package with a test suite will then have its test suite executed if there was any change in its dependency chain since the last test run. Existing test results are published at ci.debian.net every hour, and at the end of each batch a global status is updated. Maintainers can subscribe to a per package Atom feed to keep up with their package test results. People interested in the overall status can subscribe to a global Atom feed of events. Since the introduction of Debian CI in mid-January 2014, we have seen an amazing increase in the number of packages with test suites. We had little less than 200 packages with test suites back then, against around 350 now (early June 2014). The ratio of packages passing passing their test suite has also improved a lot, going from less than 50% to more than 75%. There is documentation available, including a FAQ for package maintainers with further information about how the system works, how to declare test suites in their packages and how to reproduce test runs locally. Also available is development information about debci itself, to those inclined to help improve the system. This is just the beginning. debci is under a good rate of development, and you can expect to see a constant flux of improvements. In special, I would like to mention a few people who are giving amazing contributions to the project:

31 May 2014

Dirk Eddelbuettel: RcppGSL 0.2.1 and 0.2.2

A few days ago, version 0.2.1 of RcppGSL---our interface package between R and the GNU GSL using our Rcpp package for seamless R and C++ integration---appeared on CRAN making it the first release in some time. And it turned that this version tickled an obscure and long-dormant bug under clang which was found on OS X Mavericks---which Kevin Ushey consequently squashed. So this is now reflected in version 0.2.2 which just arrived on CRAN. Besides the bugfix, a few things were modernized to reflect capabilities of Rcpp 0.11.0 and later. The releases also contain a few changes that had accumulated since the previous release in 2012 such as an additional example using B-splines, and use of updated vignette build options provided by R. The NEWS file entries follows below:
Changes in version 0.2.2 (2014-05-31)
  • A subtle bug (tickled only by clang on some OS versions) in vector and matrix view initialization was corrected by Kevin Ushey
Changes in version 0.2.1 (2014-05-26)
  • Added new example based on B-splines example in GSL manual illustrating simple GSL use via Rcpp attributes
  • Vignette compilation has been reverted to using highlight since version 0.4.2 or greater can be used as a vignette engine (with R 3.0.* or later).
  • Vignette compilation is now being done by R CMD build as R 3.0.0 supports different vignette engines, so the vignette build process has been simplified. A convenience helper script has also been added for command-line builds.
  • Unit tests now use sourceCpp() instead of cxxfunction() from the inline package
  • The DESCRIPTION file now uses Suggests: Rcpp (instead of Depends: Rcpp) to permit building of the vignette
  • The package now takes advantage of the simplified build process available with Rcpp (>= 0.11.0)
  • Similar updates to the build process were made for the example package included with RcppGSL
And courtesy of CRANberries, a summaries of changes to release 0.2.0 and this week's release 0.2.1 are available. More information is on the RcppGSL page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

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

29 May 2014

Petter Reinholdtsen: Free software car computer solution?

Dear lazyweb. I'm planning to set up a small Raspberry Pi computer in my car, connected to a small screen next to the rear mirror. I plan to hook it up with a GPS and a USB wifi card too. The idea is to get my own "Carputer". But I wonder if someone already created a good free software solution for such car computer. This is my current wish list for such system: If you know of any free software car computer system supporting some or all of these features, please let me know.

28 May 2014

John Goerzen: Review: The Wheel of Time

Five years ago, I opened The Eye of the World, the first book in the Wheel of Time series, and read:
Lord of the Morning, he said, I have come for you.

On the island, the air shimmered and coalesced. The black-clad man stood staring at the fiery mountain rising out of the plain. His face twisted in rage and contempt. You cannot escape so easily, Dragon. It is not done between us. It will not be done until the end of time. Then he was gone, and the mountain and the island stood alone. Waiting.
And then, as often, Robert Jordan began books citing some of the prophecy he invented:
And it came to pass in those days, as it had come before and would come again, that the Dark lay heavy on the land and weighed down the hearts of men, and the green things failed, and hope died. And men cried out to the Creator, saying, O Light of the Heavens, Light of the World, let the Promised One be born of the mountain, according to the prophecies, as he was in ages past and will be in ages to come. Let the Prince of the Morning sing to the land that green things will grow and the valleys give forth lambs. Let the arm of the Lord of the Dawn shelter us from the Dark, and the great sword of justice defend us. Let the Dragon ride again on the winds of time. from Charal Drianaan to Calamon,
The Cycle of the Dragon.
Author unknown, the Fourth Age
And then, the grand opening to each of the books in the 11,000-page series, something like this:
The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, called the Third Age by some, an Age yet to come, an Age long past, a wind rose in the Mountains of Mist. The wind was not the beginning. There are neither beginnings nor endings to the turning of the Wheel of Time. But it was a beginning. Born below the ever cloud-capped peaks that gave the mountains their name, the wind blew east, out across the Sand Hills, once the shore of a great ocean, before the Breaking of the World. Down it flailed into the Two Rivers, into the tangled forest called the Westwood, and beat at two men walking with a cart and horse down the rock-strewn track called the Quarry Road.
And yesterday, 11,000 pages later, I have completed the series. Really, how could I have put down a book with such a majestic beginning as that? It hinted at the epic that was to come, the amazing literature I was going to read. I didn t read it straight through; I enjoyed books like War and Peace along the way. But what a trip the Wheel of Time series was. The characters were so detailed, so deep, the setting so elaborate, the plots so grand and also so small everyone from servants to queens were well-represented in the books. Not every section was a page-turner; in fact, around the 4th or 5th book, the series started to plod for a thousand pages or two, reading more like a history book than a novel. Sometimes the prejudices and stereotypes of the characters, particularly the sexism that both the men and women displayed, were frustrating to read. I never quite figured out of this was brilliant writing (making the reader feel frustrated at the plodding pace of the book when it was describing characters being frustrated at the plodding pace of events), or if it could have been trimmed down by 2/3 in some places. But really, the number of brilliant endings, laugh-out-loud situations, and page-turning suspense that somehow managed to build over hundreds, and then even thousands of pages, outweighed the flaws.
Politics is a foggy mire full of snakes. - The Eye of the World
Ah. Furlan washed his hands in one direction, then rubbed them in the other. Ah. Forgive me, Master Andra, but Lady Alys is a fierce sounding woman. Only with those who displease her, Lan said blandly. Her bite is far worse than her bark. Ah. Ah. Ah. Your rooms are this way. . . - The Dragon Reborn
One of the marks of truly good writing is that I leave a book or series with a sense of sadness or nostalgia, leaving characters that seem almost like friends. I felt that after finishing the last book in the series, A Memory of Light. The ending was deep, and satisfying, but ultimately left me wanting even more even more than 11,000 pages, somehow.
Elienda and Briain woke from the dream. She might have been speaking of the weather rather than two deaths among women she knew. We all must wake eventually. - Knife of Dreams
I was often touched by the way the Aiel referred to each other. A desert people, their fond farewall was may you always find water and shade. A fitting metaphor for anyone s life, I think. And they referred to their spouse as shade of my heart. Jordan touched on quite a few themes of religion and philosophy. In that quote above, he has the Aiel referring to death as waking from a dream. An intriguing metaphor, isn t it? He even writes conflicts of philosophy, religion, and culture into the series. I was particularly impressed with his treatment of theodicy and the problem of evil (the argument and religious response relating to the presence of evil in the world in the face of a loving God.) It is the most impressive treatment I have seen in fiction, and does a better job of advancing the theodistic argument than many philosophers have, I suspect. It is hard to really go into that one here because of the length and potential for spoilers. I can, however, comment on his treatment of existential nihilism the theory that life and the universe is without meaning, and the sometimes-related comment that what does anything matter then anyway? Here are a couple of quotes:
In Maradon, I saw what had been done to men who followed me. I saw Light in them, Min. Defying the Dark One no matter the length of his shadow. We will live, that defiance said. We will love and we will hope. And I saw him trying so hard to destroy that. He knows that if he could break them, it would mean something. Something much more than Maradon. Breaking the spirit of men he thirsts for that. He struck far harder than he otherwise would have because he wanted to break my spirit. His voice grew softer and he opened his eyes, looking down at her. And so I stood against him. - Towers of Midnight
What if I think it s all meaningless? he demanded with the loud voice of a king. What if I don t want it to keep turning? We live our lives by the blood of others! And those others become forgotten. What good is it if everything we know will fade? Great deeds or great tragedies, neither means anything! They will become legends, then those legends will be forgotten, then it will all start over again!

Why? Rand thought with wonder. Because each time we live, we get to love again.

It felt relaxing to stare out at that distant light, so welcoming and noble. Storms will soon come, it seemed to say. But for now, I am here. I am here. - The Gathering Storm
I unfortunately can t put in in its proper context due to spoilers, but it is a pivotal turning point in the series, relating to the preservation of the world. By giving what we might normally call a characteristic or behavior evil an almost-human voice and character, it can be discussed in interesting ways.
We are always more afraid than we wish to be, but we can always be braver than we expect. Hold on to your heart, and the Aes Sedai cannot harm what is really you, your heart. They are not nearly so far above us as we believed. May you always find water and shade, Egwene. And always remember your heart. - Lord of Chaos
Eben is dead. Would you want to forget your pain if you lost that hulking giant of yours? Have your feelings for him cut away like some spoiled chunk of flesh in an otherwise good roast? - The Gathering Storm
These quotes are examples of characters in the series dealing with difficult situations. In one, a character is yelled at for offering to use her special powers to numb the pain of another person over a death. It brings up a question that those of us that have known pain might find interesting: would we really have wanted our pain erased? And suggests perhaps not. That there is a benefit to it. That we get through it by embracing it by embracing it while still being true to our heart.
He had four rules concerning action and information. Never make a plan without knowing as much as you can of the enemy. Never be afraid to change your plans when you receive new information. Never believe you know everything. And never wait to know everything. - Lord of Chaos
Sometimes the series treats us to logical thinkers, whether they are generals or innkeepers, and gives us little tidbits like this one.
Androl brushed off his hands, smiling. Children were so adaptable. Before them, centuries of tradition, terror and superstition could melt away like butter left too long in the sun. - Towers of Midnight
And sometimes, things to chew over. Isn t that an interesting comment on prejudice? Children aren t born prejudiced; we can see how easily they make friends with anyone. It is sad that we teach them to be, isn t it? Wheel of Time is a fine story, expertly woven. But it is not just a story. It is true, in the sense that it illuminates truths, just like Romeo and Juliet can. In it, I see lessons and echoes of the civil rights era, comments on what makes good leaders, characters wrestling with decisions without adequate data, people putting on a mask of emotions, sacrifice, and the overall theme of the entire series: the power of love and compassion. The inspiration of the series for me well, it is there, but it may take a few more days to figure it out. I think it has something to do with this: The wind rose high and free, to soar in an open sky with no clouds.

Next.

Previous.