Search Results: "ema"

13 January 2012

Raphaël Hertzog: People Behind Debian: Steve McIntyre, debian-cd maintainer, former Debian Project Leader

Steve McIntyre has been contributing to Debian since 1996, 2 years before I joined! But I quickly stumbled upon Steve: in 1999, he was struggling with getting his debian-cd script to produce 2 ISO images (it was the first time that Debian did no longer fit on a single CD), I helped him by rewriting debian-cd with a robust system to split packages on as many ISO images as required. I remember those times very well because Steve was very supportive of my efforts and it was a real pleasure to get this done. His friendly nature probably also explains why he got elected Debian Project Leader twice! Anyway, enough history, check out his interview to learn more about the great work he s doing nowadays. My questions are in bold, the rest is by Steve. Raphael: Who are you? Steve: I m a professional software engineer, 37, living in Cambridge (England) with my new wife Jo. I studied for the EIST degree at the University of Cambridge, then (like many people here, it seems) I just forgot to go home again afterwards and settled here. I spent more of my study time playing with Linux than working on my degree, so I guess I m lucky that it worked and I found a career in that area! Raphael: How did you start contributing to Debian? Steve: During my time in college, I started hacking on software in my free time, using Slackware as my first Linux distribution from the middle of 1994. After encountering more and more problems with Slackware, I was encouraged by a number of friends to make the jump over to Debian and in October 1996 I did. The installation process back then was much harder than anything people see today, but after a long weekend I finally had my Debian system up and running. I was already one of the main upstream developers for the Mikmod music player at that time, so that very same weekend I applied to be a DD so I could maintain it in Debian too. Back then, the NM process was much simpler: I just mailed a key to Bruce and he set me up with an account almost immediately! I then found that Joey Hess had beaten me to it and already packaged Mikmod. Grrr! :-) Raphael: What s your biggest achievement within Debian? Steve: Without a doubt, my proudest achievement within Debian is being elected Project Leader for 2 years by the other developers. It s a great feeling to have earned the trust of your friends and peers, and also a great responsibility to go and help Debian where needed: talking to the press about Debian, assisting wherever problems crop up, etc. The DPL job is certainly a lot of hard work, and I have nothing but respect for anybody who volunteers for it.
It s a great feeling to have earned the trust of your friends and peers.
Elsewhere, I ve been leading the Debian CD team for years too, both doing most of the maintenance of the debian-cd package and producing and testing the regular installation CDs and DVDs that we ship to the world. Again, this is a time-consuming job but it needs doing and it s worthwhile. Raphael: You re currently employed by ARM. What are you working on and are they supportive of your Debian involvement? Steve: The situation within ARM is very interesting; I m employed in PDSW (Processor Division, SoftWare), a new group founded just a couple of years back to help improve the state of software on ARM. Most of the people in the group are working on Free Software at this stage (e.g. toolchains, browsers, Linux kernel), which is lovely. Some of the engineers have also been seconded into a new non-profit company Linaro, which is a collaboration between ARM and a number of other companies investing in core Linux software and tools for ARM-based CPUs. I m one of the ARM engineers in Linaro, and I m a Technical Architect in the Office of the CTO. My role includes looking at future projects for Linaro to help with (e.g. ARM servers), but for the last few months I ve been concentrating on the new armhf architecture in Debian, Ubuntu and elsewhere. armhf is a new architecture in Debian and Ubuntu terms, but it s not strictly a new type of hardware. Instead, it s a new ABI. We have two reasons for doing this work:
  1. It targets the latest version of 32-bit ARM CPUs (v7) and makes better use of the hardware, for better performance. Compare targetting i686 instead of i386, for example. We ll still support the older armel port for the foreseeable future for users with older hardware that can t run armhf.
  2. More importantly: we are standardising on the ABI / compiler options / hardware support for future users.
