Credit for finding out how to do this goes to dims, who has been doing lots of cool Android hacking lately: http://davanum.wordpress.com/2007/12/18/android-task-manager-primitive-prototype/ If you're interested in Android and what it can do, you should be following his online journal! As a way to keep pushing and testing Hecl, I decided to see if I could copy what he'd done in Hecl. It has indeed produced a few improvements to the Java code. That done, making it work was short and sweet:

set layoutparams [linearlayoutparams -new  FILL_PARENT WRAP_CONTENT 
set layout [linearlayout -new $context]
$layout setorientation VERTICAL
# Create ourselves some commands to access Android internals.
java android.app.ActivityManagerNative activitymanagernative
java android.app.IActivityManager iactivitymanager
java  android.app.IActivityManager$TaskInfo  taskinfo
java android.content.ComponentName componentname
java java.util.List javalist
set am [activitymanagernative getdefault]
set tasks [$am gettasks 10 0 [null]]
set len [$tasks size]
set tasklist [list]
for  set i 0   < $i $len   incr $i   
    set baseactivity [[$tasks get $i] -field baseactivity]
    lappend $tasklist "Task: [$baseactivity getpackagename]"
 
$layout addview [textview -new $context -layoutparams $layoutparams \
         -text "Currently running tasks"]
set lview [basiclist $context $tasklist -layoutparams $layoutparams]
$layout addview $lview
$lview requestfocus
set callback [callback -new [list [list SelectTask]]]
$lview setonitemclicklistener $callback
heclcmd setcontentview $layout
proc SelectTask  parent view position id   
    [activitymanagernative getdefault] movetasktofront $position
 

It could have been squeezed further by avoiding some of the temporary variables, and perhaps also by implementing a mapping between java.util.List and Hecl lists. I think one of the next things I want to do is work on some infrastructure so that people will be able to actually work on scripts on their phone. That's sort of a departure from the past (most phone keyboards would be sheer torture for inputting long scripts), but it's a cool demo in any case.

I have just read a rant by Sean Middleditch about bad project management [1]. He describes his post as “personal, rather angsty, and especially whiny” but I think it’s useful and informative. He makes some interesting technical points about PHP programming (I wasn’t aware that there were so many ways of easily getting things wrong and having difficulty to get them right). But of course this isn’t all limited to PHP, the web site WorseThanFailure.com has anecdotes about mistakes of similar calibre being implemented in every language imaginable. Sean is apparently considering leaving the computer industry after having numerous bad experiences of having highly paid people mess up projects while he gets paid a lot less to try and fix the worst of the bugs and get the systems working in production. I understand what it’s like, I have occasionally idly contemplated leaving the industry after bad projects. However the fun of working on free software combined with the amounts of money that I can earn in the computer industry made me quickly abandon such ideas. His stories in some ways resemble my experiences in working as a contractor, most of my contracts have been profoundly weird for various reasons (I’ll use the WTF [2] category of this blog to document some of them). I had two theories as to why I ended up in so many strange contracts, one was that I was in some sort of Twilight Zone and the other was that taking contracts based on the amount of money offered puts you at high risk of being employed by people who have no financial pressure to do things in a sensible manner. My advice to anyone in such a situation is to try and find a contract position paying an unreasonable amount of money. Getting more than $80 an hour (the rate Sean cites as being paid to the idiots who cause problems) is going to be difficult, but getting $50 or $60 an hour is much easier to achieve and should be enough to alleviate the pain of working on doomed projects.

• [1] http://blogs.awesomeplay.com/elanthis/index.php/archives/2007/11/29/432/


• [2] http://etbe.coker.com.au/category/wtf/

Share This

Debian could use more manpower, but is it actually easy for new contributors who would like to help to do useful things, and get the impression that they actually improved Debian? There are several problems here:

• Find bugs that are not too hard to fix. I don’t know about your packages, but in mine, there are some bugs that are easy to fix, and it’s just a matter of finding the time. If someone provided a patch, I would be very happy and apply it or provide feedback as fast as possible.
• Find packages with active maintainers. It is no secret that if you choose the wrong package, your patch could very well sleep on the BTS for years.
• Find bugs that actually matter. It’s not strictly a requirement. But fixing bugs in packages that should probably be removed from Debian instead is not really rewarding.

I think that other projects are better than us at providing directions to newcomers. Gnome has the whole Gnome Love thing, for example. I’m thinking about building lists of “interesting” bugs. That would include RC bugs without patches, of course, but could also include a list of bugs based on an usertag that would mean “This bug is suitable for new contributors (it’s not too hard, and you could learn things fixing it). If you want to work on this bug, I’ll provide help and feedback and integrate your patch ASAP.” (This is very different from the “help” tag, which usually means “I couldn’t fix this, it’s too hard, I need help.“. It’s a bad idea to direct newcomers to bugs that are too hard for the package’s maintainer!) Additionally, a nice feature would be to be able to filter the list of bugs with the packages that the user has installed.

• What do you think?
• As someone willing to contribute to Debian, do you often find it hard to find stuff you could do?
• As a maintainer, do you have a lot of bugs that could use such a tag? Would you use it?

Comments are open, please us them ;)

After half day of playing with Wine, MinGW and friends, I managed to be able to automatically build Windows versions of both python-gammu and Wammu. However I do not have environment to actually test these versions (except for Wine), so I would really welcome if some Windows users could do some testing. I expect some strange crashes at beginning, but hopefully we will be able fix it to produce working Wammu version for Windows in future. You can get the installer here: http://tmp.cihar.com/wammu-0.26-setup.exe It's NOT final or stable version, but as the only changes which happened since last release were either minor or related to cross compilation, it should be equal to combination of Gammu 1.16.0, python-gammu 0.24 and Wammu 0.25, so don't be confused by versions. PS: Okay, when application works in Wine, it does not mean it will work in Windows, see bug report for details.

I just released version 0.25 of Wammu. This release brings new icon set thatnks to David Corrales and fixes various crashes. Full list of changes:

• Fall back to Add methods if Set is not supported.
• Fixed phone number validation.
• Fixed crash when org.freedesktop.Notifications service is not provided.
• Correctly report why guided wizard can not connect to phone.
• New navigation icons, thanks to David Corrales.

