Search Results: "tach"

18 August 2011

Raphaël Hertzog: People behind Debian: Peter Palfrader, Debian System Administrator

You might not know who Peter is because he s not very visible on Debian mailing lists. He s very active however and in particular on IRC. He was an admin of the OFTC IRC network at the time Debian switched from Freenode to OFTC. Nowadays he s a member of the Debian System Administration team who runs all the debian.org servers. If you went to a Debconf you probably met him since he s always looking for new signatures of his GPG key. He owns the best connected key in the PGP web of trust. He also wrote caff a popular GPG key signing tool. Raphael: Who are you? Peter: I m Peter Palfrader, also known as weasel. I m in my early 30s, born and raised in Innsbruck, Austria and am now living and working in Salzburg, Austria. In my copious free time, other than help running Debian s servers I also help maintaining the Tor project s infrastructure. Away from the computer I enjoy reading fiction (mostly English language Science Fiction and Fantasy), playing board games and going to the movies. Weather permitting, I also occasionally do some cycling. Raphael: How did you start contributing to Debian? Peter: I installed my first Debian the week slink came out. That was Debian 2.1 for the youngsters, in early 1999. The one thing I immediately liked about slink was that Debian s pppd supported RAS authentication which my university s dial-up system required. No way I d go back to SuSE 5.3 when I had working Internet with my Debian box. :) During that year I started getting involved in the German language Debian channel on IRCnet which got me in contact with some DDs. Christian Kurz (<shorty>) was working on Debian QA at the time and he asked my help in writing a couple of scripts. Some of that work, debcheck, still produces parts of the qa.d.o website, tho the relevance of that nowadays is probably negligible. While trying to learn more Perl earlier, I had written a program to produce syntax highlighted HTML for code snippets in various languages. I didn t really know what I was doing but it kinda worked, and probably still does since I still get mail from users every now and then. I figured that it would be really nice if people could just get my software together with Debian. According to code2html s Debian changelog the initial release of the package was done on a weekday at 2:30 in the morning early in 2000, and if my memory serves me correctly, shorty uploaded it shortly afterwards. I started packaging a couple of other piece of software and in the same year I sent my mail to the debian account managers to register my intent to become a DD. No new developers where being accepted at that time since the DAMs wanted to overhaul the entire process so I wasn t surprised to not get any immediate reply. Of course what the silence also meant was that the mail had been lost, but I only learned of that later when I took all my courage to ask DAM about the status of application a couple months later. Once that was sorted out I was assigned an AM, did the usual dance, and got my account late in November 2000. Raphael: Four years ago, the Debian System Administration team was a real bottleneck for the project and personal conflicts made it almost impossible to find solutions. You were eager to help and at some point you got dropped as a new member in that team. Can you share your story and how you managed the transition in the difficult climate at that time? Peter: Ah, that was quite the surprise for an awful lot of people, me included. Branden Robinson, who was our DPL for the 2005-2006 term, tried to get some new blood added to DSA who were at the time quite divided. He briefly talked to me on IRC some time in summer 2005, telling me I had come recommended for a role on the sysadmin team . In the course of these 15 minutes he outlined some of the issues he thought a new member of DSA would face and asked me if I thought I could help. My reply was cautiously positive, saying that I didn t want to step on anybody s toes but maybe I could be of some assistance. And that was the first and last of it, until some fine November day two years later I got an email from Phil Hands saying I ve just added you to the adm group, and added you to the debian-admin@d.o alias. and welcome on board . *blink* What!? My teammates at the time were James Troup (elmo), Phil Hands (fil), Martin Joey Schulze and Ryan Murray (neuro). The old team, while apparently not on good terms with one another, was however still around to do heavy lifting when required. I still remember when on my first or second day on the team two disks failed in the raid5 of ftp-master.debian.org aka ries. Neuro did the reinstall once new disks had arrived at Brown University. I m sure I d have been way out of my league had this job fallen to me. Fortunately my teammates were all willing and able to help me find whatever pieces of information existed that might help me learn how debian.org does its stuff. Unfortunately a lot of it only existed in various heads, or when lucky, in one of the huge mbox archives of the debian-admin alias or list. Anyway, soon I was able to get my hands dirty with upgrading from sarge to etch, which had been released about half a year earlier. Raphael: I know the DSA team has accomplished a lot over the last few years. Can you share some interesting figures? Peter: Indeed we have accomplished a lot. In my opinion the most important of these accomplishment is that we re actually once again a team nowadays. A team where people talk to one another and where nobody should be a SPoF. Since this year s debconf we are six people in the admin team: Tollef Fog Heen (Mithrandir) and Faidon Liambotis (paravoid) joined the existing members: Luca Filipozzi, Stephen Gran, Martin Zobel-Helas, and myself. Growing a core team, especially one where membership comes with uid0 on all machines, is not easy and that s why I m very glad we managed to actually do this step. I also think the infrastructure and our workflows have matured well over the last four years. We now have essential monitoring as a matter of course: Nagios not only checks whether all daemons that should be running are in fact running, but it also monitors hardware health of disks, fans, etc. where possible. We are alerted of outstanding security updates that need to be installed and of changes made to our systems that weren t then explicitly acked by one of us. We have set up a centralized configuration system, puppet, for some of our configuration that is the same, or at least similar, on all our machines. Most, if not all, pieces of software, scripts and helpers that we use on debian.org infrastructure is in publicly accessible git repositories. We have good communication with other teams in Debian that need our support, like the ftp folks or the buildd people. As for figures, I don t think there s anything spectacular. As of the time of our BoF at this year s DebConf, we take care of approximately 135 systems, about 100 of them being real iron, the other virtual machines (KVM). They are hosted at over 30 different locations, tho we are trying to cut down on that number, but that s a long and difficult process. We don t really collect a lot of other figures like web hits on www.debian.org or downloads from the ftp archive. The web team might do the former and the latter is pretty much impossible due to the distributed nature of our mirrors, as you well know. Raphael: The DSA team has a policy of eating its own dog food, i.e. you re trying to rely only on what s available in Debian. How does that work out and what are the remaining gaps? Peter: Mostly Debian, the OS, just meets our needs. Sure, the update frequency is a bit high, we probably wouldn t mind a longer release cycle. But on the other hand most software is recent enough. And when it s not, that s easy to fix with backports. If they aren t on backports.debian.org already, we ll just put them there (or ask somebody else to prepare a backport for us) and so everybody else benefits from that work too. Some things we need just don t, and probably won t, exist in Debian. These are mainly proprietary hardware health checks like HP s tools for their servers, or various vendors programs to query their raid controller. HP actually makes packages for their stuff which is very nice, but other things we just put into /usr/local, or if we really need it on a number of machines, package ourselves. The push to cripple our installers and kernels by removing firmware was quite annoying, since it made installing from the official media next to impossible in some cases. Support for working around these limitations has improved with squeeze so that s probably ok now. One of the other problems is that especially on embedded platforms most of the buildd work happens on some variation of development boards, usually due to increased memory and hard disk requirements than the intended market audience. This often implies that the kernel shipped with Debian won t be usable on our own debian.org machines. This makes keeping up with security and other kernel fixes way more error prone and time intensive. We keep annoying the right people in Debian to add kernel flavors that actually boot on our machines, and things are getting better, so maybe in the future this will no longer be a problem. Raphael: If you could spend all your time on Debian, what would you work on? Peter: One of the things that I think is a bit annoying for admins that maintain machines all over the globe is mirror selection. I shouldn t have to care where my packages come from, apt-get should just fetch them from a mirror, any mirror, that is close by, fast and recent. I don t need to know which one it was. We have deployed geodns for security.debian.org a while ago, and it seems to work quite well for the coarse granularity we desired for that setup, but geodns is an ugly hack (I think it is a layer violation), it might not scale to hundreds or thousands of mirrors, and it doesn t play well with DNSSEC. What I d really like to see is Debian support apt s mirror method that I think (and I apologize if I m wronging somebody) Michael Vogt implemented recently. The basic idea is that you simply add deb mirror://mirror.debian.org/ or something like that to your sources.list, and apt goes and asks that server for a list of mirrors it should use right now. The client code exists, but I don t know how well tested it is. What is missing is the server part. One that gives clients a mirror, or list of mirrors, that are close to them, current, and carry their architecture. It s probably not a huge amount of work, but at the same time it s also not entirely trivial. If I had more time on my hands this is something that I d try to do. Hopefully somebody will pick it up. Raphael: What motivates you to continue to contribute year after year? Peter: It s fun, mostly. Sure, there are things that need to be done regularly that are boring or become so after a while, but as a sysadmin you tend to do things once or twice and then seek to automate it. DSA s users, i.e. DDs, constantly want to play with new services or approaches to make Debian better and often they need our support or help in their endeavors. So that s a constant flow of interesting challenges. Another reason is that Debian is simply where some of my friends are. Working on Debian with them is interacting with friends. I not only use Debian at debian.org. I use it at work, I use it on my own machines, on the servers of the Tor project. When I was with OFTC Debian is what we put on our machines. Being a part of Debian is one way to ensure what Debian releases is actually usable to me, professionally and with other projects. Raphael: Is there someone in Debian that you admire for their contributions? Peter: That s a hard one. There are certainly people who I respect greatly for their technical or other contributions to Debian, but I don t want to single anybody out in particular. I think we all, everyone who ever contributed to Debian with code, support or a bug report, can be very proud of what we are producing one of the best operating systems out there.
Thank you to Peter for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

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

7 August 2011

Rapha&#235;l Hertzog: People behind Debian: Margarita Manterola, Debian Women member

Photograph taken by Julia Palandri