In the past, there has been a huge amount of specialisation (aka fragmentation) in the ARM Linux environment, and that worked OK for specialised devices that only ever ran the software shipped with them. ARM CPUs are now becoming more and more mainstream, so people will expect to be able to install generic software on their machines. That gives a requirement for a standard base platform, and armhf (arm-linux-gnueabihf in GNU triplet terms) is that standard that we are pushing in the community. Debian, Ubuntu, Fedora, Suse and others are all going to use this, making compatibility possible. I ve been working with a small team of people to make armhf happen, helping where needed: putting together build machines; patching Debian packages directly; discussing and fixing toolchain issues with Ubuntu folks; agreeing ABI specifications with people from Fedora; advising people from other distros bootstrapping their new ARM ports. ARM and Linaro are very supportive of this work, and it s been lovely being sponsored to work directly on Free Software like this. It s work that will directly benefit ARM and its partners (of course!), but it s also helping out more generally too: Debian QA work, cross-build support, bootstrapping efforts, multi-arch. More and more of the ARM market is driven by Free Software, and companies are acknowledging that. I should probably also mention that we re hiring ! :-) Raphael: What are your plans for Debian Wheezy? Steve: There are three main tracks here. Obviously, I m interested in seeing armhf release with Wheezy. We ve just been added to Testing last weekend, so that s going well. We ve got over 90% of the archive built now, and we re mopping up the remaining issues. I m the primary maintainer of cdrkit at this point, but I d prefer to have it go away. Xorriso and the associated software in libisoburn is almost capable of replacing all the aging cdrtools-derived software that we have in Debian, The only missing feature that I m aware of is creating the HFS hybrid filesystems that we use for installations on Mac systems. I ve been talking with the upstream folks about this for some time already, and I m hoping we can finish this soon enough that we can get it into Wheezy. Finally, I ve got the ever-growing wishlist of things for debian-cd. We ve got the beginnings of an automated test suite that Mart n Ferrari has written, but it needs integrating and improving. I want to help get regular weekly/daily/release debian-live builds running on the main CD build machine. There s work needed if we want to make good installation media for the new multi-arch world, too. The Emdebian people are asking for help making CD images The list goes on :-) Raphael: The ARM community seems to be very interested in multi-arch. Can you explain why? Steve: There are a number of reasons for ARM people to be interested in multi-arch; two really stand out for me:
This is potentially the killer app for multi-arch: simply install the libraries for the target architecture [ ], install a simple cross-gcc package [ ] and you re all set.
Raphael: What s the biggest problem of Debian? Steve: For me, Debian s biggest problem has been the same for a long time: we are forever short of enough people to do the work that we re trying to do. That might sound like a weird thing to claim when Debian is one of the largest Free Software projects on the planet, but it s more a statement of just how huge our goals are. Many of the largest things in Debian are developed or controlled by very small teams working very hard, and there s always a risk of losing people due to burnout in those situations.
We are forever short of enough people to do the work that we re trying to do.
Some of the tasks that should be easy given our large membership (e.g. large-scale packaging transitions) can often instead take a very long time. We are fortunate to have more people wanting to join in Debian s work all the time, but we also need to be careful to keep on promoting what we re doing and recruiting new contributors, encouraging them to get more and more involved in core work. Debian gets ever bigger in terms of the size and the number of packages we distribute; we re not currently matching that growth rate elsewhere. Raphael: What motivates you to continue to contribute year after year? Steve: This one is much easier to answer! The thing that first attracted me to Debian was the fact that I could help to develop it, help to decide how things could and should be done within it. Instead of being forced to accept what some corporation decided I could do with my computer, I could change the software to suit my needs and preferences. Alongside that, I could get involved with a strong community of similar people all over the world, all with their own strong opinions about how software should work. I joined in and found it was great fun and very rewarding. That hasn t changed for me in the intervening years, and that s why I m still around. I work on Debian because it helps me to get the OS that I want to use. It seems that lots of people around the world find it useful too, and that s awesome. :-) Raphael: Do you believe that Stefano Zacchiroli will be the first DPL who managed to stay 3 consecutive years on the seat? Would you like him to candidate again? Steve: To be honest, I would be very surprised if Zack stood again for DPL this year. He told me himself that he wasn t planning on it, and I can understand that decision. He s been an awesome DPL in my opinion, and I m glad that he took the job. But: it is also a very difficult and time-consuming task that would be enough to wear down anybody. If Zack does decide to stand again, I would support him 100%. But I know that we also have lots of other good people in Debian who would be ready to take up the challenge next. Raphael: Is there someone in Debian that you admire for their contributions? Steve: There are lots of people I admire in Debian, so many so that I almost don t want to list individuals here for fear of missing people out. But :-) Bdale Garbee has been an inspiration to many of us, for many years. He s technically excellent, a great friend to many of us, an endless source of sage advice and (last but not least) he has some wonderful stories to tell about his experiences over the years. On top of that, he s just cool. :-) Christian Perrier is another exceptional developer, in my eyes he s great at co-ordinating people in translations, working tirelessly to make this very important part of Debian work better and better with every release. He s also a really nice guy and we all love him. I also have to mention Joey Hess here, whether he likes it or not. *grin* He s been responsible for so many good things in Debian over the years, even if he did steal my first package Finally, the teams of people who make sure that Debian is always working: the security team and DSA. The rest of us can choose to take time off from Debian to go and do other things, but these people need to cover things every day. That s a major responsibility, and I salute them for taking on that challenge.
Thank you to Steve for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that you can find older interviews on http://wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

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

Alexander Reichle-Schmehl: Release Critical Bug report for Week 02

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:
In Total:1537
Affecting Wheezy:900
Wheezy only:188
Remaining to be fixed in Wheezy:712
Of these 712 bugs, the following tags are set:
Pending in Wheezy:48
Patched in Wheezy:111
Duplicates in Wheezy:45
Can be fixed in a security Update:24
Contrib or non-free in Wheezy:11
Claimed in Wheezy:0
Delayed in Wheezy:2
Otherwise fixed in Wheezy:46
Ignoring all the above (multiple tags possible) 477 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released. However, with the view of the Release Managers, 799 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

C.J. Adams-Collier: The Very Model of a Poster to CLPM