There is still no binary for Windows. I don't have time and environment for maintaining them. Volunteers are welcome!

Yes, Bastian, there is a way to do what you want. I believe I told you from the very start: refactor reportbug and implement reportbug-ng on top of the existing code. But no, you chose to reimplement everything (a typical thing to do for GUI programmers) and now you are asking us maintainers to change the way we've been doing things for years? You also make presumptuous statements about how we deal with bug reports. If you personally hate how certain packages prepare bug reports, then maybe you should personally suck it up and use different software? Seems like a more logical and less intrusive way forward, then expecting others to "send a friendly mail" to ask for more information on a bug report. Maybe you have all the time in the world, but I don't. I can work on e.g. mdadm (which uses an interactive bug script) only on rare occasions, and then I'd rather fix and close bugs than to indulge in another iteration of bug submitter ping-pong. You are also personally annoyed by long pre-subject texts, which you doubt anyone reads? I don't even bother to challenge that, but let me say that pre-subject texts are there to prevent stupid bug reports, or bug reports filed in the wrong place, and to take load off the maintainer. So you chose to ignore them? Given the projected user-base of your tool, I'd say you should rather force people to read them by asking them to transcribe the text. If you don't want to pop up a terminal, well, why the heck didn't you integrate debconf properly, while reusing reportbug, and taking a step forward to provide a proper interface for bug scripts? Why do you even bother to whine about interface issues at this point? Feel free to take over my packages, which make use of interactive bug scripts. I see zero reason to change them, and I will not. NP: The Flower Kings: Paradox Hotel

Further to my musings on a debhelper-type script to handle tdebs, I'm considering two modes:

1. maintainer mode - the default. With no options, operate on all .po files in all identifiable gettext directories (if -d /^po.*/), creating absolutely minimal control data on-the-fly, installing the directories and the binary translation data (.gmo) and building the .deb for each translation (with nothing else in the package). Emdebian will use this mode when cross building.


2. translator mode - when passed the name of a translation locale (either in the gettext form, e.g. sr@Ltn, or the filename form, sr+ltn) only builds a package for that po file. Should be relatively simple to create upload wrappers that can handle single translations in a similar manner to current uploads from porters.

Likely that some kind of update tool is going to be needed to retrieve the updated translations from the locale repository and merge back into the upstream package - which in turn means some form of "translation source" in the repository (the po file as a gz maybe?). Need to keep the POT file somewhere as a source file too so that new translations can be created easily. Such a tool would also need to be distribution-neutral as upstream may not be using Debian at all. Likely to investigate linkage with the Translation Project on an opt-in basis. (Not all upstreams use TP).
I can see an apt-locale package in the offing . . . - get source, build a single tdeb for a new or updated translation, query the locale cache, partner to langupdate . . .
Still not convinced on the script name: em_installtdeb because this script also generates stuff and the 't' is almost hidden in the name. (Eventually, I'd seek inclusion into debhelper and change the prefix accordingly).
Also not sure how to handle the package version string - this isn't commonly in the POT file (and may often be wrong or apply to the upstream version) but some Debian-compatible versioning will be needed. May need a stump debian/changelog that is discarded during building and which is generated within maintainer mode - i.e. held in the tdeb source.
Yes, I know some of this diverges from the Debian TranslationDebs approach but this is done with good reasons:

1. Emdebian does not want more than just the translation binary files in the tdeb package.


2. To get a working implementation soon, Emdebian is doing without the .tdeb suffix and going with .deb


3. No dependencies at all


4. No "language packs" as Emdebian needs full control over individual translation files, not over mere collections of localisation support files.

I was considering importing my car to Switzerland. When I moved in 2002, I asked the customs office about the process and was told that I'd need to pay taxes and fees, so I postponed the import until Day Unknown. Today, a very friendly customs official told me that this is not true and that I could have imported my car duty-free if I had done so as part of my move. Slightly annoyed, I went on to discover what those duties would be today. I found out that there are seven different types of fees I'll have to pay, and tried to understand the reason for these fees:

1. To import a car, you need a form 11.010, downloadable from the Swiss Customs Office. Because each download causes extra work for the administrator, they charge a nominal fee of CHF 0.70 to get the PDF file.

2. I take that form to the customs office. There, the officials will assemble around the car and attempt to lift it. I don't know why they do that, but they charge you between CHF 12 and CHF 15 per 100kg of weight. I think it must be recompensation for the hard physical labour. Also, each customs official can lift 100kg, which explains those figures they seemed a bit arbitrary at first.

3. Next, they'll ask 4% of the estimated value of the car as a car tax. They do this because the value of a car is directly related to the area it covers, and since Switzerland is so small, you effectively have to buy a couple of square metres for the car. It's not quite as easy as that though: once I bought the area under my car, I have to move the car away, because I cannot park my car on the area I just bought. I have to buy parking space for that. If I don't want to buy a parking space, I have to keep the car moving. In order to keep the car moving I need to fork over CHF 40 per year for a permit to drive the car on Swiss highways.

4. Now, I pay 7.6% value-added tax. It makes no difference that the car isn't new, that I am not selling or buying it, nor that I have already paid 16% VAT in Germany when I bought it. Since I am about to "consume" the car in Switzerland, I have to pay consumer tax. Since I also consume the physical labour the officials put into the car lifting exercise, as well as the area under the car I bought, I pay VAT for (car value + lifting tax + area under car). Unfortunately, the European Union will not pay back the consumer tax I previously paid as part of the export, since I already consumed the car there.

5. I then get a report about the import. This costs CHF 20. I don't need this report, but I have to buy it. The reason is that the computer admins are so overworked serving PDF files to future importers that they have not had time to stop the computers from printing this report, and the special paper and toner used by all administrative offices in Switzerland costs about CHF 20 per page. An alternative explanation is that CHF 20 is the smallest bit of "money" in Switzerland, everything else is "change".

6. I will also have to pay annual taxes for possession of a car, the value to be determined by the custom officials. Since I already paid for the area under the car while moving and while stationary, I think the annual car tax is levied for environmental reasons. A lot of people drive through Switzerland to get from Germany to Italy or from Austria to France, pumping a lot of exhaust gas into the Swiss air. This makes them guilty, just like inhabitants of Switzerland who own a car are guilty. Due to legal reasons, the Swiss government can only punish Swiss people for those sins, so the annual car tax is a little higher to cover for all environmental damage. It is doubtful where the money goes, though. I also have to continue paying taxes in Germany, because I still have a residence with my parents.

7. Finally, I have to purchase a car insurance. That insurance does not insure the car, it insures the others on the road. Actually, it is a driver-car-dependent insurance, meaning that the others are insured only if I am the driver of my car. If I drive another car, or someone else drives my car, the others will not be insured. unless I pay higher insurance fees. Because cars with a larger area under them and those that require more people to lift them are more dangerous, the insurance fee is proportional to the car density. At least I can give up my German insurance and be covered by the Swiss insurance. However, I cannot keep my German insurance and be covered in Switzerland. I think this is because the head of customs department and the CEO of the insurance company have sex with each other.

It's been a great day, given how much I learnt. I finally understand why people have fought wars over taxes. I think I may leave the car in Germany. PS: Yes, this post may be considered hyperbole. NP: The Pineapple Thief: 8 Days Later

Ok guys. After spending several hours of this weekend to package the latest release of Norman Walshs DocBook: The Definitive Guide, I’m now proud to tell you: It’s done! I was able to build the package with a free Java engine (GIJ) so docbook-defguide can stay in main. However, it was some kind of disappointing: Sun Java needs an hour and a maximum heapsize of 512MB to build the package on my system. GIJ needs 16 hours and a maximum heap size of 1GB to build. kaffe, which I tried too, fails much earlier than GIJ with a maximum heap size of 512MB. So I decided against it and for GIJ. If you know of a way to speed up the build process (besides the possibility to buy a faster system … except you want to make it your christmas or birthday present for me *g*), don’t hesitate to tell me. The packaging files are in the Debian XML/SGML groups SVN repository. However, expect the package in your Debian repository soon (guess, my sponsor wants to rebuild it, which may need another 1x hours :)). Update Ardo van Rangelrooij kindly offered to build the package on an AMD X2 4600+ with 6GB. The build time decreased to at least 7-8 hours. The package will be uploaded to the Debian archive within the next days.