When I think about Margarita, I always remember her as a friendly and welcoming person. Like most of the Debian Women members by the way. But she likes to spread some love and organized a Debian Appreciation Day for example. I think I met her in real life for the first time at Debconf 6 in Oaxtepec (Mexico). She deeply cares about Debian in general. She has proven it multiple times with her DPL candidacy and by giving talks like Making Debian rule again. One last thing, Debconf11 is just over and you will see that Debconf4 has had a big influence on Marga. My advice is simple: next time there s a Debconf on your continent, make sure to take a few days off and come to meet us! It really gives another picture of the Debian community. Now let s proceed with the interview. Raphael: Who are you? Margarita: I m Margarita Manterola, a Software Developer from Argentina. I work developing software in Python in a Debian-friendly company during the day, and teach programming at a local university during the evenings. I m married to Maximiliano Curia who is also a Debian Developer, most of our Free Software work has been done together. I only maintain a handful of packages in Debian, I m more interested in fixing bugs than in packaging new software. I ve also been a part of the organizing team of many of the previous Debian Conferences. One of the biggest commitments and the biggest success of my participation in Debian was being part of the organizing team of DebConf8, in Argentina. Raphael: How did you start contributing to Debian? Margarita: I started using Debian around 2000. Soon after we had learned the grips of general GNU/Linux usage, Maxy and I started giving an introductory course at our local university, and became quite involved with the local LUG. At some point in 2002/2003 I became a Debian Bug Reporter : most of my friends would report bugs to me, and I would then write them in the proper form to the BTS. I would also be very attentive about reporting any bugs that I might encounter myself trying to create good bug reports. The turning point in my participation in Debian was DebConf4 in Porto Alegre, Brazil. Being so close to Argentina meant that we felt specially invited to be there, and Maxy and I decided to go to DebConf for our honeymoon. We didn t really know much about DebConf dynamics, but we were really eager to learn more about Debian and become more involved. What happened was that meeting with DDs from all over the world transformed our lives, we became part of the Debian family and wanted to be more and more involved. Soon after that we both started maintaining packages and not long after that, applied to become Developers. The Debian Women project also meant a lot to me. I felt encouraged all along the way, encouraged to learn, to ask questions and to lose the fear of making mistakes. I became a Debian Developer on November 2005. Since then, Debian has always been one of the most important things I do in my life. Raphael There was a Debian Women BoF during debconf. What are the plans for Debian Women in the upcoming months? Margarita: I was not there in person, but thanks to the awesome work of the video team, and of Christian Perrier s typing efforts when something failed, I was able to experience much of what was discussed. :) One of the many points that came up during the BOF is that many people Want to help but don t know where to start or how to go about it. It s a challenge for the Debian Women project to find a way to allow these people to become involved in Debian through Mini projects or something like that. Another of the subjects that was brought up was the Debian Women mentoring project, which has been going on for quite a while now, but lacks enough publicity. So, we need to reach more people about it, and maybe also improve it with some templates, similar to the New Maintainer templates, so that mentees that don t know where to start have some sort of general path to follow. Raphael: You created very useful diagrams documenting how package maintainer scripts are invoked by dpkg. How did you do it and was that a useful experience? Margarita: I did those diagrams to be able to answer one of the questions in the NM templates, regarding the order of the maintainer script execution. Answering the question in text was basically copying and pasting the part of the Debian Policy that explained it, which wasn t really too clear for me, so I decided to go and make a diagram of it, so that I could really understand it. I did it by the best of all debugging techniques: adding prints to each of the maintainer scripts, and testing them in all the different orders that I could think of. It was a useful experience at the time, because I learned a lot of how maintainers scripts work. I didn t expect the diagrams to become so famous, though, I only did them to answer one NM question, that I assumed most other people had already answered before :) Raphael: You participated in a DPL election. This is a big commitment to make. What were your motivations? Margarita: As I said, I was part of the organizing team of DebConf8, in Argentina. Which was quite a success, a lot of people enjoyed it and praised the good work that had been done by the local team. During said DebConf8, I had a dream (it was almost a nightmare, actually): I woke up and just like that, I was the DPL. I spoke to some people about this dream and to my complete surprise many said that I should actually do it. After giving that possibility a year and a half of thoughts, during the 2010 campaign I was talked into participating myself as a candidate, and it was a very interesting experience. However, I m very glad that Zack got elected and not me, I think he makes a much better DPL that I would have made. Raphael: What s the biggest problem of Debian? Margarita: I think the main problem that we have is our communication, both inside the project and outside the project. Most of us are very technical people, our skills lay in the technical part of Debian (preparing packages, fixing bugs, writing software, administering systems) not in the social part. And thus, we lack a general empathy that is quite needed when interacting with people from all over the world. Raphael: Do you have wishes for Debian Wheezy? Margarita: Not particularly. I do want it to be a great release with good quality, stable software. I would also like to keep making Debian more and more universal with each release, making it more user friendly, more accessible, and more robust than any other previous release. Raphael: Is there someone in Debian that you admire for their contributions? Margarita: I admire a lot of people in Debian. There s a lot of people that contribute a lot of time to Debian, amounts of time that I can t begin to understand how they can afford. I admire Stefano Zacchiroli, our current project leader. And Steve McIntyre, the project leader before him. Also Bdale Garbee, who s also been a DPL in the past. Making this list I realize that Debian has been blessed by quite a number of great leaders in the past. I admire Holger Levsen, for his contributions to the DebConf video team, that have made it possible year after year for the whole project to participate in DebConf remotely. I admire Steve Langasek and Andreas Barth (etch is still my favourite release). I admire Christian Perrier for his work on internationalization. I admire Joerg Jaspert for the incredible amounts of time that he puts into Debian. And actually, I could go on admiring people all night long. I admire so many people that this interview could become a very boring list of names. I guess it s better to leave it at saying that Debian is lucky to have quite a lot of excellent hackers around.
Thank you to Marga for the time spent answering my questions. I hope you enjoyed reading her answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

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

Tanguy Ortolo: Useful options of rsync

rsync logo
rsync is often used to back up systems, with options such as:
-a --archive
recurse and preserve usual attributes: symlinks, devices and special files, user and groups ownership, permissions and times;
-H --hard-links
detect and preserve hard links;
-A --acls
preserve ACLs, if you use them;
-X --xattrs
preserve extended attributes, if you use them.
In addition to these common options, rsync has plenty others, so everyone has his own recipe, but I would like to share two useful options I discovered.--numeric-ids By default, rsync uses literal UIDs and GIDs if it can find matches in both the source and the destination. That is, if you have users jacquouille (1002) on your source system Reblochon, and a user jacquouille (1005) on your destination system Neufch tel, rsync will map them: files with an UID of 1002 will be backed up with an UID of 1005. This may or may not be wanted, but anyway you must be aware of it. For instance, if you have to restore Reblochon's home directories and do that by attaching a new drive locally to Neufch tel, you will end with mixed up UIDs. This option --numeric-ids forces rsync to use numeric IDs instead of trying to map them. It is notably needed for backups of jailed systems (BSD jails, OpenVZ, VServer, lxc ) which appear to have bogus IDs when seen from their host system because they have their own ID maps. --fake-super When you back up a full system or anything that requires keeping file ownership or device information, you need to have root privileges on the destination system. Without them, rsync would be unable to correctly chown() the destination files. This option --fake-super offers a way to back up privileged information without requiring root privileges. It works by adding special extended attributes such as user.rsync.%stat containing al this information. Of course, it still requires a destination file system that supports extended attributes. This provides a good way to push system backups without weakening your security by opening a root access on you destination system. For instance, I personally use it with rsyncd running as an unprivileged user.

31 July 2011

Uwe Hermann: The FONIC Surf-Stick, Huawei E1750 HSPA USB modem, on Debian GNU/Linux via usb_modeswitch and wvdial