So, in 2002 I attended my first SPUG meeting. Also in attendance were Randal, Tim, J.P. (I think) and quite a few of the other usual suspects. The guest speaker was the inestimable Dr. Damian Conway. This night might be the single most important event in my career as a builder of the internets. I was already set in my ways regarding my operating system, and I knew enough perl to get by, but I wasn t in touch with any users groups until then. The crown jewel of the night was Damian s recital in full of his poem, I Am The Very Model of A Poster To CLPM (sung to the tune of that song from Pirates of Penzance). I must admit that I d never heard of CLPM and that it all sounded like gobble-de-gook at the time. If I recall correctly, this happened just after he took about 10 minutes to teach us all to pronounce the name of then-Pumpking, Jarkko Hietaniemi. This was the same year that the following video was made <iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="http://www.youtube.com/embed/XkU_GQVOCqo" width="420"></iframe> With that in mind, there s one more thing I need to share with you before disclosing the lyrics. This piece was developed during a time when it was common for members of the perl community to flame one another on news feeds, take their anger and frustration out on newbies and generally be the bane of most of the internet. I like to think that it helped to shape me into a kinder, gentler perl programmer, debian user and general netizen over the years. I would also like to think that it will do the same for future members of our communities. And so, without further ado, Damian Conway s
I Am The Very Model of a Poster to CLPM Now everything I need to know about the Perl community
I learned in kindergarten when I was a little lad of three
And in these next few minutes I ll relate those five apothegm
For I am the very model of a poster to c.l.p.m. The first truism I was ever taught upon my mother s knee
Was that our dad s a better dad than their s could ever hope to be.
His name is Larry Wall, and that s determinism nom native
Since of the mural attributes he demonstrates proof positive. He s eight feet tall and ten feet wide; of granite-like solidity.
He wards us from the serpent s tabs and coffee bean s stupidity.
He guards us from that Gallic tower s B&D urbanity,
And makes sure we don t see sharp code that might cut loose our sanity. He watches over each of us, like Odin of the Norse belief
The stern All-Father figure and, at times, the comical relief.
So, if you vaunt our patriarch s supreme linguistic acumen,
You are a model sychophantic poster to c.l.p.m. The second tenet that I learned concerns, of course, the fairer sex
And why they are in short supply, while geek-boy JAPHs are multiplex.
As every schoolboy knows each conversation has single aim:
To raise one s own significance, whilst razing others down in flame. And thus good men and true who hold this principle as sacrosanct
Will all pursue beligerence as though they were from Mars. Or tanked.
It is the tenor of your newgroup posts that she from Venus flies:
Because most threads devolve into comparisons of ..meanness, guys. When every post affronts their own collaborative sorority
It must exasperate them, for it renders the majority
Of female Perl geeks absent, till we re forced to rename blonde Dutch men
To act as female models of a poster to c.l.p.m. The third grand aphorism that was drummed into my youthful head
Was: if you can t say something nice about someone, you should instead
Say every nasty thing you can impart, imagine, or invent
In any public forum that it happens you should both frequent. This goes especially for the young, and new, and shy, and innocent.
To flame a newbie is a joy, t will make you feel omnipotent.
To watch them squirm and bleat and bleed and scurry back into their hole,
The surge of ecstasy it brings is worth the way it eats your soul. So never hesitate to turn the wrath of your vocabul ry
Upon the hapless supplicant for Perl epistomology
And if you flame each FAQ, and every question that s beneath you then
You ll be the very model of curmudg nly R.T.F.M. The next point I should like to make s the obverse of the previous
For while it s true that to be newbie is a sin most grieveous
It ain t as bad as being old and greyed and staid and tedious
And sitting at the keys all day dispensing thoughts invidious. What right have you to tell me not to ask about my CGI???
I thought that Perl was all about website development, and I
Expect that you d extend to me the simple human courtesy
Of dropping everything so you can do this homework now for me. The Internet exists so I need never read the manual
And so my inane questioning can form a stream continual
While pleading for an email since I never read this group, as well
As posting them in jeopardy, in caps, and in HTML. The rule I learned in kinder that explains where this approach springs from
Is fundamental to a certain class of Gen-X hackerdom
The single principle that guides their Internet activity
Is: me, me, me, me, me, me, me, me, me, me, me, me, me, me, ME! So if you are prepared to treat the Net as your god-given right
And suck the newsgroups dry like some goodwill-devouring parasite
And use them as a help-desk and a perldoc substitute, well then
You are the very model clueless poster to c.l.p.m. The final precept that my pre-school inculcated in my head
Is one I would commend as antithetical to all I ve said.
It is a noble concept that once used to garner more elan
The idea that, when I grow up ..I want to be a fireman. The fire-fighter s job s to help, despite the inconvenience
And spare the inexperienced the cost of their own ignorance
And put out fires when the flames ignite the common living space
And through it all maintain an air of competence and skill and grace. And this, my friends, I recommend to all of our community
That rather than a careless match or carefully lit incendiary
You spray out knowledge, patience, and a gentle stream of good advice
And save the newbies from themselves, and oldies from their prejudice. And be yea more as Larry is, a fire-Wall against the threat
Of ignorance and arrogance, with both of which we re still beset.
For if you choose to help your fellow JAPHs instead of scorching them,
You ll be the next burnt offering we spit-roast on c.l.p.m. ;-) [edit]

11 January 2012

Jon Dowland: The Silent Land

I've just finished reading Graham Joyce's haunting The Silent Land: an atmospheric and moving love story set in an Alpine ski resort. Husband and Wife Jake and Zoe head out to the slopes early one morning and are caught in an avalanche. They survive, narrowly, but upon returning to the resort, everything has changed Anyone who has read any quantity of SF or fantasy will probably make an early guess at what's going on, and you'd most likely get it wrong. Even if you know where you're going, the journey is often the point, rather than the destination, and this journey is pretty gripping. I do most of my reading on the train to and from work. I often listen to music when I'm reading and I try to choose things which aren't going to distract my attention from the book too much. Film soundtracks are good; so is classical; so is a lot of Eno's work. For this book I mostly listened to the score from the latest film version of The Girl with the Dragon Tattoo, by Trent Reznor and Atticus Ross. Clocking in at only seven minutes shy of three hours, this is a haunting score that evokes a cold, isolated Swedish winter, and thematically matched the book perfectly. The score is a little less accessible than their previous work, but is rewarding on repeat listen. You can get a free 6-track sampler at the website linked above.

Craig Small: MediaServer with Rygel

Rygel XVI

Image by Cayusa via Flickr

Like a lot of people, I have one of those set-top TV boxes that can record TV shows at set times. I made sure that I could get at the files (using a FTP server in this case) and that the files were some sort of common standard (MPEG 4 TS). I also have a bunch of mp3 music files. That s fine when I m on the desktop because the files are local. I wanted to make these available to anyone in the household. DLNA seemed to be a reasonably OK way of doing this, the problem was, how to get it working in Linux? A lot of the problem is that it is hard to find a DLNA only server. Sure MythTV could do it, but it needs a tv tuner or a lot of fiddling around. XMBC can also do it, but it needs to be running a GUI. I even tried mediatomb but could not get the thing to compile as the library calls to mozjs were all using deprecated functions. I just wanted a daemon that served stuff, nothing more; no fancy ui, no need for X just file serving goodness. Rygel is almost that. You could say it is a user server much like a torrent client/server. The nice thing is you can fiddle around with rygel so it becomes close to a real server. This is how I did it. First, I made a rygel user with a home directory, but disabled login. I don t like programs running root if they don t need it and rygel doesn t need it. The home directory needs to be writeable to the rygel user too otherwise the program doesn t work too well. I use /var/local/rygel as its home. For the configuration, copy /etc/rygel.conf to ~rygel/.config/rygel.conf This is the configuration file for rygel. I disabled all of the modules except MediaExport. Make sure you disable Tracker otherwise MediaExport will not work. Tracker is only useful for real users who are logged in and have dbus etc going which this user is certainly not. I made a simple rygeld file in /usr/local/sbin which basically starts the program, forks and grabs the PID to write to a pidfile. This mean it was easier to track the program in the init scripts. 
#!/bin/sh
#
# Rygel daemon handling
RYGEL='/usr/bin/rygel'
RYGEL_ARGS=''
su -s /bin/sh -c "nohup $RYGEL $RYGEL_ARGS &gt; /var/local/rygel/rygel.log 2&gt;&amp;1 &amp;"
rygel
EXIT_CODE=$?
if [ $EXIT_CODE != 0 ] ; then
        return $EXIT_CODE