Sometimes it is extremely tempting to wave a huge, heavy, spiked cluebat around. Today I've decided to give in to this temptation. The case in point is the upload today by their maintainer of first cwidget and later aptitude. The fact that the maintainer blogged about both uploads probably means that he's pretty happy about it. Unfortunately I, and people in the Debian release team, were less than amused. Reason is that the uploads set back a complex transition of apt and related packages by at least a week. This is a transition we'd already been following and trying to get into testing for over a month and which was finally as good as ready to go. So what was so wrong about these uploads and what could (should?) the maintainer have done? First of all he should have realized that aptitude has become a rather central package in Debian with strong ties to apt and thus to a lot of other packages. Second, he should have checked whether his previous uploads had already migrated to testing and, if not, why not. The excellent testing migration page for aptitude (which is linked from its PTS page clearly shows that it is tied in a transition involving about a 100 packages in total. The right thing to do in such a case is to contact the release team (preferably at the debian-release mailing list, or at #debian-release). This would undoubtedly have resulted in a request to delay the uploads a few days until the transition had finished. Unfortunately that did not happen and cwidget was uploaded. Because of an ABI bump it ended up in NEW. Because of the transition I did a quick request to Joerg Jaspert to please delay accepting cwidget until the transition was over. But then a third mistake, and arguably the most serious one of the lot, was made. aptitude was uploaded for i386, built against the cwidget library which had not yet been accepted into unstable. Basically that means that an uninstallable package was uploaded. And of course it meant that at that point all efforts to finalize the transition for apt went down the drain. Some alternatives were discussed on how to deal with the new situation, including a sourcefull upload of the previous version of aptitude, but in the end it was decided to just accept the delay as one of the more annoying facts of life and instead ask Joerg to accept cwidget from NEW. In the end the damage may be a bit less than a week if the buildds cooperate (which they probably won't with cwidget still stuck at the wrong priority) and the RMs decide to force things. I sincerely hope that this story will make all Debian Developers and Debian Maintainers a bit more aware of the broader context and consequences of uploads. Oh, as I'm not an RM myself you may wonder what my interest is in this. We've got this great new feature in Debian Installer that adds support for multiple CDs during an installation (a feature that was lost with the integration of base-installer into D-I). However, we can only upload the relevant D-I component after apt 0.7.9 has reached testing...

Ah. Back home. All in all, it was a quite nice trip. I like to get actually to meet the people that I communicate a lot electronically with. Thanks Extremadura for making this happen. The last day, we stayed at the residense instead of going to the local university, as the internet at the residense was much more stable than the one at the university.
But it was still heavily firewalled. Having the svn:// port firewalled doesn’t make it too easy to work with svn - and having ssh connection time out every 5 minutes also makes it difficult to try work on some remote machine. Please. Get the network better for next time. And more bandwidth. And thanks to Nekral for the champagne && cheese ;) Now tired - and times to sleep.