FONIC Surf-Stick, Huawei E1750, package
I recently got myself a FONIC account for mobile Internet. This (German) prepaid-provider offers a "daily flatrate" for 2.50 per day. After the 10th day of usage (i.e., 25 ) you don't pay any more. This means, even if you need mobile Internet access 31 days a month, you only pay for 10 days. After 500MB/day or 5GB/month you're throttled down to GPRS speed (but you can still connect, and you don't pay more). The FONIC account comes with the "FONIC Surf-Stick", a Huawei E1750 HSPA USB modem (apparently it supports GPRS, EDGE, UMTS, HSDPA (up to 7.2Mbit/s), HSUPA (up to 5.76 Mbit/s), and a SIM card. In order to use the device on Linux you need two packages, usb_modeswitch and wvdial:
  $ apt-get install usb-modeswitch wvdial
Recent versions of usb_modeswitch (and matching udev entries) already support the Huawei E1750 out of the box, a few seconds after attaching the device it's automatically switched into modem mode. After this has been done you should have three new serial devices, usually /dev/ttyUSB0, /dev/ttyUSB1, and /dev/ttyUSB2. You'll need /dev/ttyUSB0 for talking to the device using AT commands. The lsusb output should look like this (see here for full lsusb -vvv):
  $ lsusb
  Bus 001 Device 045: ID 12d1:1436 Huawei Technologies Co., Ltd. 
(before usb_modeswitch was run, the USB IDs were 12d1:1446) FONIC Surf-Stick, Huawei E1750, front The required settings for connecting are documented at fonic.de, specifically the APN (pinternet.interkom.de). A username and/or password is not required. You need to provide your FONIC PIN though. Dialing is done using the *99# number and using the ATDT command. I'm using the following wvdial config file:
  $ cat /etc/wvdial.conf
  [Dialer Defaults]
  Modem = /dev/ttyUSB0
  Baud = 460800
  [Dialer pin]
  Init1 = AT+CPIN=1234
  [Dialer fonic]
  Phone = *99#
  Username = foo
  Password = foo
  Stupid Mode = 1
  Dial Command = ATDT
  Init2 = ATZ
  Init3 = AT+CGDCONT=1,"IP","pinternet.interkom.de"
FONIC Surf-Stick, Huawei E1750, back For mobile Internet access you would do the following:
  1. Attach the device via USB, wait a few seconds to let usb_modeswitch do its magic.
  2. Run wvdial pin and wait a few seconds (until the prompt returns):
      $ wvdial pin
      --> WvDial: Internet dialer version 1.61
      --> Initializing modem.
      --> Sending: AT+CPIN=1234
      AT+CPIN=1234
      OK
      --> Modem initialized.
      --> Configuration does not specify a valid phone number.
      --> Configuration does not specify a valid login name.
      --> Configuration does not specify a valid password.
    
  3. Run wvdial fonic and wait until the "CONNECT" message appears and you get DNS addresses:
      $ wvdial fonic
      --> WvDial: Internet dialer version 1.61
      --> Initializing modem.
      --> Sending: ATZ
      ATZ
      OK
      --> Sending: ATZ
      ATZ
      OK
      --> Sending: AT+CGDCONT=1,"IP","pinternet.interkom.de"
      AT+CGDCONT=1,"IP","pinternet.interkom.de"
      OK
      --> Modem initialized.
      --> Sending: ATDT*99#
      --> Waiting for carrier.
      ATDT*99#
      CONNECT
      --> Carrier detected.  Starting PPP immediately.
      --> Starting pppd at Mon Aug  1 xx:xx:xx 2011
      --> Pid of pppd: 18672
      --> Using interface ppp0
      --> local  IP address xxx.xxx.xxx.xxx
      --> remote IP address yyy.yyy.yyy.yyy
      --> primary   DNS address 193.189.244.225
      --> secondary DNS address 193.189.244.206
    
If everything worked fine you should now have connected successfully. There are other alternatives for achieving the same result, including umtsmon (Qt3 in the last release from 2009, looks a bit unmaintained), kppp, the GNOME NetworkManager, and others, but wvdial worked OK for me. For more details about the Huawei E1750 device (e.g. lsusb -vvv and more photos), see my wiki page at http://randomprojects.org/wiki/FONIC_Surf-Stick_Huawei_E1750 Update 2011-08-03: My measured download speed for a Debian ISO (over HTTP via wget, at night, roughly 22:00 o'clock) is 350-470 KB/s in case anyone is interested. During this download the blue LED on the stick was enabled, which denotes a UMTS connection (green == GPRS/EDGE, turquoise == HSDPA).

29 July 2011

Meike Reichle: Slides of my talks

I attached the slides of my talks to penta but they don't seem to show up so here are a couple links:

23 July 2011

Stefano Zacchiroli: harmonious assignments

why proprietary relicensing is unacceptable for a Free Software enthusiast The past few months have witnessed a large debate about copyright assignment, which seems to has neared its peak around the time Project Harmony has released version 1.0 of its agreement templates. (Note: I use the expression "copyright assignment" in this post, but I'd happily include into it both actual Copyright Assignment Agreements CCAs and Contributor License Agreements CLAs, as both could be used to permit various forms of proprietary relicensing.) Mark Shuttleworth has been one of the most prominent voices campaigning in favor of copyright assignments (to for-profit companies). A couple of interesting blog posts of his where this is evident are "On balancing economic power in the FLOSS ecosystem" and "The responsibilities of ownership". Voices against the opportunity of increasing the popularity of copyright assignments are aplenty and it is pointless to repeat good arguments which I find fully convincing. If you are interested in the subject, here are a few good reads I recommend: What I would like to add to the debate is the point of view of a Free Software enthusiast, not unlike yours truly. I contribute to Free Software not because it is superior to proprietary software in either its software products or in its development methodology. (It actually is superior in many cases, but that's just not my primary motivation.) I do contribute to Free Software to build a world in which users are in complete control of the software they run. Let's assume we have a broken toaster at home. We are all free to (1) open it up and try to repair it by ourselves. If we don't have the needed knowledge, we are free to (2) hand it over to a person that we trust and who does have the needed knowledge to repair it. That failing, we can (3) ask the toaster producer to repair it for us. Many people like me simply don't accept to live in a world where, once all the toasters will be software-driven, the only repair option will be (3), just because the toaster software is proprietary. (Given various kind of [broken] metaphors have been used to explain copyright assignments, it seemed sensible to propose my broken toaster metaphor in exchange.) When I contribute to some Free Software project, I not only care about being able myself to get a Free Software licensed copy of the whole product (i.e. the original software product + my own contribution). I care that all recipients of the product, present and future, will be able to get that contribution with enough freedoms attached to put them in control of the software that includes it. This desire can be fulfilled with a varying degree of success, depending on the license of the code base I contribute to. For instance, I find more pleasant to contribute to a copyleft licensed code base than to a weak-/non-copyleft licensed one, and more pleasant to contribute to an AGPL-ed web app than to a copyleft web app. It also means that, given the option, I will not allow the code base maintainer to re-license my contribution under terms that allow distributing it without suitable freedoms attached. Different contributors will be ready to accept different re-licensing promises, but the mere fact we are debating all this and that companies like Canonical feel the need of campaigning for copyright assignments is evidence that many contributors like me exists and actually have a problem with allowing downstream relicensing of their contributions. What is feared the most is of course proprietary relicensing. According to my moral horizon this is the case not because the company might end up gaining money out of my code: I wouldn't have a problem with that. The reason is rather that the company will be able to distribute my own code in a way that grants less freedoms to users than those that were implicitly "agreed upon" when the contribution has been written. In that respect, I can't help thinking at harmony agreements as a large scale smoke screen experiment meant to convince volunteers that copyright assignments are something Free Software needs. By exploiting the creative-commons-like "it's easy, just choose one" scheme, Harmony takes the chance of offering misleading options such as the one labeled "any OSI approved license". Via that option, which is seemingly fine, the copyright recipient will be allowed to relicense the contribution under some non-copyleft license (e.g. BSD) and from there do essentially what they want. All in all, companies campaigning for copyright assignments seem to have failed to understand two main points. The first one is that contributors motivated by Free Software ideals want the code to remain free not only for themselves, but for all recipients of the code. I'm not claiming that all contributors to FOSS projects belong to this category, but the fact that there is a considerable amount of such people is undeniable. Hoping that they will be fooled by tricks like the "any OSI approved license" agreement is foolish. The second is that while volunteer Free Software communities do respect companies that provide huge amounts of code contributions, they also expect companies to figure out by themselves which business models make their businesses sustainable. Telling volunteers that current business models are not sustainable without proprietary relicensing is worthless. Volunteers just don't care. They want software freedom guarantees and are not willing to renounce to them in exchange of the wealth of companies, not even under the (implicit) threat that otherwise those companies will be forced to reduce the amount of their code contributions.
Update: explain in the initial note why my reasoning here encompasses both CCAs and CLAs. Thanks Tollef for noticing that it wasn't clear.

21 July 2011

Rapha&#235;l Hertzog: People behind Debian: Martin Michlmayr, former Debian Project Leader

Martin Michlmayr is a Debian developer since 2000 and I share quite a few things with him, starting with his age and involvement in the quality assurance team. He managed to be elected Debian Project Leader in 2003 and 2004. He s no longer as active as he used to be but his input is always very valuable and he continues to do very interesting things in particular concerning the support of NAS devices. Read on for the details. Raphael: Who are you? Martin: I m Martin Michlmayr. I m 32, originally from Austria, and currently living in the UK. I ve contributed to various free software projects over the years but Debian is without doubt the one I m most passionate about. I joined Debian in 2000 when I was a student. I worked on Debian more or less full time for a few years while I was pretending to study. Later I started a PhD to do research about quality and management aspects of volunteer free software projects. I investigated the release process in several free software projects, in particular looking at time-based releases. After finishing my PhD in 2007, I joined Hewlett-Packard. I m part of HP s Open Source Program Office and work on various free software and open source activities, both internally and within the community. Raphael: How did you start contributing to Debian? Martin: I first used Debian in the days of 0.93R6, some time around the end of 1995. The 0.93R6 release was still based on a.out but I needed an ELF-based system for some application, so I moved to Slackware. I then quickly moved to Red Hat Linux where I stayed for several years. I rediscovered Debian in 2000 and quickly decided to join the project. I cannot recall how I rediscovered Debian but when I did, it was clear to me that Debian was the ideal project for me: I could identify with its philosophy, I liked the volunteer nature of the project, and I found the size and diversity of Debian interesting since a large project offers a lot of different challenges and opportunities. I remember how many new things there were to learn and back then the documentation and other resources for new contributors were nowhere as good as they are today. My application manager, Julian Gilbey, was a great help he was incredibly friendly and passionate about Debian. I also remember meeting up with Peter Palfrader (weasel) for key signing when we were both in the New Maintainer queue. I was incredibly lucky with my New Maintainer process and soon became an official Debian Developer. Because there was a shortage of application managers, my first major contribution in Debian was to become an application manager myself and help other people join the project. Debian is a large project with a long history and a rich culture, so new contributors should expect that it will take some time to become familiar with everything. Fortunately, there are many resources, such as documentation and the debian-mentors list, for new contributors. Another great way to become familiar with the way things are done in Debian is to subscribe to various Debian mailing lists and ideally to read some mailing list archives. It s also a great idea to attend the Debian Conference or other conferences since meeting people in real life is a great way to integrate. I remember attending Debian Conference 1 in Bordeaux where I gave my first public talk. Finally, new contributors should find an area where they can make a unique contribution. Most people in Debian maintain packages but there are so many other ways to contribute. For example, most of my contributions were not technical but were about coordination and other organizational activities. Raphael: What s your biggest achievement within Debian? Martin: I m particularly proud of a number of achievements:
  • New Maintainer: I helped a lot of people join Debian. It s great to help someone join the project and then see how they contribute. Of course, some people join Debian and then quickly become inactive or retire you never know in advance how it will work out. But I had the pleasure to help some truly outstanding contributors to join Debian.
  • Quality Assurance: I helped improve QA processes within Debian. In particular, I realized a few years ago that a lot of packages had maintainers who were inactive and that nobody did anything about it. I started to write to those maintainers to see what could be done. It s hard because you don t know the circumstance of someone they may be inactive because of an illness or for other good reasons so you have to be friendly, but yet persistent. Fortunately, most maintainers I contacted were truly inactive and so they couldn t complain when I took their packages away.
  • DPL: I acted as the Debian Project Leader for two years. I m particularly proud of this because Debian is a great project and it was an honour to represent it. I performed important organizational and coordination tasks. I also traveled to a lot of conferences and had the pleasure to meet many Debian Developers as well as users of Debian. It s very motivating to meet users and to hear how they use Debian and how we can further improve it.
  • Debian on NAS: Debian is without the doubt the Linux distro with the best support for NAS (Network Attached Storage) devices. I was always impressed by what the OpenWRT folks have done to support wireless routers and wanted to do something similar for Debian. Unfortunately, wireless routers just don t have enough storage for a full distro. But then NAS devices came along and they obviously have enough space since they are meant for storage.
Raphael: Speaking about NAS devices: what exactly are you doing on this topic and how can people help? Martin: There are plenty of instructions on the Internet to install Linux distributions on NAS or various embedded devices by connecting a serial console and then typing in hundreds of commands. What I found is that such instructions significantly limit the user base because they are way too complicated for most users. There are just too many steps that can go wrong. So instead, in Debian, we provide a solution that just works: usually, you download a firmware image for your NAS device from Debian and when you upgrade you get the Debian installer. You connect to the installer via SSH and perform a normal installation. The installer knows about the device and will prepare everything for you automatically for example, it knows if the device has requirements for the partition layout and it will install the kernel where the device expects to find it; unfortunately, NAS devices are not like PCs, so the requirements are different for almost every device and therefore you need special code to support a new device. Finally, there are detailed installation guides and we provide help on our mailing lists. There are a number of technical areas for improvement. The installation could be made even easier, and it would be nice to support new platforms and devices. A bigger problem is that while we ve implemented a great solution for NAS devices, we haven t really extended this work to support other classes of devices. For example, tablets and mobile phones are getting incredibly popular and we don t have a compelling solution for such devices, mostly because of the lack of an appropriate GUI. Raphael: What are your plans for Debian Wheezy? Martin: I ve recently been asked by Stefano Zacchiroli, our current Debian Project Leader, to coordinate the care-taking of Debian finances. Debian, as a volunteer project, relies on donations and in-kind gifts (e.g. hardware) to maintain its infrastructure and to support various development efforts, such as funding sprints and other developer gatherings. Debian s money and other assets are held by affiliate organizations around the world. My responsibility will be to keep track of money and other assets (e.g. hardware and trademarks), work with the DPL to establish procedures related to the use of Debian s assets, and make sure that the procedures are followed. Finally, we want to publish public statements so our donors know how we use their donations to further improve Debian. I just started working on this and this will be my main activity in Debian in the coming months. Raphael: Speaking of money, I plan to run a fundraising to get the Debian book I wrote with Roland Mas translated (cf. http://debian-handbook.info). Is this something Debian should support? Martin: First of all, I should make it clear that I don t decide how Debian spends its money. This is up to the DPL to decide together with the project at a whole. I ll just make sure that procedures are followed and expenses tracked and reported properly. Having said that, in my opinion, it s unlikely that Debian as a project will fund this effort. It would be inconsistent with the position of the project not to fund work directly (only some related expenses, such as travel costs to allow Debian teams to organize face-to-face meetings). Whether Debian should support the fundraising effort by helping to promote it is another question and that s probably not as clear cut. It looks like a worthwhile effort, but on the other hand it would be unfair for authors of other Debian books for Debian to put its weight behind one and there are many other efforts that are worth promoting if you promote one, where do you stop? So while it sounds worthwhile, it s probably better for Debian to stay out of it. But somehow related to this, I sometimes worry about the fact that there are so few paid opportunities around Debian. If you contribute to the Linux kernel for a while, you have an excellent chance to get hired by someone and to work on the kernel full time. The kernel may be an extreme example but there are a lot of projects that have more paid opportunities than Debian, e.g. Mono, GNOME, OpenOffice/LibreOffice and KDE. Obviously, there are some Debian Developers who can spend some time on Debian as part of their job. I know that some Canonical employees contribute to Debian, that support companies like credativ improve Debian as part of their work, and that system administrators fix bugs or package new software as they deploy Debian. But I think this is a minority of contributors and even they don t work full time on Debian. Instead what I see is that a lot of people leave university, get a job and then no longer have time for Debian or people start a family and no longer have time. I can take myself as an example since I don t have nearly as much time as I did in the past when I was a student. I guess there are different ways to deal with this problem one would be to create more paid opportunities around Debian outside the project, another one might be to make it easier for new volunteers to join the project. I don t have the answers to these questions but it s something I wonder about, and I also wonder whether pure volunteer projects can still keep up with projects with a lot of full time contributors. Raphael: What motivates you to continue to contribute year after year? Martin: Debian is a great project with a great mission, goals and people. I contribute to make Debian a better solution and to promote the free software philosophy. Finally, the community around Debian provides a lot of motivation. It s amazing how much I ve learned about other cultures because of my involvement in Debian and how many friends I ve made over the years all around the world. Raphael: Do you have wishes for Debian Wheezy? Martin: Not really. I m pretty happy with the way things are going at the moment. We have made a lot of organizational changes in the last few years from which the project has greatly benefited. I m particularly pleased about the plans to adopt a time-based freeze. Raphael: Is there someone in Debian that you admire for their contributions? Martin: There are many people I admire greatly. I d like to mention Joey Hess because he s a great example to follow. He doesn t get involved in politics, is easy to work with and does great technical work. In fact, he has made not one but several contributions that have completely changed Debian (debconf, debhelper, and debian-installer). Furthermore, Debian has a lot of contributors who have done great work over the years but who are not very vocal about it. People like Colin Watson or Peter Palfrader. Debian has many unique contributors and the list of people I admire is much longer than the few people I just mentioned.
Thank you to Martin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. He raised some interesting questions. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

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

11 July 2011

Rapha&#235;l Hertzog: 7 tips to file useful Debian bug reports and get your problem solved

Filing bug reports is the most common way for users to contribute. Even if it s not too difficult, I ll give you some advice to improve the quality of your reports. After all, when you go out of your way to report a bug, it is in the hope to see it fixed so let s see how we can make this more likely. 1. Try to reproduce the bug If you can t reproduce the bug, it s next to impossible to find the root cause and thus to fix it. In that case, I would suggest you to wait until you experienced the bug multiple times. Maybe you ll be able to find something that triggers it (or that makes it more likely to encounter it). If the application has a debug/verbose mode, it might be a good idea to enable it until you experience the bug a second time. The generated log might be helpful for the developer to understand what happens exactly. So don t file bug reports straight away unless you can reproduce it. The exception to the rule is when the application gives some useful information like a core-dump, a back-trace or an error message. Obviously if the bug happens during an upgrade, it s difficult to reproduce it (unless you have multiple computers) but you should still report it. Be sure to include all the relevant information (versions of packages before and after the upgrade, logs of the upgrade, etc.). 2. Do your best to identify the faulty package When you report a bug to Debian, you must assign it to a package. While there are pseudo-packages useful for problems which are not directly attributable to a real package, in most of the cases you should report a bug against the specific package that seems to be the cause of the problem you encountered. In turn this often requires you to attribute the problem to a file (for example the executable of the application that triggers the bug). Once you have a filename you can use dpkg -S to identify the corresponding package.
$ dpkg -S /usr/bin/hamster-time-tracker
hamster-applet: /usr/bin/hamster-time-tracker
Note that reportbug accepts a filename as parameter and will do the above conversion for you. If you only know the name of the application (but not the filename of the associated executable), you can use dpkg -S with a pattern to let it return all possible matches:
$ dpkg -S hamster
hamster-applet: /usr/share/applications/hamster-applet.desktop
hamster-applet: /usr/share/gnome/help/hamster-applet/es/statistics.page
[ ]
hamster-applet: /usr/bin/hamster-time-tracker
[ ]
Or you can also verify in the list of installed packages:
$ dpkg -l "*hamster*"
Desired=Unknown/Install/Remove/Purge/Hold
  Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
 / Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
 / Name            Version         Description
+++-===============-===============-==============================================
ii  hamster-applet  2.32.1-1        time tracking applet for GNOME
3. Verify that the bug is not already reported and/or fixed If there s a newer version of the software available, it s a good idea to try to reproduce the problem with this version too. Because the developers tend to care only about the latest version, they will want to reproduce it with this version, and they will be annoyed if the problem that you reported is already fixed. That s why bug reports of users of testing/unstable tend to be more useful than bug reports of stable users. In any case, you want to verify that the bug has not yet been reported: filing a duplicate bug is useless and only generates more work for the developers to merge both bugs together. On the opposite, it s highly appreciated to add supplementary information to an existing bug report, even a simple confirmation that the bug still exists on a newer version is useful. Note that reportbug will automatically show you the list of open bugs before allowing you to submit a new one. 4. Use reportbug While the Debian bug tracking system allows anyone to submit a new bug with a simple mail, you should really use a dedicated program like reportbug (or reportbug-ng) because it will automatically include lots of useful information in the generated report (version of dependencies, current architecture, etc.) and will assist you in all the steps. 5. Describe the problem so that the developer can reproduce it Ideally your report should include everything required so that the developer can reproduce the problem on his system. If a given document triggers the bug, attach it. Describe the steps required to reproduce the bug in great details just like you would explain it to your grand-ma. Explain how you expected the program to react and what happened instead. You can learn much more on how to draft a good bug report in this article: How to report bugs effectively. It s a bit long but well worth it if you intend to report bugs and thus interact with developers. 6. Be kind and willing to help When you draft a bug report, keep in mind that you re writing to a volunteer free software developer and not to a customer service. You should be respectful and follow the usual rules of courtesy. Developers attention is scarce and should not be wasted. Be willing to help, if the developer starts investigating your problem, he might need your help to get supplementary information (in particular if he can t reproduce it) and you should be ready to provide it. Thus it s important to keep whatever you need to reproduce the problem. In some cases, the Debian maintainer might be overworked and you can offer your help to forward the bug to the upstream bug tracker, it s always appreciated. If you re reasonably confident that the problem is not Debian-specific, you can do it straight away and set the forwarded field to the URL of the upstream bug report (for example with bts forwarded <bug> <url>). 7. Use the correct severity The Debian bug tracking system lets you set the initial severity of the bug report (in decreasing severity: critical, grave, serious, important, normal, minor, wishlist). Pick the correct severity according to the official definitions but don t misread them. In particular, don t over-inflate the severity: for instance if you lost some data due to a misuse of the software, it s not critical (i.e. rm -rf * doesn t warrant a critical bug against rm). If you use only a tiny part of a software, and that part doesn t work, the package might be unusable for you but it s not unusable for everybody, so it doesn t warrant the grave severity. The important severity is often a good choice in those cases. Do not under-estimate the severity either, if a problem is important enough that it must be fixed before the next stable release (for example a regression compared to the previous release), pick a release-critical severity (i.e. at least serious ). The maintainer and the release manager can always lower the severity if they do not agree with your initial judgment. And now, happy bug-reporting!
Follow me on Identi.ca, Twitter and Facebook. Or subscribe to this blog by RSS or by email.

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

3 July 2011

Dominique Dumont: Generate a configuration editor from a config template file with Perl: lcdproc example

Hello Creating a configuration model for Config::Model can be a boring task: When a configuration system has a lot of parameters, a lot of details need to be specified to have a complete configuration validation tool. So, all tricks are permitted to make this task more bearable. Let s see how this can be applied to lcdproc. This project requires a configuration file that supports more than 40 drivers. Each driver has it own set of parameters for a total of about 250 parameters. That s a lot to specify.. Fortunately, LCDd.conf template file is written in a way which makes it relatively easy to parse and get all required information to build a model. All drivers are listed in this template file, most parameters have default values and legal values are written in comments in a uniform way. Hence this file (and comments) can be parsed to retrieve information required for the model. This blog will describe how this task can be implemented in Perl using Config::Model modules. The code will be slightly trimmed down to keep this blog (relatively) short. All initialisation code and error checks are removed. You can get the whole script on sourceforge. The main steps are:
  1. prepare a parser for LCDd.conf template
  2. parse LCDd.conf template
  3. prepare a LCDd model skeleton
  4. translate LCDd.conf template information in a format suitable to create a model.
  5. Write the resulting LCDd model
First, here s the necessary incantation to start properly a Perl program:
use strict;
use warnings;
Then load all required libraries. Their use will be described later:
use Config::Model;
use Config::Model::Itself 1.225;
use Config::Model::Backend::IniFile;
use 5.10.0;
use IO::File;
use IO::String;
Perform some initialisation to avoid upsetting the logging system:
use Log::Log4perl qw(:easy);
Log::Log4perl->easy_init($WARN);
Let s also initialize a model object that will be very useful later:
my $model = Config::Model->new();
Now we can really start the fun part. Step 1: Create a parser for LCDd.conf (INI file)
Problem: LCDd.conf comments must also be analysed to get more semantic information. The comments must be retrieved and associated with the INI classes and parameters found in this file. Fortunately, Config::Model::Backend::IniFile is able to associate comments with the relevant parameters. But Config::Model::Backend::IniFile must store its values in a configuration tree. So let s create a model suitable for LCDd.conf template that accepts any INI class and any INI parameter Dummy::Class is used to store any parameter found in an INI class. The accept keyword with .* regular expression means that any INI parameter will be accepted in each INI class.
$model->create_config_class(
  name   => 'Dummy::Class',
  accept => [
    '.*' =>  
       type => 'leaf',
       value_type => 'uniline'
        ,
    ],
);
Now the Dummy model must provide a configuration class to hold all INI classes:
$model->create_config_class(
    name   => 'Dummy',
    accept => [
       '.*' =>  
           type => 'node',
           config_class_name => 'Dummy::Class'
        ,
    ],
);
Note that an INI backend could be specified directly here. But, some useful parameters are commented out in LCD.conf. Some some processing is required to be able to create a model with these commented parameters. See below for this processing. Step 2: Parse LCDd.conf Now the dummy configuration class is created. Let s create a configuration tree from this dummy class to store the data from LCDd.conf
my $dummy = $model->instance(
    instance_name   => 'dummy',
    root_class_name => 'Dummy',
)-> config_root;
Now, read LCDd.conf:
my $lcd_file
  = IO::File->new('examples/lcdproc/LCDd.conf');
my @lines    = $lcd_file->getlines;
And perform the pre-processing on LCDd.conf mentioned above. Just un-commenting commented parameters is required:
foreach (@lines)   s/^#(\w+=)/$1/  
Store the pre-processed LCDd.conf in a IO::Handle usable by INI backend
my $ioh = IO::String->new( join( '', @lines ) );
Create an INI backend to read the data from pre-processed LCDd.conf and store it in the configuration tree:
my $ini_backend = Config::Model::Backend::IniFile
  ->new( node => $dummy );
$ini_backend->read( io_handle => $ioh );
Step 3: Prepare LCDd configuration model Your attention please. You may remember that we invoked instance on object to create the dummy configuration tree to hold LCDd.conf data. The instance method used the Dummy configuration class. Now, we must invoke instance again on object. But this time, instance will use Config::Model::Itself. This model is Config::Model s way of eating its own dog food. The configuration tree created there will be able to hold LCDd model. Hence the root of this special configuration tree will be called meta_root to avoid confusion with the other configuration root defined above (for the Dummy model). Still with me? Good, let s create this meta tree that will contain LCDd model:
my $meta_root = $model->instance(
    root_class_name => 'Itself::Model',
    instance_name   => 'meta_model',
) -> config_root;
Create the main LCDd configuration class and store the first comment from LCDd.conf as class description:
my $first_comment = $dummy->annotation ;
$meta_root
  ->grab("class:LCDd class_description")
  ->store( $first_comment );
Append my own text in this description:
my $extra_description =
    "Model information extracted from template /etc/LCDd.conf"
  . "\n\n=head1 BUGS\n\nThis model does not support to load "
  . "several drivers. Loading several drivers is probably a "
  . "marginal case. Please complain to the author if this "
  . "assumption is false";
$meta_root->load(
     qq!class:LCDd
        class_description.="\n\n$extra_description"!
);
Add legal stuff in the model:
$meta_root->load( qq!
  class:LCDd
    copyright:0="2011, Dominique Dumont"
    copyright:1="1999-2011, William Ferrell and others"
    license="GPL-2"
!
);
Add INI backend so configuration object created from LCDd model will be able to read user s INI files:
$meta_root->load( qq!
  class:LCDd
    read_config:0
      backend=ini_file
      config_dir="/etc"
      file="LCDd.conf"
!
);
Note that all the load calls above could be done as one call. They were split for better clarity. Step 4:Extracting LCDd.conf information Now that all information from LCDd.conf template file is stored in $dummy configuration tree, it s time to use this information to enhance the skeleton of LCDd model created above. Let s first find all the INI classes defined in LCDd.conf:
my @ini_classes = $dummy->get_element_name;
Now before actually mining LCDd.conf information, we must prepare several subs to handle them. This is done using a dispatch table:
my %dispatch;
First create the default entry which will be used for most parameters. This subs is passed: the INI class name, the INI parameter name, the comment attached to the parameter, the INI value, and an optional value type. It will return a string describing a model for simple elements. For instance: class:"LCDd::MD8800" element:Device type=leaf value_type=uniline default="/dev/ttyS1" description="device to use [default: /dev/ttyS1]" Here s the subroutine invoked by default. Let s create a an anonymous subroutine and store it in the dispatch table:
$dispatch _default_  = sub  
    my ( $ini_class, $ini_param, $ini_note,
         $ini_v, $value_type ) = @_;
    $value_type  = 'uniline';
Now, prepare a string that will be used later to create the ini_class model. This string uses Config::Model s serialisation format described in Config::Model::Loader:
    my $load = qq!class:"$ini_class"
                  element:$ini_param type=leaf !;
Get semantic information from LCDd.conf template comments (written between square brackets):
    my $info = $ini_note =~ /\[(.*)\]/ ? $1 : '';
    $info =~ s/\s+//g;
Use this semantic information to better specify the parameter:
    $load .=
        $info =~ /legal:(\d+)-(\d+)/
           ? " value_type=integer min=$1 max=$2"
      : $info =~ /legal:([\w\,]+)/
           ? " value_type=enum choice=$1"
      :    " value_type=$value_type";
    if ( $info =~ /default:(\w+)/ )  
        # specify upstream default value
        # if it was found in the comment
        $load .= qq! upstream_default="$1"!
           if length($1);
     
    else  
        # or use the value found in INI
        # file as default
        $ini_v =~ s/^"//g;
        $ini_v =~ s/"$//g;
        $load .= qq! default="$ini_v"!
           if length($ini_v);
     
The model (in serialised format) is ready, let s return it and exit the subroutine:
    return $load;
 ;
Now let s take care of the special cases. This one deals with Driver parameter found in INI [server] class. This sub will create a string for an enum element. The possible values of the enum are extracted from the comment found in the LCDd.conf file:
$dispatch "LCDd::server" Driver  = sub  
    my ( $class, $elt, $info, $ini_v ) = @_;
    my $load = qq!class:"$class"
                    element:$elt
                      type=leaf
                      value_type=enum
    !;
    my @drivers = split /\W+/, $info;
    while ( @drivers
            and ( shift @drivers ) !~ /supported/ )  
      # nothing, the work is done by shift operator
      # in loop test to skip all words in $info until
      # 'The following drivers are supported:'.
      # ok, that's a hack
     
    $load .= 'choice='
          . join( ',', @drivers ) . ' ';
    return $load;
 ;
This sub invokes the default sub and add a small feature to the model to ensure that DriverPath ends with / . This is ensured by the match="/$" snippet:
$dispatch "LCDd::server" DriverPath  = sub  
    my ( $class, $elt, $info, $ini_v ) = @_;
    return   $dispatch _default_ ->(@_)
           . q! match="/$" !;
 ;
Likewise, this sub invokes the default sub with the optional 4th parameter that forces the value_type of the element. In this case, we enforce an integer element:
 $dispatch "LCDd::server" WaitTime 
 = $dispatch "LCDd::server" ReportLevel 
 = $dispatch "LCDd::server" Port 
 = sub  
    my ( $class, $elt, $info, $ini_v ) = @_;
    return $dispatch _default_ ->( @_, 'integer' );
   ;
This sub returns a string for a list element with default values:
  $dispatch "LCDd::server" GoodBye 
= $dispatch "LCDd::server" Hello 
= sub  
    my ( $class, $elt, $info, $ini_v ) = @_;
    my $ret = qq( class:"$class"
                    element:$elt
                      type=list
                ) ;
    $ret .= 'cargo type=leaf
             value_type=uniline - ' ;
    $ret .= 'default_with_init:0="\" '.$elt.'\"" ' ;
    $ret .= 'default_with_init:1="\" LCDproc!\""';
    return $ret ;
 ;
Now that the dispatch table is ready, let s really mine LCDd.conf information. First handle all INI classes in the foreach loop:
foreach my $ini_class (@ini_classes)  
Let s retrieve parameters for this INI class from the LCDd.conf template:
  my $ini_obj = $dummy->grab($ini_class);
This will be the name of the lcdproc driver configuration class (e.g. LCDd::imonlcd):
  my $config_class   = "LCDd::$ini_class";
The configuration class will also be created in a serialised format. Let s create config class in case there s no parameter in INI file:
  $meta_root->load(qq!class:"LCDd::$ini_class"!);
Now, loop over all INI parameters and create LCDd::$ini_class elements:
  my @all_ini_params = $ini_obj->get_element_name ;
  foreach my $ini_param ( @all_ini_params )  
Retrieve the value provided in template LCDd.conf:
    my $ini_v = $ini_obj->grab_value($ini_param);
Retrieve the comment attached to the value provided in template LCDd.conf:
    my $ini_comment
      = $ini_obj->grab($ini_param)->annotation;
    # escape embedded quotes
    $ini_comment =~ s/"/\\"/g;
Retrieve the correct sub from dispatch table:
    my $sub = $dispatch $config_class $ini_param 
              $dispatch _default_ ;
Run the sub to get the model string:
    my $model_spec
      = $sub->( $config_class, $ini_param,
                   $ini_comment, $ini_v );
Attach the comment from LCDd.conf as class description:
    $model_spec .= qq! description="$ini_comment"!
      if length($ini_comment);
Then, last but not least, load class specification in the model, and end the loop aroung INI parameters:
    $meta_root->load($model_spec);
   
Now create a an $ini_class element in LCDd class (to link LCDd class and LCDd::$ini_class):
  my $driver_class_spec = qq!
    class:LCDd
      element:$ini_class
  ! ;
Since server and menu are not drivers, they have a special treatment:
  if (   $ini_class eq 'server'
      or $ini_class eq 'menu' )  
    $driver_class_spec .= qq!
      type=node
      config_class_name="LCDd::$ini_class"
    ! ;
   
Here s the treatment for LCDd drivers. Setup the model with a warped node so that a driver configuration class is shown only if the driver was selected in the [server] class:
  else  
    $driver_class_spec .= qq!
      type=warped_node
      config_class_name="LCDd::$ini_class"
      level=hidden
      follow:selected="- server Driver"
      rules:"\$selected eq '$ini_class'"
        level=normal
    !;
   
Now we can load the LCDd driver model in meta root:
  $meta_root->load($driver_class_spec);
 
Step 5: save LCDd model Still with me ? Good. Here s the last part, now that the model was created in memory, let s save it in files. Config::Model::Itself constructor returns an object to read or write the data:
my $rw_obj = Config::Model::Itself
     ->new( model_object => $meta_root );
say "Writing all models in file (please wait)";
$rw_obj->write_all(
    model_dir => 'lib/Config/Model/models/'
);
That s it. Once this script is run, the directory lib/Config/Model/models/ contains a bunch of files: You can see the resulting editor in my first blog on lcdproc. Conclusion and future steps (with you?) As mentioned at the end of this blog, the result of this model generation process is far from perfect, because the information retrieved from LCDd.conf template are not complete for this task (which is normal since these comments were targeted for users). Now, I d really like to discuss with project developers to improve configuration template to generate better models. For project owner, such an improvement would give them:
  • command lines to validate configuration
  • graphical configuration editor with integrated help
  • Configuration doc generated from the information stored in the template file
Please leave a comment on this blog (or send a message to config-model-users at lists.sourceforge.net) if you are interested in configuration tool generation for a project you contribute to. All the best

30 June 2011

Joachim Breitner: Flattr experiments

A while ago I registered with flattr. I found the idea of encouraging people to give kudos to people who do something on the web easily and meaningfully, by attaching a little bit of money to it. I had planned to use my flattr account only as a kudos-forwarder: All funds that I get by being flattred would be spend on flattering things that I like. At that time, flattr did not allow me registering my things without first uploading money, so I did not use my account. But recently, they changed this policy, so I added a few of my projects to the list of things people can now flattr: I almost always use the less intrusive text links. I fear that this means that people have to do an extra click before the have flattred the thing, but I still prefer it this way. Also, I do not use the automatic addition of things for each blog post, on the one hand because that does not seem to work with text links, and on the other hand because I don t think that each post is worth to be flattred. Generally, I avoid such closed-source walled-garden online services. I guess I make an exception this time because it is not a service that I run the risk of becoming dependent on. Flattr makes money per things flattered. It would be nicer if they only charged when people actually withdraw cash from their account, this way, many more people could do forward-only flattering for free, making many other people happy and appreciated, while still eventually making money.

Flattr this post

29 June 2011

Dominique Dumont: New configuration editor for LCDPROC

Hello The last version (1.247, available in Debian unstable as libconfig-model-perl) of Config::Model provides a brand new model for /etc/LCDd.conf. With this model, you can edit or validate your lcdproc configuration. To edit this configuration the first time, you will have to run:
config-edit -application lcdproc -force
The -force option is required to load the file the first time. (because the default LCDd.conf file contains configuration options for all drivers, even though only one them if usefull). You will get this screen:
lcdproc configuration editor

config-edit on lcdproc configuration

In this screen, you can setup the driver for your adress with a right click on Driver parameter. Once youv e selected the driver and clicked on store , the driver will be listed in the left part of the window so you can tune the parameters of this specific driver:

editing imonclcd paramaters

In this screen, I ve turned the backlight off and added a small note to remember why. This small note will be writted in a comment in /etc/LCDd.conf. Once all required modifications are done, it s time to save the configuration file using the menu entry File -> save Now, let s see the resulting file (which is a bit long due to the amount of comments in the original LCDd.conf file):
## This file was written by Config::Model
## You may modify the content of this file. Configuration
## modifications will be preserved. Modifications in
## comments may be mangled.
# LCDd.conf -- configuration file for the LCDproc server daemon LCDd
#
# This file contains the configuration for the LCDd server.
#
# The format is ini-file-like. It is divided into sections that start at
# markers that look like [section]. Comments are all line-based comments,
# and are lines that start with '
#
# The server has a 'central' section named [server]. For the menu there is
# a section called [menu]. Further each driver has a section which
# defines how the driver acts.
#
# The drivers are activated by specifiying them in a driver= line in the
# server section, like:
#
#   Driver=curses
#
# This tells LCDd to use the curses driver.
# The first driver that is loaded and is capable of output defines the
# size of the display. The default driver to use is curses.
# If the driver is specified using the -d  command line option,
# the Driver= options in the config file are ignored.
#
# The drivers read their own options from the respective sections.
[server]
# Where can we find the driver modules ?
# IMPORTANT: Make sure to change this setting to reflect your
#            specific setup! Otherwise LCDd won't be able to find
#            the driver modules and will thus not be able to
#            function properly.
# NOTE: Always place a slash as last character !
DriverPath=/usr/lib/lcdproc/
# Tells the server to load the given drivers. Multiple lines can be given.
# The name of the driver is case sensitive and determines the section
# where to look for further configuration options of the specific driver
# as well as the name of the dynamic driver module to load at runtime.
# The latter one can be changed by giving af File= directive in the
# driver specific section.
#
# The following drivers are supported:
#   bayrad, CFontz, CFontz633, CFontzPacket, curses, CwLnx, ea65,
#   EyeboxOne, g15, glcdlib, glk, hd44780, icp_a106, imon, imonlcd,
#   IOWarrior, irman, joy, lb216, lcdm001, lcterm, lirc, lis, MD8800,
#   mdm166a, ms6931, mtc_s16209x, MtxOrb, mx5000, NoritakeVFD, picolcd,
#   pyramid, sed1330, sed1520, serialPOS, serialVFD, shuttleVFD, sli,
#   stv5730, svga, t6963, text, tyan, ula200, xosd
Driver=imonlcd
# Tells the driver to bind to the given interface
Bind=127.0.0.1
# Listen on this specified port; defaults to 13666.
Port=13666
ReportLevel=3
# Sets the reporting level; defaults to 2 (warnings and errors only).
# ReportLevel=3
# Should we report to syslog instead of stderr ? [default: no; legal: yes, no]
# ReportToSyslog=yes
# User to run as.  LCDd will drop its root priviledges, if any,
# and run as this user instead.
User=nobody
Foreground=no
Hello=    Hello
Hello=    LCDproc!
GoodBye=    GoodBye
GoodBye=    LCDproc!
# The server will stay in the foreground if set to true.
# Foreground=no
# Hello message: each entry represents a display line; default: builtin
# Hello="  Welcome to"
# Hello="   LCDproc!"
# GoodBye message: each entry represents a display line; default: builtin
# GoodBye="Thanks for using"
# GoodBye="   LCDproc!"
# Sets the default time in seconds to displays a screen.
WaitTime=5
# If yes, the the serverscreen will be rotated as a usual info screen. If no,
# it will be a background screen, only visible when no other screens are
# active. The special value 'blank' is similar to no, but only a blank screen
# is displayed. [default: on; legal: on, off, blank]
# ServerScreen=no
# Set master backlight setting. If set to 'open' a client may control the
# backlight for its own screens (only). [default: open; legal: off, open, on]
# Backlight=open
# Set master heartbeat setting. If set to 'open' a client may control the
# heartbeat for its own screens (only). [default: open; legal: off, open, on]
# Heartbeat=open
# set title scrolling speed [default: 10; legal: 0-10]
# TitleSpeed=10
# The "...Key=" lines define what the server does with keypresses that
# don't go to any client.
# These are the defaults:
ToggleRotateKey=Enter
PrevScreenKey=Left
NextScreenKey=Right
ScrollUpKey=Up
ScrollDownKey=Down
# ScrollUpKey=Up
# ScrollDownKey=Down
# If you have only 4 keys, you can choose to use this:
# ToggleRotateKey=Enter
# PrevScreenKey=Up
# NextScreenKey=Down
# If you have only 3 keys, you can choose to use this:
# ToggleRotateKey=Enter
# PrevScreenKey=Up
[menu]
# You can configure what keys the menu should use. Note that the MenuKey
# will be reserved exclusively, the others work in shared mode.
# The following works excellent with 4 keys or more.
MenuKey=Escape
EnterKey=Enter
UpKey=Up
DownKey=Down
LeftKey=Left
RightKey=Right
[imonlcd]
Protocol=0
OnExit=2
Device=/dev/lcd0
# My fishes dont like the glow
Backlight=off
DiscMode=0
You will notice a few things:
  • Comments from the original file in section [server] and [menu] were kept
  • Unused drivers sections are gone
  • The fishy note about backlight was saved as a comment above the backlight parameter
If you need to update the file, you will have to run:
sudo config-edit -application lcdproc
The -force option is no longer needed. If you don t like to click, you can run:
config-edit -application lcdproc -ui none -save
For instance:
config-edit -application lcdproc -ui none -save 'server driver=imonlcd - imonlcd Device="/dev/lcd1" '
Further reading If you want to know more about lcdproc model, you can view: Under the hood I was too lazy to write myself the models of all drivers (about 3500 lines for them all). All models were generated from the LCDd.conf template file provided by lcdproc project. This blog explains how this was done. But the result is far from perfect. Event though LCDd.conf comments give a lot of semantic information, parameter types could be better adjusted and some of the examples provided in LCDd.conf confuse the model generator.
So the current comments are good, but not enough. In the future, we could decide on better structural conventions for the comments that would give users the information they need and give a model generator enough information to generate better models. This will hopefully be the topic of yet another blog All the best

28 June 2011

Pietro Abate: I'm going to debconf 2011

debconf11_banner.png
Got my tickets, now looking for a place to sleep... My first debconf. It's going to be gooood :)

Sam Hartman: Dream Plug

As part of trying to help with Freedom Box, I gained access to a Dream Plug The Dream Plug is one of the leading possible platforms for Freedom Box. Computationally it s sexy for a low-power device. There s a 1200 mhz arm with 512m of RAM. As a platform to enable people to create novel applications, it s great. It has multiple USB ports, two ethernets, a built-in 802.11B/G access point, bluetooth, audio, ESATA, Micro SD and full-sized SD. So, whether you application needs storage, networking, audio, or some interesting side device, you re covered. With the optional JTAG adapter it s even fairly friendly to developers: there are options for recovering from most failures and full console access. If you re looking at a reference platform that s still nominally embedded, but that allows you to play around thinking about what your application could do, this is a great option. However, especially for Freedom Box, it s important to remember that the reference board a developer wants is not the same as a cost-reduced product on which to actually deploy something for people to buy. The Dream Plug is wrong for every actual deployment I ve imagined. First, it s huge. If you happen to have free power plugs on your wall with lots of space above and below them, it might be an option. If however, you re like everyone I know and have power strips, constrained spacing, etc, then the industrial engineering will disappoint at every turn. I was hoping for something that kind of looked like an Apple Airport Express. It s significantly larger than that in every dimension. Also, the plug is oriented the wrong way for minimizing the fraction of the power strip it takes up. The power supply part of the device can be detached, although even that is way too huge for a power strip, and the cable between the power supply and the computer is fairly short. You can reconfigure the device without its plug nature: running a cord from a normal power outlet to the power supply. But then if you have to detach the power supply for heat management reasons, you get a cord from the outlet to the power supply and another cord from the supply to the device. Add a few USB or ESATA devices and the octopus of cables begins to resemble some arcane mechanism. (So far, no elder gods have appeared though.) The other issue is that you almost never want all the functionality. You pay for the bluetooth, audio and ESATA in terms of cost, heat and space regardless of whether you use them. I don t have a lot of applications that really take advantage of the full array of hardware. The firmware update mechanism is decidedly not targeted at end-users. The version I obtained had a hacked copy of Debian lenny. No mechanism was provided for replacing the image in a safe manner that did not potentially require the optional highly-non-end-user-compatible JTAG board if something got interrupted. You could either unscrew the device and get to the micro SD card containing the image, or run software to replace the image from within Debian lenny. It s possible to configure the boot loader to run an update image off USB or SD until that succeeds, but doing that is also a non-end-user operation. In conclusion, the name is perfect. This is exactly what hackers need to dream about the power of small computers everywhere. However we must not forget that there s a step required to turn dreams into reality. Just as with any fully proprietary product, Freedom Box will require cost reduction steps, semi-custom boards and actual OEMs to truly be usable. The claim in the previous sentence that the Freedom Box may have proprietary elements is disquieting to some. I think we can put together a software stack that is free with the possible exception of some device firmware. However, my suspicion is that anyone who turns that into a fully realized end-user product will add proprietary elements. I suspect some of the results of the cost reduction process such as resulting semi-custom boards will be proprietary. In many cases though, I suspect some proprietary software elements will be introduced.

25 June 2011

Andrew Pollock: [tech] On trying to find the resource limits of a running process on an old kernel

I had cause to try and get a core dump from a segfaulting process at work the other day, and I wanted to figure out if fiddling with /etc/security/limits.conf was going to do the trick (I didn't) or if I had to modify the initscript to include a ulimit -c unlimited call. Of course, on a modern system (>= 2.6.24), one would just take a look at /proc/PID/limits and get on with life, but unfortunately the system in question was running 2.6.18, so more fiddling around was required. I'd found something once before that told me how to do it with GDB, but all I could find this time around was a rather over-complicated Knol article, which made a bunch of assumptions (well mainly that the binary in question wasn't stripped). So with some help from the Knol article, I muddled through it. Disclaimer: I don't profess to be an expert on system internals like this, so if this eats your first-born, don't come crying to me. Firstly, you need to know that it's the getrlimit(2) system call that you want to be using, and then you need to figure out the number for the resource limit you want to retrieve. The man page for getrlimit(), tells you it's defined in /usr/include/sys/resource.h, but I've found that the actual useful bits end up being in /usr/include/bits/resource.h I wanted the resource limit for the maximum core dump size, which is RLIMIT_CORE and has a value of 4. Next, you need to know that the getrlimit() system call takes an integer and a pointer to an rlimit structure as arguments. We've just figured out the value for the integer, but we're also going to need to pass a pointer as the second parameter. A pointer to enough memory to hold an rlimit structure. Fortunately, the rlimit structure is pretty simple:
struct rlimit  
    rlim_t rlim_cur;  /* Soft limit */
    rlim_t rlim_max;  /* Hard limit (ceiling for rlim_cur) */
 ;
After a bit of grepping around in /usr/include, I determined that an rlim_t is essentially an unsigned long int, so we need to allocate a pointer big enough to hold two of them. Note that if we had an unstripped binary, we could have saved a lot of faffing around by just going
print sizeof(struct rlimit)
in GDB (assuming that the binary has the getrlimit symbol in it) The sure-fire way of figuring out how much memory we need for this pointer is to go
print sizeof(unsigned long int)
in GDB, and then double that (since we want two of them). On my system an unsigned long int is four bytes, so I'm going to want to allocate enough memory for 8 bytes. Now it's time to attach GDB to the offending process and see what the resource limit currently is. (gdb -p PID)
(gdb) print malloc(8)
$1 = 152186904
(gdb) print getrlimit(4, $1)
$2 = 0
(gdb) x/2xw $1
0x9123018:	0x00000000	0x7fffffff
(gdb) quit
So in this particular case, we've retrieved the soft and hard limits of the RLIMIT_CORE resource limit, and you can see that the soft limit is zero, and the hard limit is unlimited. Note that the getrlimit() function returns an integer as its return code, which is what the $2 = 0 is above. Now it's just a case of altering the the resource limits via the preferred mechanism, restarting the process and then repeating this GDB examination of the process to check they were changed successfully. Circumstances where this can all fall down would appear to be ones where the getrlimit symbol isn't present in the binary, or the binary is compiled as a position-independent executable. I'd think that in the latter case, the system is probably modern enough to be running a kernel that supports directly examining the resource limits via the /proc filesystem.

23 June 2011

Evgeni Golov: monitoring Adaptec RAID controllers in Debian

So I got my hands on that new machine, somewhere, somehow, and I had to make myself comfortable on it. The biggest difference in that machine and the ones I used before is the RAID controller, an Adaptec 5405, instead of the 3ware ones I used to have before. That means getting used to new tools, messages and all these things which I ll try to document here.Step 1: does vendor deliver?Well, yes, mostly. There is (mainline) kernel support for the controller, Squeeze s kernel will boot up just fine and I just throw my junk into /dev/sda and it will handle the whole raidy thingy itself. But what is when I want to check the health of the disks, to add a spare or modify the caching? Ask the mighty vendor and it will answer Yes, you can! .So I downloaded that asm_debian_x86_x64_v6_50_18570.tgz, unpacked and faced two debs, one i368 and one amd64. Yes, you could have saved half of the bandwidth if someone would have asked for the arch before, but who cares for some additional 60MiB today? So let s see what it does. Oh no, wait, there is a README ASM_IUG_for_Debian_and_Ubuntu.txt:
1. Make sure to be in root level access.
2. Install the ASM storman .deb package. For example, if the package is storman_6.50-18570_i386.deb,
   then install it using the following command dpkg -i storman_6.50-18570_i386.deb
3. Adaptec Storage Manager will get installed at /usr/StorMan
4. Add the line /usr/StorMan to /etc/ld.so.conf. Then run "ldconfig". This is needed for the arcconf
   utility to find the path of the libstdc++.so.5 library
Well, 1 is obvious, so is 2.
For 3: hum, /usr/StorMan? Ever heard of FHS? Don t think so.
For 4: WTF?! I prefer to get libstdc++5 from my local Debian mirror instead.But at least they provide a .deb, right? Uhm, no, it s an RPM converted via alien :( And don t dare to look at preinst, postinst and postrm (it extracts an own copy of Sun JRE 1.6u16, chmods around wildly on install and does rm -rf something on uninstall, did I see that some days ago on the webs?). Let s get rid of that package as soon as possible, I decided, and just keep arcconf (which will be described later), esp because StorMan itself seems to include some call-home functionality which I d like not to have:
cp -a /usr/StorMan/arcconf /usr/local/sbin/
apt-get remove --purge storman
Step 2: does community deliver?You can, by the way, get (better) packages at http://hwraid.le-vert.net/wiki/DebianPackages from Adam C cile (Le_Vert). I didn t test those much, but I currently use the arcconf package from there, which seems to be exactly what I need: proper dependencies and just the arcconf binary, no Java sh*t.Step 3: monitor the controllerAs this post is about monitoring, not ranting, let s continue. As mentioned before, I only have arcconf installed, which is just a cli to do stuff with the controller. If I understood the docs right, the actual StorMan is able to send notification mails when a disk dies or the controller gets eaten by aliens, but as I don t have StorMan, I have to do things myself.Adam has a aacraid-status package in his repository, which includes some minimalistic shell-daemon to monitor the output of arcconf. It didn t perfectly fit my needs (and had some hickups with my disks which refuse to report a vendor, whyever), so I decided to write something myself (slightly based on what Adam has done in aacraid-status, though).The result is on GitHub: https://github.com/evgeni/aacraidAs you can see the code contains (at the time of writing) exactly ZERO comments and there is no README either, but it s actually quite usable already.
  • aacraid.py is the main magic inspired by Adam s aacraid-status, basically just parsing arcconf output
  • aacraid-status prints all useful info about all controllers, arrays and disks (the output is pretty much like Adam s)
  • aacraidd is a small daemon which will monitor all controllers every (per default) 5 minutes and mail you in case of status-change
I am now running aacraidd and get happy mails when something breaks :) [running = running from /etc/rc.local, no init script yet :)]Step 4: monitor the disks via smartmontoolsThere is one little problem I have with arcconf: it s closed source and does magic to the controller.With the old 3ware controller I was able to monitor the disks with smartmontools/smartd using something like this:
/dev/twa0 -d 3ware,0 -a -s L/../../2/01 -m root
/dev/twa0 -d 3ware,1 -a -s L/../../2/03
This is possible with Adaptect controllers too (not through /dev/twaX obviously). You have to have the sg module loaded, which will result in /dev/sg[012] on my machine, with sg0 being the controller itself and sg1/sg2 the both disks attached to it. Having sg loaded, one can now use smartd with:
/dev/sg1 -d sat -a -s L/../../7/01 -m root
/dev/sg2 -d sat -a -s L/../../7/02 -m root
(-d sat is the important option here!)Thanks to Thomas Krenn Wiki: Smartmontools mit Adaptec RAID Controller for the basic info and ostlogd.spenneberg.net: Adaptec-Raid-Controller S.M.A.R.T.-Healthstatus monitoren for the pointer to the sg module!Step 5: relaxYupp, 4 steps are enough, go relax until the next disk dies (you will be doing something REALLY important that moment according to Murphy).

16 June 2011

Wouter Verhelst: Attaching in mutt

All mail clients suck. Some just suck less. But they all have their own peculiarities. mutt, for instance, is a full-featured text-mode mail client. As such, it's pretty popular amongst many Linux enthousiasts, including me. A common error made amongst mutt users is to talk about attaching a file in a mail, but then forgetting to actually do so afterwards. This is because mutt starts an external editor to allow you to edit the message in question, which since it's not mutt itself would seem to make it impossible to attach a file while you're editing a mail, requiring one to remember to actually perform the attach step. One solution to this problem could be to use the little script that Steve wrote, which will complain if you mention something about an attachment in a mail without actually attaching anything. While I'm sure it works to some extent, this kind of script has the downside that it's never going to be 100% correct in all cases (you might mistype the word 'attach', or you might use another word that you didn't think about when you wrote the script, or you might be replying to someone who sent you an attachment). However, a better way could be to realize that mutt does, actually, support attaching files while you're editing a mail text, by way of the 'Attach:' pseudo-header. It requires two steps:
  1. Make sure that you have set 'edit_headers' to 'yes' in your configuration. This will cause mutt to fire your editor on a file that also contains the (relevant) headers for your mail, rather than just the body.
  2. When you want to attach a file, rather than trying to remember to do so after exiting your editor, just add an 'Attach:' header to the headers section of your mail, with as argument a filename optionally followed by a description. When mutt finds that header, it'll attach the named file, and all is well.
Yes, of course, that does mean you'll have to change your habits, and actually remember to add the damn pseudo-header rather than be like me and still forget to attach files. But hey, can't help you with that.

12 June 2011

Steve McIntyre: How to not embarrass yourself with missing attachments in mutt

I keep on seeing people sending messages saying "see attached file" or similar in their emails, but then forgetting to actually attach the file. I used to do it myself lots, but then with the help of some ideas I found on the net I wrote the following script to use with mutt. To use it, use the setting "set sendmail=" to point at it.
#!/bin/bash
#
# mutt-sendmail
# helper script to reduce embarrassment with mutt :-)
#
# Copyright 2011 Steve McIntyre <steve>
# GPL v2
###
# save msg in file to re-use it for multiple tests
###
TMPFILE= mktemp -p ~/tmp -t mutt.XXXXXX    exit 2
cat > $TMPFILE
## Attachment keywords that the message body will be searched for:
KEYWORDS='attach patch'
## Define test for multipart message.
function multipart  
    grep -q '^Content-Type: multipart' "$TMPFILE"
 
## Define test for keyword search.
function word-attach  
    grep -v '^>' "$TMPFILE"   grep -v "^X-attached:"   grep -E -i -q "$KEYWORDS"
 
## Header override.
function header-override  
    grep -i -E "^X-attached: *none *$" "$TMPFILE"
 
###
# FINAL DECISION:
# chain series of functions, use !   && for logic connections,
###
if multipart   ! word-attach   header-override; then
    formail -I bcc < $TMPFILE   /usr/lib/sendmail -oi -oem "$@"
    status=$?
else
    echo "No file was attached but a search of the message text suggests there"
    echo "should be one.  Add a header \"X-attached: none\" to override this"
    echo "check if no attachment is intended."
    status=1
fi
rm -f $TMPFILE
exit $status

10 June 2011

Gunnar Wolf: Reading revolutions: Online digital text and implications for reading in academe A (very informal) review

It's been a long time since I last took some time to read First Monday A great online publication, if you are not familiar with it, that I would categorize (and no, I'm not probably well-informed in it to be authoritative) as dealing with social, psychological aspects of the cultural shifts the online world has brought upon us (often dealing with topics related to Free Software communities, the reason I first met the publication). Firstmonday is an Open Access champion from early on. It follows an approachable but academic format (this means, it is peer-reviewed, its articles give extensive lists of references, and the articles are not the short reads we have got used to finding on the net, but, quoting from their audience profile, English is not the first language of many First Monday readers; A large percentage of First Monday readers are not a part of academia; Cultures, educational backgrounds, and fields of study vary greatly among First Monday readers.) This means, it's at least a great publication for me to follow :) Anyway After a long time not following it, I have just read Reading revolutions: Online digital text and implications for reading in academe, by Barry W. Cull; First Monday, Volume 16, Number 6 - 6 June 2011 Nice, interesting read. As I was planning on telling about the article to a couple of friends more into the subjects than myself, I'll comment+quote some bits on it. Before going any further: The article makes several references to Maryanne Wolf. No relation to her I'm not lulling my (two? are you both still reading?) readers towards her work ;-) The article talks about the differences social, even dips into some physiological aspects that the activity of reading is sustaining due to the shift from an activity done mainly from books (or other similar printed material) to the computer screen. Of course, we all know from our own experience many of the basic traits Shorter attention spans, a different reading pattern (skimming instead of reading; browsing through several related items instead of in-depth reading a single text as a knowledge unit). The article begins with an overview of reading and humankind. Cull quotes Maryanne Wolf's phrase, despite the fact that it took our ancestors about 2,000 years to develop an alphabetic code, children are regularly expected to crack this code in about 2,000 days . An interesting point I never thaught of is the start of reading as a purely mental activity, detaching reason from verbalization, ~1200 years ago:
Interestingly, these early scribes first did their work by reading out loud to themselves. Not until the ninth century did monastic regulations begin requiring silent reading. By the thirteenth century the practice of men reading silently and alone became commonplace. This shift to silent reading was a profound change, one that Darnton suggested involved a greater mental adjustment than the shift to printed text
. One last important point in this older history, that I'm quoting because I know I'll need the reference later on for one of my texts is about reading as a social activity Yes, also related to the quietness I just mentioned:
Interestingly, with the democratization of the printed text, there was a return to reading aloud. Reading was a solitary silent process only for the educated elite who could afford to buy books. For the rest of the population, as Darnton pointed out, reading was a social activity which took place in workshops, barns, and taverns [and] while children played, women sewed, and men repaired tools.
After this introduction (obviously one of the most interesting parts to me), Cull gives numbers showing how reading is evolving (in the USA and Canada), and quotes some prediction on how the future will end up adapting. Of course, I live in a place with a very different society, so I cannot comment much. Then he confronts some studies regarding specifically leisure reading, as it is a much more trustable factor than just literacy (in a world as highly literate as ours is, many people only read when they have to and have never or very seldom experienced the pleasure of reading just for the sake of it), bringing into the discussion the Internet (and computers in general) usage patterns. I found also very interesting the next section, regarding the pattern changes many libraries are facing now, specially academic/research-oriented libraries:
For several millennia, right up until just two decades ago, the central role of a library was to collect and house physical texts: from clay tablets, to scrolls, to printed books (Battles, 2003; Manguel, 2006). While printed text remains essential to most academic libraries, today s libraries have also become a core conduit via which researchers access scholarly texts online. Just within the last few years, Canadian academic libraries, in a situation similar to libraries throughout the Western world, have reached an interesting tipping point librarians now spend the majority of their collections budgets on electronic instead of printed texts.
( )
Libraries are convinced that digital text, now in its infancy, is likely to have a long future. Not only do they purchase electronic texts, but most academic libraries have also become publishers of electronic texts, whether they are digitizing large portions of their book holdings, or focusing on scanning a relatively small number of archival documents from their unique special collections.
And yes, doing some work with our Institute's library, I can confirm this trend. About e-books: I have got quite into that topic since the Kindle won my heart (and my money!) half a year ago. The little device completly changed my reading habits, I have read lots more since I carry it. And yes, I have never considered a full tablet-like device The article talks long about the difference, about the disadvantage that multitasking means to the human brain (oh, do I suffer from it!) I liked this snippet, quoting Steve Jobs a couple of years ago, regarding an Apple e-book reader question:
When Apple was rumoured to be working on an e book reader a few years ago, CEO Steve Jobs expressed his lack of interest: It doesn t matter how good or bad the product is, the fact is that people don t read anymore, he reportedly said, continuing by stating that 40 percent of the people in the U.S. read one book or less last year. The whole conception is flawed at the top because people don t read anymore (Markoff, 2008). Nicholas Carr (2010) has summed up Apple s involvement in the tablet phenomenon this way: Jobs is no dummy. As a text delivery system, the iPad is perfectly suited to readers who don t read anymore .
The issue for me is, I do enjoy reading, but I am an information addict. I know that if I have parallel information flows, my attention will surely dilute between them. Of course, as I read this article on-screen, it was hard for me to take the needed discipline not to be distracted by IMs or IRC highlights during the whole reading (which was also as an excercise for myself ;-) ). I am surprised to see this on student preferences (and even more surprised to see this data comes from my university):
In a study of students at the Universidad Nacional Aut noma de M xico (UNAM), the majority of students preferred print, and 63 percent reported that they could bear reading a document on a computer screen for no more than one hour (Ram rez Leyva, 2003). When it comes to course textbooks, a marked student preference for paper over e books has recently been found (Woody, 2010).
As we approach the end, it talks about another important topics I have often tried (and often failed) to communicate to my users: That of paratext, the meaning of the different texts, covers, items, layouts, etc. that are not part of the text itself but do shape the way we face it. To some of us, this seems obvious. To others, it is so hard to understand It closes with two more topics I will refer to. One is the permanent connectivity. All the time, more people are connected virtually all of their waking time. This affects not only learning habits but priorities. Will this near constant access to information interfere with students desire to comprehend and remember information, necessary to the educational process of turning it into knowledge? Author and university business school lecturer Don Tapscott recently suggested that students might not have to stress about the details those you can check Finally, regarding the continuity and ellaboration found in texts that are each time more common He quotes Maryanne Wolf:
I am worried about kids who are immersed in digital culture. They will get to college and they will have been Twittering so much that they won t have the patience to read those really long cognitively convoluted and complex sentences. They may not have developed those rich networks which are required in order to read at a high level of sophistication. The effort is what we are going to lose. They are becoming not so much a lazy reader, but an atrophied reader
As you can see, not only this post is meant to tell my couple-of-interested-friends to read the article, but it's mainly meant as a mental placeholder for myself. I will be surely refering to some of these items.