fi
PGROUP= ps --no-headers -o pgrp $$ 
PID= pgrep -g $PGROUP -f $RYGEL 
echo $PID &gt; /var/run/rygel.pid
exit 0
In case you were wondering, the pgrp finds the program group so the pgrep finds the right rygel process that has the same program group as the starting shell. The init script is a standard init script except the exec flag checks for /usr/bin/rygel but the start line starts /usr/local/sbin/rygeld This is because we want to kill the real rygel process but start it with the script. This setup works rather well. You do get some messages in the logfile about dbus not working but it is harmless. I tried disabling the mpris and external plugins but no matter what flag or configuration file option I tried, they would always try to start and fail with no dbus. Rygel is a a reasonably light-weight way of serving media to your home network. It idles 200 MB virtual with 16MB resident and when idle uses almost no CPU.
Related articles

10 January 2012

John Goerzen: Social Overload

I m finding social media is becoming a bit annoying. I enjoy using it to keep in touch with all sorts of people, but my problem is the proliferation of services that don t integrate well with each other. Right now, I have: So my problems are:
  1. Posting things multiple places. I currently can post on identi.ca, which automatically posts to twitter, which automatically posts to Facebook. But then I d still have to post to Google+, assuming it s something that I d like to share with both my Facebook friends and my Google+ circles it usually is.
  2. The situation is even worse for re-tweeting/re-sharing other people s posts. That is barely possible between platforms and usually involves cutting and pasting. Though this is somewhat more rare.
  3. It s probably possible to make my blog posts automatically generate a tweet, but not to automatically generate a G+ post.
All the hassle of posting things multiple places leads me to just not bother at all some of the time, which is annoying too. There are some tools that would take G+ content and put it on Twitter, but without a character counter on G+, I don t think this would be useful. Anyone else having similar issues? How are you coping?

9 January 2012

Craig Small: procps 3.32 Debian packages

Following up from the upstream release of a new procps, the debian packages have also been updated. This upload has a significant change in that, I hope, procps is now multi-arch compliant. To make this happen, the libprocps library is now in it s own package, separate from the binaries. It also means that if you have programs not from procps that link to this library they are now broken. I put in a Breaks: line for the three I know about (xmem, guymager and open-vm-tools) which will need a recompile with a small tweak in the control file and linked statements. As suggested in the multi arch implementation wiki page, I tested the libprocps0-dev package by compiling something against it, in this case another Debian package xmem. Doing this was very useful for teasing out some bugs on the dev package itself that did not appear while linking the library to the procps binaries. In short, the new procps has a lot fewer patches than the old ones and the next version will have less as I have already included the current changes into the upstream git repository. The main differences are now The three are really bugs, especially the last, which is why the patches will disappear next release.
Related articles

Steve McIntyre: Armhf buildds and status in Debian