When you live in NYC and have a demanding job, you tend to ignore the city (at least I do), that is until guests descend upon your place. And since a Large Family Clan has recently landed in my apt, I have spent the last few days trekking north, south, east, and west, across bridges, in parks, and memorials, eating, drinking, and passing out at night after the constant flurry of activity. Yesterday we headed pretty much as far north as you can go to pay a visit to the lovely Cloisters sitting high on a cliff. The Cloisters provides stellar views of the Hudson at the same time as it transports you back in time when a lot of energy was put into scribbling religious material on paper in really stunning and ornate ways. I have not paid a visit to the Cloisters since my undergraduate days and after yesterday’s stroll, I am sorry I waited until the frigid winter to do so. It is an *incredibly* serene place, especially the inner courtyard gardens, and if you need serenity (and I think anyone who lives in NYC, needs to counter the low-grade and high-grade exposure to constant noise with some noiseless environments), this is the place to go. We then made our way to the Columbia area to check out the campus, St. John the Divine (currently under renovation), and so I could pick up a book being held for me at the Book Culture bookstore (which I wish was a lot closer to me than it is)… It was nice to escape the blustering winter conditions and browse the rows of books in a warm and well lit environment. But after purchasing Information Please: Culture and Politics in the Digital Age, parts of which I am hoping to teach next semester, and flipping through the book, my new found serenity was replaced by some serious offense when the only index I could find was an author index. There was no subject index in sight, which at the time left me totally surprised!! Anyone who is in the business of using books as research tools knows the index is —-> indispensable. And a well indexed book is much appreciated (never mind what a non-existent index does). In fact, I felt like I stumbled on some rare object because I don’t think I have ever seen an academic book published in the last 30 years not sporting this useful tool and I wonder if 1) I have a bunk copy 2) The editors/authors forgot to include it and just pushed out the book anyway 3) This was a willful choice made for reasons hidden to the reader. I think I may have to contact Duke University Press and let me know they momentarily robbed me of my serenity