7 June 2011

John Goerzen: Back from Joplin

I m just back from spending a few days volunteering with the tornado recovery effort in Joplin, MO. The biggest image that remains in my mind is of the first time I saw a person picking through a large pile of rubble. The person was standing on top of what used to be a house. Now it was a pile of wood, glass, carpet, siding, and roofing material. I m sure there was hope for finding some treasure or other maybe a photo album or videos of children. In any case, it made me feel so lucky, even unfairly lucky, to have not had to go through that. This scene was repeated several times, but mostly the houses that devastated appeared abandoned by the time we were there, now two weeks after the event. But I heard stories, and lots of them. The victims of the storm, who were perhaps trying to rebuild that part of their house that got smashed by a tree or a pickup, or trying to get their intact belongings out before abandoning the house, or whatever, were mostly surprisingly upbeat. They were working out in 95-degree heat, many without electricity, running water, or sewer service. Almost every person I met that suffered a loss from the tornado wanted to tell their story. Many also told of their plans for the future, which were full of hope and even upbeat. These were people doing a hard job in terrible conditions and still showing hope. Another testament to the disaster was the most unusual set of vehicles you ve ever seen parked at any hotel you can care to think of, for at least an hour-and-a-half radius in the direction I came from. Besides the usual cars and minivans, there might be FEMA vehicles, electric company trucks, Red Cross vans, construction trucks of every kind, police and law enforcement from all over, etc. There was quite obviously an influx of people helping out in Joplin. My primary task there was to provide communications support for the effort as an amateur radio operator. Amateurs (or hams ) are something of a volunteer first responder of sorts during times of crisis; most of us own and are very familiar with operating equipment that can communicate over very long distances without the need for any on-site infrastructure. Amateur radio was the only method of communication for some Joplin hospitals in the immediate aftermath. The communications emergency is over, but the response isn t. I was assigned to work with the Salvation Army. They were doing a lot of things in Joplin, and had hundreds of volunteers working with them. I don t think I even know what many of them were doing I do know they had set up several warehouses across the city working with donating clothing, food, etc. The part I was involved with was primarily the canteen operation. The SA sent in food service trucks from several parts of the country. These trucks would roam up and down the streets in the damaged area, trying to get past every single street several times a day. Anybody that we could see would be offered food and water. No strings attached, no questions asked. This included homeowners, electric line workers, construction crews, sanitation workers, and quite a few nonprofit groups that sent well-meaning and useful volunteers into the area but didn t think to provide them with a large supply of water due to sending them into an area without any. Oops. In any case, with extreme heat and no running water, conditions were dangerous. The canteens also knew of certain at-risk families that were living in homes that were mostly intact in the disaster areas, and made a special point to check in on them. They also generally looked to make sure that people looked like they were healthy. Each canteen also had a counselor on board that would visit with people while we quickly prepared their meal they all seemed to welcome that. Amateur Radio s Role The operation of this size had quite a logistics challenge. I d hear of things like an unexpected need of 70 lunches, or a semi showing up with donations before there was space, or an unexpected but very welcome donation of a large quantity of ice cream without a place to store it (so the canteen trucks, which have freezers, needed to pick it up quickly). That s where us hams came in. Each canteen had an amateur radio operator on board. Each major location also had a ham stationed there, and the head of operations also often had a shadow a ham that would follow him around wherever he went to relay messages back and forth. We also had hams with pickups (with radios in them, of course) that could transport things around the city to places that needed them, hams at headquarters managing all the communication and generally investigating questions that didn t have immediately obvious answers, etc. Radios were used instead of cellphones for a few reasons. One big one is that everybody on the operation can hear what everyone else s needs are, since it s a group communications situation rather than one-to-one. It s easy to give a general alert to everyone ( come get your ice cream now please! ) and people that have suggestions can chime in. This came in extremely handy more than once. Also, it frees the people doing other jobs from having to spend time chasing someone s voicemail, finding phone numbers, etc; that gets delegated to us in some cases. I heard from the head of canteen operations, for whom this was the first disaster he d worked that had amateur radio support, how wonderful it was to have this going on. I also heard a secondhand report that some police officers that were also amateurs had listened to our operation and reported that we sound more professional than 911 dispatch and do a better job. On Sunday I was assigned to a canteen. This meant I didn t have a lot of radio traffic to pass, so although I had it in my ear all day, I wasn t actively talking on the radio very much. So I rode in back, helping hand out water, carry meals to people, and so forth. On Saturday, I was the shadow for the head of operations. That was a difficult task, because he barely ever moved at a pace slower than a run, sometimes would abruptly zip out somewhere, etc. But it was also enlightening and vital. He was a real get it done sort of guy, and was the key to quite a few things. Having someone available to relay questions to and from him was a good thing. And today I worked as a transport person and at headquarters. Due to not having a pickup there, I didn t actually get called on much to transport things, but in general between jobs the whole time I d act as a runner if needed, or simply try to figure out the details of how things were run for next time. I wound up taking net control (being the control operator at headquarters, and generally managing communications so that people don t talk over each other and such) for about an hour. So I got to do a little of just about every amateur radio task. Thoughts I am thankful for the opportunity to go, and the good feeling of helping people in need the first I ve ever had the chance to do that in a disaster. It s a good feeling to have a skill that is useful and appreciated. Sometimes it felt like handing out food and water is something pretty small in the scheme of things. But on the other hand, it gives people a chance to have contact with someone that cares, an opportunity to have people that can notice problems drive by a few times a day, and an opportunity to help meet people s basic needs. And sometimes in a fluid situation, there might be more volunteers than are needed, so I did spend some time sitting waiting for the next task. But overall, I m convinced that the work I helped facilitate was a good thing and provided a good and needed service in Joplin. This has been quite the experience and I m sure it s changed me too, though I don t yet know how.

5 June 2011

Russ Allbery: git-pbuilder 1.22

I actually released this on May 23rd, but I never posted an announcement here, and I think it's worth at least a brief note (if for no other reason that I can remember what I've been working on). The new version adds support for reading COWBUILDER_BASE from the environment so that you can use a different location for your cowbuilder setups if you'd like. It also removes an extra level of quoting around options in $BASE that caused problems with the shell. The latter is weird, and I still don't completely understand it. I was setting a variable like:
    OPTIONS="$OPTIONS --basepath '$BASE'"
and then using it with:
    pdebuild --pbuilder "$BUILDER" -- $OPTIONS
(with some additional complexity). I expected, since $OPTIONS was not quoted, that this would expand $OPTIONS and then do shell parsing again, which would strip off the other level of quotes. But this doesn't seem to actually work; instead, the quotes are left in, at least for some shells. This is apparently some corner of shell quoting that I don't understand. The chances of the base path containing shell metacharacters is quite low, so I just went with the solution that feels "underquoted." Anyway, you can get the latest version from my scripts page.

Next.

Previous.