Current status Back in September, I wrote about the machines that I set up to help bootstrap the new armhf port in Debian. Basing on Konstantinos' huge efforts in bringing up the new "architecture" in debian-ports, we started importing armhf into the main Debian archive on the 24th of November. Since then, those builders have been churning away night and day to build the huge collection of software that makes up the Debian archive. The current state can be seen on the armhf buildd status page, and there's a nice graph showing how quickly we've managed to run from 0 to over 90% of the archive here. (Click on the image for a larger version, or visit https://buildd.debian.org/stats/ for other versions. We overtook hurd-i386 quickly and are now ahead of the kfreebsd-* architectures. armhf bootstrap graph We've recently brought 3 more similar build machines online (hildegard, howells and hummel), again sponsored by the nice folks at Linaro but now hosted at the York NeuroImaging Centre at the University of York. This gives us both more build horsepower to keep up with building more different bits of Debian (experimental, updates etc.) and more redundancy in case of problems. We now have the vast majority of the archive built, and now a number of us are concentrating on fixing the remaining issues: language bootstraps and bugs. Also, on the 7th of January we were just added into testing, the next step on our path for inclusion as a Debian release architecture. Setting up the machines A lot of people have been asking me about the physical setup I showed in my last blog about these machines, so here's more details for those who are interested. Mount the 6 boards into the mini-rack, connect up the Molex power connectors to each board, attach ethernet cables and turn it all on! Each board comes with a micro-SD card containing uboot and an Ubuntu installation. I've configured uboot to boot off the hard drive directly, but leaving configuration available to use the Ubuntu on the micro-SD as a simple rescue system should the need arise. The Quickstart boards are not ideal physically for two reasons: the lack of SATA power, plus you need to push a power button on each board to boot it - they don't boot automatically the moment power is applied. However, they're quite inexpensive little machines and have done a great job of building the Debian archive so far! The ideal machines for us would also include more RAM at this point. CPU on these is adequate, but the larger C++ packages (yay webkit!) use a huge amount of memory at link time. Linking in swap is not the best thing, performance-wise... :-( UPDATE 2012-01-12: Ian tells me that the newer Quickstart-R boards apparently have a different power controller; these now boot up straight away without needing you to push a button. That sounds useful.

8 January 2012

Niels Thykier: Testing migration and package relations

While looking at the dpkg Breaks-field[0] 
$ aptitude show dpkg
Package: dpkg
[...]
Version: 1.16.1.2
[...]
Breaks: apt (< 0.7.7), aptitude (< 0.4.7-1), dpkg-dev (< 1.15.8), libdpkg-perl (< 1.15.8), pinfo (< 0.6.9-3.1), tkinfo (< 2.8-3.1)
it occurred to me that most (all?) of these relations were irrelevant to Britney when she migrated dpkg 1.16.1.2 to testing. Right now, at least the APT relations are only relevant if you are doing something like a distribution upgrade from Lenny/Squeeze to Wheezy. Similarly, the version constraints in a lot of dependency relations (e.g. libc6 (>= 2.11) ) are satisfied in testing and unstable at the same time. Removing the version constrains on dependencies is a rather minor thing as it is basically just a minor constant time optimization on each dependency check. However, removing an entire clause slightly reduces the problem size a bit. Particularly, the Conflicts/Breaks relations tends to be expensive for us. The first task was to identify the relations that can (or cannot) be simplified. In a Britney run we at most 4 versions of the same package per architecture, though usually only 1 or 2[1]. I devised a small set of rules to simplify the relations. These rules are applied to each package in the relation (atomic proposition, if you will).
  1. If the relation is versioned and it involves a virtual package in any suite, then do not change the relation in any way. Rationale: A virtual package cannot satisfy any versioned relation (Policy Manual 7.5)
  2. If the relation is a dependency (i.e. Pre-Depends or Depends) and the package is not available in any suite, then do not change the relation in any way.
  3. If the relation is versioned and the relation is satisfied in all suites (where the relationed-on package is available), then remove the version constrain. Rationale: If all (present) versions satisfy the relation, then version constrain does not change the semantics.
  4. If the relation is a conflict (i.e. Conflicts or Breaks) and relation is unsatisfiable in all suites, then remove the relation. Rationale: If none of the (present) versions satisfy the conflict-relation, then there is no conflict[2].
The rules are rather conservative in some cases and there is room for improvements. However, one has to remember that removing too few relations costs a bit in runtime, removing too many breaks testing and possibly a lot. Obviously, I prefer the former to the latter (especially because I will be a part of the clean up -crew). I tested my implementation of those four rules above against the current master branch. In short, it produces the same result as the master branch in all the tests so far. In the hand-made test-suite, the tests generally do not have any superfluous relations. Thus, it is slightly slower, though usually within 0.1 seconds of the master branch. On the other hand, in the live-data samples I have collected so far it does vastly better. For the longest run (sample from 2011-12-13), it reduces the runtime with ~70 seconds (from ~215 to ~145 seconds). In the other runs, it reduces total runtime with ~35 and ~2 seconds, respectively. In these samples, only the amd64 and i386 packages are considered (and human hints are ignored). For those interested, the code is available in my branch. :) [0] There is perfectly valid reason for doing that. I might get back to that in a later post. [1] One in unstable, testing, testing-proposed-updates and proposed-updates. The latter may seem a bit weird, but [0] [2] This is the rule that prune relations like the one in the dpkg Breaks-field. Edit: 2011-01/09, clarified that we have at most 4 versions per architecture.

7 January 2012

Jon Dowland: Flow My Tears, the Policeman Said

The Philip K. Dick Collection The Philip K. Dick Collection
I've just finished reading "Flow My Tears, the Policeman Said" by Philip K Dick, one of 13 novels collected in the Library of America's wonderful "The Philip K. Dick Collection" boxed set. This story has never jumped out at me as one to read with any particular urgency, despite the title being a reference to a composition by my namesake. I was reminded about it whilst listening to one of BBC Radio 4's "Great Lives" broadcasts, where Michael Sheen read a passage from the book. As an aside, the "Great Lives" series is a really interesting listen: I particularly enjoyed their episode on Ludwig Wittgenstein. You can get the whole series in podcast form. Back to the book. It features Dick's trademark theme of fractured realities, perhaps more so than in many of his more well-known works such as Ubik or A Scanner Darkly. It also has much better characterisation than I expect from his writing. His female characters remain as always sinister, threatening, mischevious, but they are at least fleshed out. There is a lot more of an exploration of the human condition than usual. Dick wrote that the novel begun as an attempt to explore different varieties of love. I enjoyed the mystery of the weird goings-on whilst they were mysterious, but I felt mildly let down when the explanation was eventually proffered.

Craig Small: rpath bites me again

Debian OpenLogo

Image via Wikipedia

It s funny, in bad way, when certain sorts of bugs come back to bite you. People may remember the fun debian had with rpath issues around in the late 90s where some binaries wanted to set the path of where their libraries were located. After much contraversy the consensus was at least in Debian (with some specific exceptions) RPATH is bad and don t use it. I lived through that fun and remember hacking libtool or autoconf or some such file. The horror of those times came back to haunt me today while working on procps 3.3.2 packages. lintian was suddenly complaining that binary-or-shlib-defines-rpath for all my binaries. I ve not seen rpath set for many years and as I m also part of the upstream and never saw it set there it took me a while to work out what was going on. Certainly, my binaries were setting the RPATH, it wasn t lintian getting the wrong idea. You can see this with objdump myfile grep RPATH. If you get a hit, you got RPATH set, an empty result means no RPATH. libtool was definitely setting the rpath, with 
cc -Iproc -g -O2 -o \$progdir/\$file pmap.o  ./proc/.libs/libprocps.so \
 -Wl,-rpath -Wl,/home/csmall/debian/procps/procps/proc/.libs \
 -Wl,-rpath -Wl,//usr/lib/x86_64-linux-gnu
That s not one rpath setting but two, for double insult. Configure flags such as disable-rpath wouldn t work. I flicked back to a pure upstream archive and there was no rpath there in either the compile flags or objdump. There was obviously some sort of side-effect going on. The problem, after much testing, was in the debian/rules file: 
        ./configure \
          --build=$(DEB_BUILD_GNU_TYPE) \
          --enable-watch8bit --enable-w-from \
          --prefix=/ \
          --mandir=\$$ prefix /usr/share/man  \
          --libdir=\$$ prefix /usr/lib/$(DEB_HOST_MULTIARCH)