There's no way around it: I'm a bit of a Rails fanboy. While it's got it's glitches, it's certainly made the part of my life that involves writing web applications a hell of a lot easier, and introduced me to the wonder that is the Ruby programming language. However, there are plenty of times when Rails just isn't a good fit. It's not particularly simple to deploy, it's quite heavy, and it does have a definite learning curve. So, when I need to write something simple, I've just used Ruby's built-in CGI support. But I will do so no longer. For I have found Camping. The name doesn't make a whole lot of sense, and until you come to grips with Why The Lucky Stiff's weird sense of humour, the docs will probably make you think that acid trip you took several years ago has just kicked in again. However, the purpose of Camping is pretty easy to understand: it allows you to make simple (CGI level) web "applications" using Rails-like (or more properly, MVC) concepts, which are fairly easy to write and deploy. If you're familiar with Rails (or probably most of the other Rails-clones that have sprung up in other languages) then Camping will probably smell at least faintly familiar. You have routes, which map URLs to controller actions, which retrieve models and feed them to a view which sends results back as HTML. From that perspective, Camping is easy to learn -- it's core concepts can piggyback on existing knowledge, and you can get started very quickly. Using your Rails-fu, however, will only get you so far. For one thing, the API is similar-but-different enough that while your first couple of simple experiments will probably Just Work, getting more complex things done will either fall under the "different" or "difficult" headings. That isn't meant to be a slight on Camping, though -- if you want to do horribly complex things, then you're heading into territory best served by Rails anyway. But there is a bit of a middle ground where the utter simplicity of Camping is stretched a little, but it's still more appropriate to write a Camping app than a Rails app, and it's important to remember that you're not using full-blown framework when you thump up against something that's beyond-trivial in Rails, but is not quite so simple in Camping. Camping is a microframework -- it says so right there on the front page. Why's intention is that Camping will always be provided in less than 4kB of code. So you're never going to get, for instance, the broad range of HTML helpers that Rails' ActionView provides to make writing HTML templates so easy, or the Prototype JavaScript framework shipped with the main code. If you don't want to blow a steam pipe, then, when starting out with Camping, you need to think "this is a lot easier than hand-writing CGIs" instead of "this is a lot harder than writing a Rails app". There are a few things that are undeniably a pest in Camping, though. The docs are a little incomplete and hard to follow (even when you account for Why's "unique" style of writing), and some of the coding tricks that are employed in making the framework can make debugging a bit tricky. They're not showstoppers, but it's worth knowing about them in advance so you don't go nuts when you're first using the framework. If you're not the sort of person who needs small, self-contained web scripts, then I'd say you'll probably never get much benefit out of Camping. On the other hand, if you're still writing your CGIs against the "bare(ish) metal", then I would strongly encourage you to take a look at Camping, to make your life just that little bit more delightful.

Its been a couple of weeks since the Open Source Developers’ Conference in Brisbane, but it was only now that I’ve got the time to blog about it. This is due to some work that got piled in my backlog (I haven’t been lazy enough to have this work all automated yet :(). First off, my trip to Brisbane was a long one, due to the UNDP travel agency giving me a route taking me to Bangkok first, because of my exchange grant’s papers made in short notice. No matter: this being my first ever international trip, this meant that I would be visiting two different countries in just one shot. Bangkok was just an overnight stay though, so I didn’t see much, but their new airport was nevertheless impressive. Arriving there at almost midnight, the only bright places I saw were the big Suvarnabhumi airport and the Novotel where I had my layover. After some sleep, I had a pleasant morning, but only a short one at Bangkok, as my flight to Brisbane followed after: The Brisbane flight was long, and I arrived just an hour before midnight. Now, my next problem was getting a place to stay. I took an airport shuttle to the Royal on the Park, where the conference will be held, first to see if there are any free rooms, or barring that, some recommendation on nearby places to stay, even if only for the night. I was quite anxious because I wasn’t able to arrange for accommodation prior to this trip (short notice, remember?), so I decided to go directly to the venue to be the best way of trying my luck. And try my luck it was! First, I was greeted by a front desk manager who turned out to be a fellow Filipino, and he helped me get a room in the hotel. At the time though, he could not guarantee that I can stay there for the duration of the trip (only for the night) but he would help me to find alternate accommodation instead on the next day. I thought that was good enough, since it was already midnight by the time I reached the hotel, and just a bed to sleep on for the night would do great for me to worry about moving elsewhere later. And the next day: Day 1 of OSDC: I was up rather too early that day; the worrying about moving elsewhere settled in too early as well, and had made me check out very early so I can hopefully look for that alternate accommodation by lunchtime. One by one, the attendees came, and soon enough more than a couple of hundred people were filling the main conference room, waiting for OSDC to begin. And we began with a keynote from Rusty Russell on C, the humbling language and Ian Clatworthy’s talk on distributed version control systems. After the keynote, I was notified by the hotel management that instead of moving elsewhere, I can just remain there for the duration of the conference. I was quite relieved! For the remainder of the day, I listened in on the Perl stream of talks from Kirrily Robert, Josh Heumann, and Jacinta Richardson, on packaging Perl modules, Perl 6, and Perl code optimizations, respectively. Kirrily’s talk was timely since I am writing a couple of Perl modules to be released on the CPAN (one, Tie::Amazon::S3, is now up On the morning Day 2, I listened in on Mark Rees’ talk on testing web applications using twill and a scripting language, like Python. I then followed Adam Kennedy’s talk on the CPAN 1.5, learning about CPAN::Mini, the CPANPLUS (which IIRC will be standard in Perl 5.10) and the Tiny modules in the process. More on the Perl stream continued with another talk from Josh Heumann on intermediate Perl testing, providing a humorous yet informative strategies not really just for testing Perl scripts or modules but for software testing in general: Later in the afternoon was Paul King’s talk on agile developer practices for dynamic languages, covering Groovy and Ruby. That was later followed by Leslie Hawthorn’s talk about the Google Summer of Code and the announcement of the Highly Open Participation contest for the young geeks who are not yet in college or university but would like to work on open source projects just like the SoC-ers. After the day’s schedule of talks, there was a break before the conference dinner, allowing also for a short keysigning session and CACert identity check. Then, we had the conference dinner, sponsored by Google. There was also a game held: every table makes up a team who, given some Play-dohs and imagination, are to make up a bug’; the best bug’ wins a free book. Unfortunately, my table/team didn’t win any books, but that was beside the point anyway, as the bugs that were made up were quite something: On the last day, the morning talks I attended were all about Ruby and Rails. Nic Williams gave an introductory talk on Rails, then Paul King gave another talk, this time on Grails (the Java version of Rails,) and closing the morning session was Keith Pitty’s talk on Ruby for Java shops. For the afternoon, I followed Adam Kennedy’s talk on optimizing projects for wetware. For the closing keynote, Nat Torkington talked about the future of software: And with a day left before returning home, I went to sightseeing mode, bought a couple of books, and the mandatory pasalubong for the relatives. At midnight, my flight took me back to Bangkok, another long trip that touched down at the crack of dawn: After a few hours’ wait, I took the plane back to Manila, returning home just after lunchtime. This being my first international trip, making it alone seemed to be quite an adventure. But I wasn’t really alone in this endeavor: kudos goes to the UNDP International Open Source Network for their exchange grant program, to my relatives for their support, to Free and Open Source Software for really making things rock (and free ;), and to $DEITY for being there. Until the next trip!

It's an end of year tradition for non-profit organizations to do big fund-raising and membership pushes. As I mentioned several days ago, I am personally giving to two organizations this year: the Wikimedia Foundation and the Free Software Foundation. The FSF has a goal of 500 associate members by year-end and it's an important goal that will sustain the foundation's activities. While membership dues keep the lights on, the fact that the foundation has a robust and growing membership is equally, if not more, important. FSF executive director Peter Brown put an appeal online in both video and text versions. In it, he lays out some of the most important issues for the next year. You should watch the video version in OGG Theora or this YouTube version (requires Gnash or non-free Flash). The appeal briefly lays out the FSF's plans for next year. My partner Mika Matsuzaki and my friend Oliver Day shot and edited the video. Please pass the link around to those you feel might be interested. Here's my appeal:

Now is the time to join and give to Free Software Foundation. 2008 is going to be extraordinarily important year for free software. Eben Moglen likes to quote Gandhi's "first they ignore you, then they laugh at you, then they fight you, then you win" progression when describing the free software movement. As I pointed out when I joined the FSF board, we're beginning to see powerful interests fighting free software. It's going to increase in the next few years. Things will probably get a lot uglier for free software before they get better. We can win but things are far from settled. The FSF is the front-line organization in this fight and we need a robust and proactive foundation, and an active and involved membership, if we're going to win. Here are the issues that I'm going to pushing the FSF to pursue in the next year. Expanding activism outside our traditional technologist communities: In part through the work of projects like Defective By Design, we've seen the tide turn for DRM on music in what what may be the FSF's greatest success last year. I'm going to push the FSF to continue the campaign to attack DRM for video, eBooks, and the other places it is cropping up. The most remarkable thing to me about Defective By Design is that its participants and supporters are not, for the most part, people who develop or use GNU/Linux or even know what GNU is! If advocacy for software freedom involves a conversation we can only have with people who understand what POSIX is and how one uses it, we've already lost. Through DbD, BadVista, and other projects, the FSF has made major strides in the last year. It need to do much more and needs your support to do so. Get proactive about software patents: As a community, we've had our head in the sand about software patents for far too long. There are companies and patent trolls sitting on massive, growing piles of software patents. They are not our friends and they do not mean us well. One cannot write non-trivial software today without running a serious risk of infringing patents. The software patents minefield we've found ourselves in is a very fundamental threat to the success of free software and we've already begun to see the first casualties and costs. We must eliminate software patents. Now. The US is very important in this fight (much patent law is "exported" from the US) and almost no organization is working on software patent elimination there. Not enough people are thinking and acting strategically on this issue. The FSF is planning to make major steps in this fight in the coming year and we need your support to do so. Web services and the changing face of software: This last year, I worked to help launch the new version the AGPLv3. The license addresses the role of copyleft for software like web-services which, due to the legal particulars of the GPL, did not extend to the purveyors of web services. Of course, access to source code does not make the users of all web-services free (e.g., the GMails and the Facebooks). Nobody seems to know what freedom for webserver entails. There might not even be good answers. In the next year, I'm going to push the FSF to help start several conversation and to begin to follow up on what I think was an important first step with the AGPLv3. While this is not a major organizational priority yet, it's a major action item that I will be pursuing through the FSF. If you feel strongly about this issue, whatever your position, become a member, stay involved as these projects develop, and have your voice be heard. We don't know the answers yet and we need your input as much as we need your action.

Please, support the FSF in the efforts listed above, and in others, by giving generously. If you're not a member, please join the FSF as an associate member. If you are already a member, please consider making a tax-deductible donation. The FSF is a very lean, very humble organization of passionate and dedicated individuals working tirelessly for software freedom. Every little bit helps. Members pays USD $120 ($10/month) and student members pay half that. FSF has members across the world -- where a weak dollar often makes it even cheaper. Member support and participation builds capacity and credibility for the foundation and keep the organization responsible, responsive, and in tune with our community.

A common feature in blog software is a Blogroll, this is a list of links to blogs which are associated in some way with the blog in question - most commonly it’s a list of blogs run by friends of the blogger in question. Now in the case of friends with very similar interests (IE same religious and political beliefs, sexual preferences, hobbies, etc) this wouldn’t cause a problem. In the case of commercial blogs it also will work well (EG Google runs a large number of blogs which contain links to all the rest - they may not interest all readers but should be expected not to offend any). In the case of personal blogs where people don’t always have the same interests there is scope for problems. A link to the main page of a blog is an unconditional recommendation for the blog. There are not many of my friends who I share that much in common with that I would be prepared to give such a recommendation for a frank personal blog, and for those few I am unwilling to do so as it generates social pressure to include others. Some of my friends who didn’t get listed in my blogroll would probably get offended, even though it’s only the occasional post that I strongly disagree with which would make me refrain from such a listing. I appreciate it when people add me to their blogroll, but don’t have any expectation that the listing will remain (I’m not going to get offended if someone changes their criteria for listing and removes my entry). But I consider it an equal compliment when someone cites one of my blog posts as a reference and recommends that other people read it. Citing an individual post has the advantage (for the person citing the post) they are specifically not recommending my entire blog. For example if you recommend one of my posts about Linux and one of your readers goes further into my site and is offended by my posts about politics then it’s not your issue. Tim Berners-Lee made an interesting point [1] “so readers, when they find something distasteful or unreliable, don’t just hit the back button once, they hit it twice“. I know that some people who would be interested in the technical Linux issues I write about don’t read my blog because they are offended by my political beliefs, I am not concerned about this - but I don’t expect that everyone who chooses to link to me will necessarily want to make the same trade-off. When citing individual posts it’s possible to strongly agree with one post and strongly disagree with another by the same author. Probably the best way of acknowledging your friends via blogging (if you choose to do so) would be to make an occasional links post which contains short positive recommendations to the best posts your friends wrote. If every month or two someone writes a links post (post which has little content, merely recommendations for other posts) which references your posts then you know that they like you (and you get a Technorati.com boost), so a blogroll entry hardly seems necessary. An additional benefit for giving such direct credit is that the person receiving the links will know what you consider to be their best work which will help them in their future writing. I believe that adding this feature to common blogging software was a mistake. The small number of people who actually need this (such as Google) can create it via a HTML widget (IE writing raw HTML for the page - it’s really easy to do) and the rest of the population would be better off without it.

• [1] http://dig.csail.mit.edu/breadcrumbs/node/170

Share This

DeBaBaReTools seems to work good enough that writing an early-stage HOW TO seems to worth the time :)

---

The first thing to do is of course fetch the sources:

$ svn export https://neo.yahostme.com/svn/DeBaBaReTools/trunk/ DeBaBaReTools

Build and install the package:

$ cd DeBaBaReTools; dpkg-buildpackage -b; dpkg -i ../debabaretools_0.2_all.deb

$ dpkg -L debabaretools
/.
/etc
/etc/DeBaBaReTools
/etc/DeBaBaReTools/common.conf
/usr
/usr/bin
/usr/bin/wannaBuild
/usr/bin/needsBuild
/usr/bin/needsReBuild
/usr/bin/buildQueue
/usr/bin/checkSums
/usr/bin/wannaUpload
/usr/bin/processIncoming
/usr/share
/usr/share/doc
/usr/share/doc/debabaretools
/usr/share/doc/debabaretools/copyright
/usr/share/doc/debabaretools/ENV
/usr/share/doc/debabaretools/changelog.gz
/usr/share/doc/debabaretools/TODO
/usr/share/DeBaBaReTools
/usr/share/DeBaBaReTools/backends
/usr/share/DeBaBaReTools/backends/config
/usr/share/DeBaBaReTools/backends/config/reprepro.sh
/usr/share/DeBaBaReTools/backends/probe.sh
/usr/share/DeBaBaReTools/backends/fetch
/usr/share/DeBaBaReTools/backends/fetch/dget.sh
/usr/share/DeBaBaReTools/backends/verbosity.sh
/usr/share/DeBaBaReTools/backends/lock
/usr/share/DeBaBaReTools/backends/lock/default.sh
/usr/share/DeBaBaReTools/backends/setDefault.sh
/usr/share/DeBaBaReTools/backends/buildQueue
/usr/share/DeBaBaReTools/backends/buildQueue/plaintext.sh
/usr/share/DeBaBaReTools/backends/signature
/usr/share/DeBaBaReTools/backends/signature/gpgv.sh
/usr/share/DeBaBaReTools/backends/check
/usr/share/DeBaBaReTools/backends/check/default.sh
/usr/share/DeBaBaReTools/backends/build
/usr/share/DeBaBaReTools/backends/build/pbuilder.sh
/usr/share/DeBaBaReTools/backends/upload
/usr/share/DeBaBaReTools/backends/upload/dput.sh
/usr/share/DeBaBaReTools/backends/parsers
/usr/share/DeBaBaReTools/backends/parsers/default.sh
/usr/share/DeBaBaReTools/backends/repository
/usr/share/DeBaBaReTools/backends/repository/shared.sh
/usr/share/DeBaBaReTools/backends/repository/reprepro.sh
/usr/share/DeBaBaReTools/backends/misc.sh
/usr/share/DeBaBaReTools/backends/codenamesTable
/usr/share/DeBaBaReTools/backends/codenamesTable/release.sh
/usr/share/DeBaBaReTools/backends/codenamesTable/reprepro.sh
/usr/share/DeBaBaReTools/backends/config/default.sh
/usr/share/DeBaBaReTools/backends/fetch/default.sh
/usr/share/DeBaBaReTools/backends/buildQueue/default.sh
/usr/share/DeBaBaReTools/backends/signature/default.sh
/usr/share/DeBaBaReTools/backends/build/default.sh
/usr/share/DeBaBaReTools/backends/upload/default.sh
/usr/share/DeBaBaReTools/backends/repository/default.sh
/usr/share/DeBaBaReTools/backends/codenamesTable/default.sh

Now you have to create a base reprepro repository. I strongly recommend setting the REPREPRO_BASE_DIR ENV variable if possible.

A recommended repository structure is (in repoitory/):

.:
./build:
./build/cache:
./build/data:
./build/data/logs:
./build/tmp:
./conf:
distributions
incoming
options
tiffany.py
uploaders
./db:
./debian:
./debian/dists:
etch
oldstable
sarge
sid
stable
testing
unstable
./debian/dists/...
./debian/pool/...
./incoming:
./incoming/accepted:
./incoming/new:
./incoming/rejected:
./pub:
./pub/UploadQueue:

Note that the build/, incoming/ and pub/ directory structures are DeBaBaReTools' defaults, if you want to change them you will have to set some variables at the configuration file ($HOME/.DeBaBaReToolsrc).

The distributions file must at least contain the Codename, Suite and Architectures entries for DeBaBaReTools to work correctly. Note that the current code used to correlate the suites with the codenames greps for the given codename/suite including two lines before and two after the match, so the entry must be on that scope.
E.g.

$ cat conf/distributions
Codename: sid
Suite: unstable
Architectures: i386 amd64 source
Components: main contrib non-free
Uploaders: uploaders
DebIndices: Packages Release .bz2 .gz .
DscIndices: Sources Release . .gz .bz2
Contents: .bz2 .gz .
Tracking: minimal includechanges keepsources

conf/incoming must name at least one rule. This is because when installing, DeBaBaReTools will grep for all the rule names and execute them one by one.
The rest of reprepro's setup is trivial.

When building packages with pbuilder, DeBaBaReTools expects the basetgz's to be named like $PBUILDER_CACHE/$CODENAME.tgz where $PBUILDER_CACHE is an environment variable defaulting to /var/cache/pbuilder.

Tweaking DeBaBaReTools:
Because we are using reprepro and pbuilder we'll give some hints to DeBaBaReTools so it uses a reprepro-specific and/or pbuilder-specific backend where possible.

$ echo 'HINT_ALL="reprepro pbuilder"' > $HOME/.DeBaBaReToolsrc

The .DeBaBaReToolsrc file is sourced by all scripts, so you might even set variables like $REPREPRO_BASE_DIR there.

/usr/share/doc/debabaretools/ENV documents only some of the multiple environment variables that can be specified to customise DeBaBaReTools' behaviour. It is important to say that variables which are empty will be filled with a default value.

You may now want to modify .dput.cf by adding a 'local' target for your repository:

[local]
fqdn = localhost
method = local
incoming = /home/raphael/Deb/repository/pub/UploadQueue
allow_unsigned_uploads = 0
run_dinstall = 0

So let the fun begin! :)

To make sure everything is ok let's run processIncoming in verbose mode:

VERBOSE=1 processIncoming
processIncoming v0.1 started.
processIncoming v0.1 stopped.

Not getting that output means something is not ok.

All the scripts will try to source a file called $HOME/.$ APP_NAME rc, where $APP_NAME is the name of the script, e.g. processIncoming. This can be used to customise them even more.

Tweaking the scripts behaviour:

processIncoming offer some options such as:

• NEW_POLICY, default: binary. Meaning: uploads introducing new binaries will be moved to $NEW
  
• REJECTED_POLICY: move(default)/kill: action taken on non-reclaimed (by a .changes file) files
  
• CHECK_SIGNATURE: 1(default)/0, whether to check signatures on the .changes file or not
  
• INSTALL: 1/0(default), whether to run the repository's install rules, this will usually be set at run-time (e.g. daily cronjob)
  
• KEYRING: default: uploaders.gpg, the keyring with keys allowed to upload
  

wannaBuild:

• BUILD_LOGS_DIR: $BUILD_DATA/logs, directory where build logs are stored
  
• SIGN: see the ENV file for details
  
• SIGN_COMMAND: see the ENV file for details
  
• DEB_HOST_ARCH: see the ENV file for details
  
• BUILD_DATA_CACHE: $BUILD_DIR/cache, directory where tools such as dget may store data
  
• KEYRING: secring.gpg (needs to be changed), keyring file containing the keys to accept
  
• UPDATE_ENVIRONMENT: see the ENV file for details
  
• GAINROOT: see the ENV file for details
  
• DISTROS_TO_BUILD: $SUPPORTED_DISTROS (based on the repository's backend information), list of distributions (e.g. unstable) wannaBuild is going to build for.
  

When you should call which DeBaBaReTools script:
processIncoming takes care of accepting package uploads and installing them when told to do so.
needsBuild processes the .changes files accepted by processIncoming and tells the build queue manager that a given package needs to be built, or when the binary package is also uploaded, or is already built.
wannaBuild only takes care of building source packages (note that arch: all-onnly packages WON'T be built, they must be uploaded together with the source package).

So the workflow is:
processIncoming -> needsBuild -> INSTALL=1 processIncoming

A package won't be installed in the repository if it isn't handled before by needsBuild.

Here's a demonstration (note the usage of VERBOSE=1):

$ dput local kcometen3_1.1-1_source.changes
Checking Signature on .changes
...
Uploading to local (via local to localhost):
Successfully uploaded packages.
Not running dinstall.
sh: /usr/bin/mini-dinstall: No such file or directory
Error while executing command.
Continuing...

The package is now at pub/UploadQueue

$ VERBOSE=1 processIncoming
processIncoming v0.1 started.
Processing /home/raphael/Deb/repository/pub/UploadQueue/kcometen3_1.1-1_source.changes...
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcometen3_1.1-1.diff.gz" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcometen3_1.1-1.dsc" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcometen3_1.1-1_source.changes" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcometen3_1.1.orig.tar.gz" to "/home/raphael/Deb/repository/incoming/accepted/"
processIncoming v0.1 stopped.

After checking sums and signature, the upload is accepted.

$ VERBOSE=1 needsBuild
needsBuild v0.2 started.
Architectures: i386 amd64 all
Now processing /home/raphael/Deb/repository/incoming/accepted/kcometen3_1.1-1_source.changes
Adding kcometen3 to be built in i386 for the sid distribution
Adding kcometen3 to be built in amd64 for the sid distribution
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcometen3_1.1-1.dsc" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcometen3_1.1.orig.tar.gz" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcometen3_1.1-1.diff.gz" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcometen3_1.1-1_source.changes" to "/home/raphael/Deb/repository/incoming"
needsBuild v0.2 stopped.

The package is now marked to be built on i386 and amd64 for sid (note that distro to codename conversion is performed) and moved to incoming/ so processIncoming is able to install it.

$ VERBOSE=1 processIncoming
processIncoming v0.1 started.
processIncoming v0.1 stopped.

There's nothing under pub/UploadQueue and nothing is installed (do you remember the INSTALL=0 option? :))

$ INSTALL=1 VERBOSE=1 processIncoming
processIncoming v0.1 started.
No distribution found for 'kcometen3_1.1-1_source.changes'!
There have been errors!
No distribution found for 'kcometen3_1.1-1_source.changes'!
There have been errors!
No distribution found for 'kcometen3_1.1-1_source.changes'!
There have been errors!
making diffs between /home/raphael/Deb/repository/debian/dists/sid/main/source/Sources and /home/raphael/Deb/repository/debian/dists/sid/main/source/Sources.new:
generating diff
Exporting indices...
processIncoming v0.1 stopped.

The errors can be safely ignored, it is just that reprepro couldn't install kcometen3_1.1-1_source.changes for the specified install rule (I've one for each distro, that's why).

$ VERBOSE=1 wannaBuild
wannaBuild v0.1 started.
Fetching list of packages to be built for unstable
Fetching source package kcometen3 v1.1-1
Use of uninitialized value in string eq at /usr/bin/dget line 377.
cat: /home/raphael/Deb/repository/build/data/needsBuild.unstable: No such file or directory
Starting build backend...
Executing sudo pbuilder --update --basetgz /var/cache/pbuilder/unstable.tgz
Starting build process
Verifying signature of /home/raphael/Deb/repository/build/kcometen3jb3362/kcometen3_1.1-1_i386.changes...
gpgv: no valid OpenPGP data found.
gpgv: the signature could not be verified.
Please remember that the signature file (.sig or .asc)
should be the first file given on the command line.
Fetching list of packages to be built for testing
Fetching list of packages to be built for stable
Fetching list of packages to be built for oldstable
wannaBuild v0.1 stopped.

There are still some things that need to be fixed (e.g. the no such file or directory message).
Other than that, the output is just fine: the package wasn't automatically signed so when trying to check the signature it failed to find it thereby not uploading the package automatically.

Now we cd to build/kcometen3jb3362/, review the build log, the .changes file, and we finally sign it.
Afterwards, we upload the package and install it:

$ VERBOSE=1 processIncoming
processIncoming v0.1 started.
Processing /home/raphael/Deb/repository/pub/UploadQueue/kcometen3_1.1-1_i386.changes...
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcometen3_1.1-1_i386.changes" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcometen3_1.1-1_i386.deb" to "/home/raphael/Deb/repository/incoming/accepted/"
processIncoming v0.1 stopped.

$ VERBOSE=1 needsBuild
needsBuild v0.2 started.
Architectures: i386 amd64 all
Now processing /home/raphael/Deb/repository/incoming/accepted/kcometen3_1.1-1_i386.changes
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcometen3_1.1-1_i386.deb" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcometen3_1.1-1_i386.changes" to "/home/raphael/Deb/repository/incoming"
needsBuild v0.2 stopped.

$ INSTALL=1 VERBOSE=1 processIncoming
processIncoming v0.1 started.
No distribution found for 'kcometen3_1.1-1_i386.changes'!
There have been errors!
No distribution found for 'kcometen3_1.1-1_i386.changes'!
There have been errors!
No distribution found for 'kcometen3_1.1-1_i386.changes'!
There have been errors!
making diffs between /home/raphael/Deb/repository/debian/dists/sid/main/binary-i386/Packages and /home/raphael/Deb/repository/debian/dists/sid/main/binary-i386/Packages.new:
generating diff
Exporting indices...
processIncoming v0.1 stopped.

done :)

We can now setup some cronjobs:
*/10 * * * * processIncoming
*/5 * * * * needsBuild
@daily INSTALL=1 processIncoming

needsReBuild and uploadQueue still need to be written, so don't expect them to do anything right now.

I hope people start using it so I receive more feedback :D

After a lot of hacking I've now got chronicle displaying comments upon entries. Since my blog is compiled on my home desktop machine and comment submission happens upon a remote machine the process involves a bit of a hack:

Publish Blog

The blog is compiled and uploaded to the live location using rsync.

Wait For Comments

Once the blog is live there are embedded forms which may be used to receive comments. The CGI script which is the target of the forms will then write each comment out to a text file, located outside the HTTP-root.

Sync Them

Prior to rebuilding the blog the next time I update I rsync the comments directory to my local machine - such that the comments posted are included in the output

This my local tree looks something like this:

~/blog/
 -- comments/
 -- data/
 -- output/
 -- Makefile
 -- chroniclerc

Here I have a Makefile to automate the import of the comments from the live site to the local comments/ directory, rebuild, and finally upload. All this means that I can rebuild a blog created by a combination of plain text post files and plain text comment files. It also means that there is a fair lag between comment submission and publication - though I guess there is nothing stopping me from auto-rebuilding and syncing every hour or two via cron... I'll make a new release with this comment.cgi script and changes once the package hits Debian unstable...

I'm not into tattoos, but this is an interesting concept. Note: this is a "design probe". The movie isn't real, it's an idea that may or may not eventually be made possible. But it sure is interesting. (via) (afterthought: Actually I am into tattoos, just not on my own body :-)

Microsoft has an article on their website in which they compare Windows to "Linux". As can be expected, the comparison is rather one-sided, and in some cases flat-out wrong. Usually I ignore this type of things, but this time I decided to just point out why it's so wrong, and put it online. Comments are welcome.