The problem is above, and all it was was a / . libtool does some checking to see if the library directory exists and if it doesn t silently turns on rpath. It s not smart enough to know that //usr/lib/x86_64-linux-gnu is the same as /usr/lib/x86_64-linux-gnu and so it enables rpath. Removing the slash before the usr fixed the problem. I d say this is bad behavour on libtools part. It should know that / is // or all the other alternative ways of specifying paths. Hopefully this post will stop someone else wasting their time like I did.

6 January 2012

Alexander Reichle-Schmehl: Release Critical Bug report for Week 01

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:
In Total:1614
Affecting Wheezy:945
Wheezy only:148
Remaining to be fixed in Wheezy:797
Of these 797 bugs, the following tags are set:
Pending in Wheezy:47
Patched in Wheezy:135
Duplicates in Wheezy:45
Can be fixed in a security Update:28
Contrib or non-free in Wheezy:10
Claimed in Wheezy:0
Delayed in Wheezy:6
Otherwise fixed in Wheezy:50
Ignoring all the above (multiple tags possible) 532 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released. However, with the view of the Release Managers, 845 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

Craig Small: procps-ng version 3.3.2 released

procps-ng version 3.3.2 was released today. This version fixes some bugs introduced in version 3.3.1 as well as a number of enhancements. Below is the most significant set of changes that 3.3.2 brings. NLS The most visible change is that procps-ng is now international. The NLS changes took a long windy path but we got there in the end. This means all procps-ng programs can now use standard gettext PO files to output in any supported language. While the programs have been enabled for translations, there are no po files as yet but we expect them to follow soon. Library Changes procps always had a closed library, meaning that it wasn t supposed to be used for other non-procps programs. This meant the library was always called libprocps-(version) rather than using a SONAME. Procps 3.3.2 now uses a SONAME of version 0.0.0 The API hasn t changed but it will be in subsequent versions. Patch Backporting Due to the stagnant natute of procps development in the past, there have been a large number of patches each distribution carries for procps. A significant number of patches have been incorportated into procps-ng, giving a more consistent look across the distributions and meaning any subsquent fixes or enhancements are done in one place. A major goal of procps-ng was to reduce the number of distribution specific patches which this change has helped greatly. debian Packages The Debian packages will be worked on soon and will clear up some confusion about the procps binaries and library packages as this will now be split into two. It also means that some programs that depend on libprocps will break, but going on from this point will be able to use the normal shlibs process to manage that, rather than the ugly crunch we will have now.

5 January 2012

Michal &#268;iha&#345;: ColorHug client in unstable

It took me much more uploads than I expected, but ColorHug client is finally in unstable. I was fighting with various bugs, which I could not reproduce locally and of course with my own stupidity in configuring pbuilder. Anyway the buildds overview now shows mostly green, so this is good. The remaining ones mostly wait for libgusb, which needs build on armhf and needs to be ported to non Linux (or rather libusb needs to exist there). One of things I've learned on the way is that docbook-utils is not enough to convert docbook to man pages, you need docbook package as well. Still I don't understand why this did locally work for me... The one outstanding issue is that client code assumes it runs on little endian host (or rather same endianity as the ColorHug device) and thus will break on PPC and other big endian machines. The upstream is aware of that an I even managed to produce patch which should fix it, though I have no means to test it (lack of big endian hardware and lack of the ColorHug device itself).

Filed under: Debian English 4 comments Flattr this!

Jaldhar Vyas: Jeopardy!: The Post-Mortem

By now hopefully you got a chance to see my Jeopardy! episode so it won't be much of a spoiler to mention that I didn't win. It went like this. I flew into LA on the night of October 31st. The taping was to take place on the next two days. Jeopardy! tapes two weeks of shows, two days a week for a total of 10 episodes. Contestants are randomly chosen for one of those 10 episodes but you don't find out which one you will be on until the last minute. Randomness and secrecy have become become a big part of the production process in games since the quiz show scandals of the 1950s. (Interesting fact: it is a Federal felony to tamper with a TV game show.) There were a group of just under 20 0f us altogether waiting to go on. All very nice people. Here in the New York area one tends to equate very intelligent people with "Type A" personalities but we got on well together. Interspersed between the tapings, we had short practice sessions to familiarize ourselves with the studio setup and this is where I first started getting a little apprehensive. Jeopardy! is not just about general knowledge, there is a physical element too in that you have to buzz in by pressing a button on a stick which is wired up to some producers console. You can't buzz in before Alex has finished reading the question and obviously you can't buzz in if someone is already answering the question. If you buzz at the wrong time, your buzzer locks for 0.75 seconds so just jamming your finger on the button. I didn't even get that far as on the entire first day I failed to buzz in at all despite changing hands, changing grip different ways and other strategies. I was pretty despondent by the second day but then miraculously I managed to get the hang of it. So when I was finally selected (for the 3rd game of that day.) I was back to my usual cool self. I was up against Dave Leach and Nicholas Campiz who were returning after having tied in the previous game. And the game did start well enough. Oh one thing you may notice is that Alex mispronounces my name Jaldhal. I knew he did that once or twice and even mentioned it to a producer but it was only viewing the episode right now that I see he does it consistently. I assumed such things would be fixed up in post-editting but I guess not. Oh well, after living in this country for so many years I've learned to be happy whenever two consonants are more or less in the right place. This particular mispronunciation is actually fairly common, even Indian people have been known to make it. The alternative theory is that Alex couldn't read my horrible handwriting which is also plausible. Anyway, I digress. I started off fairly well. My first mistake was in a category about alcoholic drinks. I answered vermouth when the correct response was gin. In my defense I'm a strict teetoler so none of these words mean anything to me. I also earned the disapproval of my superhero fan son by mistaking Dr. Strange for Dr. Doom. I did get the one about Spiderman villain Dr. Octopus so that mollified him somewhat. The highlight of my evening was strangely enough in a category about books of the Bible. I got a Daily Double. It was a risky move but I have always wanted to make a "true" daily double so I threw caution to the winds and wagered everything I had. To my surprise as much as anyones, got the answer right doubling my score. I was in a pretty good position for the Double Jeopardy but thats when Dave started dominating. If you haven't been watching previous games, Dave Leach is arguably the best player this season. Not only is he smart but he is almost supernaturally fast on the buzzer. You can't see because I kept my hands behind the podium but I again and again I would desperately try to ring in on a question I knew the answer to only to be beaten to the punch by Dave. This caused me to start getting a bit reckless and answering questions where I was less than certain which cost me dearly. One particularly dumb mistake was in a category where all the answers were supposed to start with the letter g. I said compass when I should said gyrocompass but actually I should have left that category alone entirely. By the time Final Jeopardy came around winning was no longer an option as Dave was too far in the lead. I was slightly ahead of Nicholas in 2nd place. This is where I again made a strategic error. My original plan to bet nothing in Final Jeopardy but the category was "1930s Novels" and I liked my chances. The clue was read out and it involved an anti-war novel whose author was blacklisted. I was elated. It had to be "All Quiet on the Western Front" right? The blacklist bit gave me pause as the author Erich Maria Remarque was German and this was obviously a reference to the anti-Communist blacklist in the 1950s USA. But somehow I remembered that he had spent the end of his life in Hollywood or maybe I just convinced myself that it was plausible. Evidently my thought process wasn't too crazy because all three of us came up with the same answer. All three of us were wrong. The correct answer was "Johnny Got His Gun" by Daltan Trumbo. In hindsight I knew this but it illustrates the strange ways the mind works. I knew because the video for Metallicas song "One" from "...And Justice for All" is based on the film adaptation of this book. However in a previous orientation session the lady who is the contestant coordinator for Jeopardy! had mentioned AQOTHWF as anexample of something and this got stuck in my brain crowding out the previously known fact. So when all was said and done I ended up in 3rd place. (I bet big whereas Nicholas was more conservative.) Oh well. Despite not winning I had a blast. I fulfilled my dream of appearing on Jeopardy! I met Alex Trebek. (And I should be receiving an autographed picture of us together soon.) My witty banter was sufficiently witty. I made enough money to cover my travel expenses and still have a nice amount left. And I got to meet lots of interesting and wonderful people. So I'm satisfied.

4 January 2012

Matthew Garrett: Android, GPL violations and Google

A bit over a year ago, I wrote about how an incredible number of Android tablets on the market were in violation of the terms of the GPL. I've had rather a lot else to do since then so it's now awfully out of date - but taking a quick browse through the current stack of cheaper devices indicates that things aren't all that much better. We've got source code for some chipsets that were missing it before, but to compensate we've got a whole bunch of new hardware that's entirely lacking. It's all pretty poor, really.

At the time, I wrote the following:

"(Side note: People sometimes ask why Google aren't doing more to prevent infringing devices. For the vast majority of these cases, Google's sole contribution has been to put Android source code on a public website. Red Hat own more of the infringing code than Google do. There's no real reason why Google should be the ones taking the lead role here, and there's fairly sound business reasons why it's not in their interest to do so)"

Factually speaking, nothing's changed. Each of these devices contains code owned by Google, and Google could absolutely take legal action against the vendors. Equally, so could Red Hat, Intel, Nokia and dozens of other companies who hold copyright on portions of the code carried on these devices, and so could thousands of individuals around the world. Nobody's obliged to enforce their copyrights, and in the absence of anyone else doing so it's unreasonable to insist that Google should do it.

However.

Google gives Android away. This seems like an odd thing for them to do, given that it's a significant engineering effort and costs a lot of money to produce. But remember what Android brings to Google - it's a platform with a well-integrated mechanism for distributing advertising to users. Scanning the market shows a huge number of ad-supported apps, and Google's getting money for every single one of those that gets shown. The more Android devices, the bigger the market for apps - and the wider their advertising reach.

In other words: unscrupulous hardware vendors save money by ignoring their GPL obligations. This lets them appeal on price, increasing the number of Android devices in use and increasing Google's profits. Google makes money off other people's violation of the GPL.

Could Google do anything to stop this? Yes. They could sue for copyright infringement, but that kind of thing's time consuming and awkward and any argument about the GPL always seems to end up as a big argument involving conspiracy theories. Instead, Google could attach some extra conditions to the Android trademark. Requiring that the trademark only be attached to GPL-compliant products ought to allow Google to take advantage of the existing well-tested mechanisms for seizing counterfeit goods, providing a direct economic incentive for companies to come into compliance. For added marks, they could restrict the adwords code to devices that use the trademark - if the vendor removes the trademark, applications depending on the adwords functionality would refuse to run and Google wouldn't make money off the infringing hardware.

Or, of course, they could just carry on making extra money as a result of vendors denying users the freedoms granted by the copyright holders. Although that sounds kind of evil to me.

Edit: You probably also want to read the followup post here.

comment count unavailable comments

3 January 2012

Julien Danjou: Google Calendar notifications using pynotify

I use Google Calendar to manage my calendars, and I really missed something to warn me whenever I have an appointment with an alert set. So here is an example of a Python program to do such a thing. It is written using the Google Data APIs Python client library and pynotify. I'll detail the code here, so you can build your own and adapt it to your needs. First, we need to import GTK+ and pynotify, and initialize it. 
import gtk
import pynotify
pynotify.init(sys.argv[0])
Then, we need to import gdata Calendar API and connect to the calendar. I'll use the simple email/password way to login, which is clearly not the best, but it's also the simplest. Feel free to use OAuth 2.0. :-) 
calendar_service = gdata.calendar.service.CalendarService()
calendar_service.email = 'mygooglelogin'
calendar_service.password = 'mygooglepassword'
calendar_service.ProgrammaticLogin()
Now we're ready to request stuff and notify! First, request the events from the default calendar. 
feed = calendar_service.GetCalendarEventFeed()
Now we can iterate over feed and do various checks. 
for event in feed.entry:
    # If the event status is not confirmed, go to the next event.
    if event.event_status.value != "CONFIRMED":
        continue
    # Now iterate over all the event dates (usually it has one)
    for when in event.when:
        # Parse start and end time
        try:
            start_time = datetime.datetime.strptime(when.start_time.split(".")[0], "%Y-%m-%dT%H:%M:%S")
            end_time = datetime.datetime.strptime(when.end_time.split(".")[0], "%Y-%m-%dT%H:%M:%S")
        except ValueError:
            # ValueError happens on parsing error. Parsing errors
            # usually happen for "all day" events since they have
            # not time, but we do not care about this events.
            continue
        now = datetime.datetime.now()
        # Check that the event hasn't already ended
        if end_time > now:
            # Check each alert
            for reminder in when.reminder:
                # We handle only reminders with method "alert"
                # and whose start time minus the reminder delay has passed
                if reminder.method == "alert" \
                        and start_time - datetime.timedelta(0, 60 * int(reminder.minutes)) < now:
                    # Build the notification
                    notification = pynotify.Notification(summary=event.title.text,
                                                         message=event.content.text)
                    # Set an icon from the GTK+ stock icons
                    notification.set_icon_from_pixbuf(gtk.Label().render_icon(gtk.STOCK_DIALOG_INFO,
                                                                              gtk.ICON_SIZE_LARGE_TOOLBAR))
                    notification.set_timeout(0)
                    # Show the notification
                    notification.show()
Running this program, you should see a notification if an appointment has an alert to be raised at that time. This should be enough to start to build something. If you don't want to program this into Python, you might want to take a look at gcalcli.

1 January 2012

Tanguy Ortolo: Debian Developper

Debian red swirl For this new year I got a quite specific present : a Debian Developer account. Of course this is not an end by itself but rather a beginning, or perhaps a continuation of my modest effort to contribute to the greater good of our users and free software. As an introduction, I would like to quickly explain how I came to this point, and I also have some people to thank.

Debianist journey
1997-2003
First family computer, a PC running Microsoft Windows 98. I became a power-user, and I progressively replaced all the pieces of that computer, except it operating system (though I reinstalled it several times).
2003
First contact with GNU/Linux: at my preparatory school, we use XEmacs and Kile under Mandrake Linux 9.2 to do some works in Caml Light and LaTeX. I start enjoying free software at home, with Mozilla Firefox, Thunderbird and Libre^WOpenOffice.org.
2005, preparatory school
I try Knoppix at home and eventually install Mandriva Linux 10.2 for my own use. Since then I have never used Microsoft Windows for personal work any more.
2005, engineer school
I integrate Centrale Paris and I join the team of VIA Centrale R seaux, which I believe is a known den of debianists. So I start using Debian on my personal laptop.
2006
Debian power-user. I start reporting bugs.
2007
First small contributions: some of my bug reports now include patches. I also start maintaining a French training document about Debian: formation Debian GNU/Linux.
2008
First packaging work with the help of adn, a modification and split of frozen-bubble to have a server-only package (contribution finally refused, actually).
2010
First package: I adopt dokuwiki with the help of adn. I become a Debian Maintainer, with the intent of applying as a Debian Member later.
2012
I am now a Debian Developer, responsible for a handful of packages and able to do NMUs and to sponsor new contributors.
As you may guess, I have always been a tinkerer, about computers but also about bikes (the ones that work with manpower, not the ones that make noise and smoke ;-)). And I also always wanted to publish my works somehow, because I hate to think that someone could have to do again some reusable work I had to do before instead of taking advantage of it. Well, it happened that free software was a way to achieve both goals: to hack and to make my work available for anyone. Thanks I would like to thank all those who helped me to discover and contribute to free software, especially: adn, who helped me with my first steps to directly contribute to Debian, dererk and all the Debian Developers that patiently reread and sponsored my packages, and my Application Manager gwolf, who gave quite a lot of time asking me questions, reading my replies, and replying to some questions that arose during the process. Outside of the Debian Project I have to thank Alexis de Lattre, who wrote the original Formation Linux that I am now maintaining under the name of Formation Debian GNU/Linux , a document which helped me to discover GNU/Linux and Debian specifically. More generally, I would like to thank all the Free Software community that made that possible: Debian Developers, hackers and users from everywhere. We have built and we are still building quite an impressive pile of very useful work, and we can be proud of it. Notes
  1. Here in the northern hemisphere our school years begin in the middle of the civil year, which makes it tricky to tell them apart
  2. This is almost a synonym for tinkering, in the context of free software, is it not?

31 December 2011

Adam Rosi-Kessel: Done

I started this blog over a decade ago. Over time, my priorities have changed family, work, home, etc. Many other avenues for online self-expression have also developed in the interim. I m done for now. Old entries remain online, but do not necessarily reflect any of my current views, and certainly do not reflect any views of any of my employers.

Russell Coker: Links December 2011

Barry Ritholtz wrote an insightful post quoting Federal Reserve Bank of Kansas City President Thomas Hoenig, who warns that the nation s biggest banks are putting the U.S. capitalist society at risk [1]. Big banks oppose capitalism. Glenn Greenwald has written an insightful article for Salon about the modern definition of American excellence being the killing of supposedly bad people without any due process [2]. Mazuma Mobile buys used mobile phones [3]. They can send a post-pack to ship your old mobile to them. This is good for the environment and also saves some money. Sam Varghese has written an informative article about the Trans Pacific Partnership Agreement that will probably end up benefiting US corporations at the expense of Australian citizens [4]. Cory Doctorow has written an informative article for The Guardian about the BBC DRM plans[5]. He received information that was denied in a FOI request which shows how poor the BBC case is and how bad the Ofcom oversight is. Sam Harris has written an insightful blog post about self-defense [6]. He also has many other posts that are worth reading. Aparna Roa gave an interesting TED presentation about her robotic art [7].

Next.

Previous.