I love 2.0: Raquel has released a small interesting personal project as a tumblelog. Spanish spoken, I love 2.0 (although I prefer calling it I 2.0 ) features some interesting small chunks of information and news on Web 2.0 and related topics. Way to go!

Update (3/3/2008): We’re also working to bring Google Gears for mobile to Android and other mobile platforms with capable web browsers. Here is my writeup of yesterdays Android Code Day in London. Eclipse 3.3 is needed to get the plugin working. Only eclipse 3.2 is in Debian unstable. Download the Europa release and re-setting up the plugin will do it. I’m no Eclipse fan boy, though the integrated debugger works. The iteration cycles are really short for trying stuff out. Very good. Developers, mainly from a Symbian background grilled Jason Chen over security and wanting C API access. Lot of people didn’t seem to like the idea that users were controlling security. I like Google’s “empowering the users” stance, though I think representatives from operators don’t. I heard that poor argument about users asking their operators for android support. Jason argued well that it’s up to user education to contact the right people. When a computer crashes in the UK, who do people call? VirginMedia? Please! :) How about Breakpad crash reporting on Android?. Jason used the OHA to defend Google from looking like they have all the political power… Hmmmm. :) I can understand the tight rope that Google are walking. They are trying not to fragment their platform before it’s properly released. OEMs, operators will feck it up if they have the chance to play with the source code before a Google co-ordinated release. Once they release Google claim they will release everything under the Apache 2 license. So I asked could we see Android on desktops? Jason said there is nothing stopping you. I hope not. Their opened fonts and multimedia codecs on desktop PCs could really make a big difference for Linux take up, especially in Asian (growth) markets. I have studied and implemented Asian fonts and Android’s font rendering even on that nightmare Website sina looked good to me. Despite the “Symbian developers” giving Jason hell in the beginning I had impression they actually liked Android. It fealt almost staged. Scary. Symbian C++ programmers learning Java and jumping ship! Same old problems with images. People are concerned about how bitmap images will scale on different target screens. There is four ‘skins’ already supported in the emulator (QVGA-L+P, HVGA-L+P). We need scalable images too on the Web. ;) Though there are some workarounds demonstrated which seemed OK to me. During the hackathon, I wanted to write a backup/sync tool. Since only Jason Chen seemed to know Android and there was a filled audience, I didn’t get to ask him how really to go about coding it. Though with the help of Dave from Zyb, we eventually found out about content providers. Took some debugging to find that out, but we got there. Having a working debugger is really really nice. We discovered we needed “android.permission.READ_CONTACTS” in the manifest to make our little application that read out the contact on stdout. Cool, though I’d rather use Javascript and the Web stack. Anyway, Android seemed like a good platform, but I have concerns. My biggest concern is basically where is Google Gears on Android? Jason could neither confirm or deny this, so perhaps they have it. Though gears is an opensource project and you can see code reviews… no Android mentioned. What happens if the Android platform is wildly successful? Then we are going to see two major platforms. The Android platform on mobiles and the Web platform on everything else. I worryingly saw no support for Web application device APIs on Android. Encouraging people to write for their Android/java-esque platform undermines their main Web platform! It’s like Microsoft’s mistake of undermining their own platform all over again. From Android you can use Webkit and the Web stack. But from the Web API stack you can’t seemingly access their Dalvik VM APIs. I disclose I am an employee of Aplix (opinions etc. are my own), also a OHA member. I am actively working on a plugin technology that exposes APIs as familiar JS APIs to Web developers. I have already done a proof of concept implementation of Google Gear’s Location API on mobile devices with Aplix technologies. Google you should really do the same and make Web applications equal citizens on your mobile platform by implementing Gears on Android (if you haven’t already).

As you know I implemented the support of symbols files in dpkg-shlibdeps/dpkg-gensymbols, and I would be very pleased if libc6 could start using it as most packages would then benefit from weaker dependencies on libc6 and be more easily installable on previous versions of the distribution (sid package directly installable on etch in some cases). Some time ago I tried to get the ball rolling by providing a first patch in #462444. Unfortunately the glibc team has not been able to finish the work up to now and the base freeze is approaching… so it would be great if some people could jump in, make the required changes, test and propose a new (fully working) patch. I just sent a message to give some indications on how to get forward, hopefully that will help anyone who wants to tackle this. Thank you for your help! Partagez cet article / Share This

I had a call last week from one of our customers that a self-managed server had been attacked and email wasn't running smoothly on it any more. The exploited web app (old version of mambo IIRC) had been repaired and there didn't appear to be a shell-gaining exploit, so what was wrong? Looking at the mail queue gave a clue. I couldn't see anything at first. Nothing. No output. Eventually, qmail-qstat returned and reported over 50,000 emails in the queue, which is pretty high for that webserver. Poking around the mailserver found lots of examples of a few types of spam. I stopped outgoing mail so I could clean up. I don't use qmail much. It hasn't been free software for long and the default upstream packaging (which was being used on that server) isn't very friendly IMO. So, I had no idea how to remove messages from a qmail queue, like exim -Mrm or postsuper -d. I looked at the qmail man pages and the qmail binaries. Nothing. I looked at the qmail FAQ. Nothing. I asked a LUG IRC channel. Something, but no answer. With some web searches, I found mailRemove.py - why is this not in qmail and not even a FAQ? No clear contact details on the FAQ, either.

The topic of switching from CVS to something else regularly came forward but nobody did anything. The net result is that several documentation are now maintained outside of the debian-doc repository because their respective maintainers didn’t want to stay with CVS. After noticing that the developers-reference also switched to SVN, I decided to convert the whole debian-doc CVS repository and import it in the new “ddp” SVN repository on Alioth. This is now done. Hopefully, the Debian Documentation Project can now again become the central place for writing good documentation about Debian. New contributors can be easily added through the DDP Alioth project. Volunteers are welcome to review what’s in the SVN and move obsolete documentation aside. People who moved away are welcome back. Another project that also suffers from its CVS usage is the website (and it desperately needs a better design). After yet another round of discussion on #debian-devel, we agreed that discussing endlessly was not an option and that someone had to try the conversion and prepare the scripts for SVN usage. So I proposed to handle the CVS to SVN conversion and ifvoid decided to try to update the scripts. And it looks like things are progressing quite well… we included the CVS revision -> SVN revision mapping in the conversion (option –cvs-revnums of cvs2svn) and this will enable us to script the update of all translations (they encode a CVS revision to know if they are out-of-date or not). Expect to hear from us soon on debian-www@lists.debian.org… Partagez cet article / Share This

Yes, it’s DPL election time again. On the good side, we’ll spend less time this year than we used to thanks the constitution change. On the bad side, it seems that almost nobody is interested to run for DPL (even HE is not sure yet!). I’ve been relatively satisfied by the work done by sam (although one can always do better) and it looks like many share this feeling… and when this is the case, we just expect the DPL to run again. But sam clearly said that he won’t run again. What a pity. I also don’t plan to run this year[1] but I’m always interested in leadership issues and I’d gladly be part of a DPL team. Hopefully someone will provide such an alternative on the ballot this year. Right now, I’m more in the mood of implementing some real changes (like the symbol based dependencies that I added to dpkg-shlibdeps) instead of trying to convince others to do them. When you associate this to some support of the leadership in place, it can give very good results. Now back to real work, I still have to test and polish the dpkg-source rewrite which adds support of several brand new source package formats. Feel free to check out our progress in the sourcev3 git branch. [1] Feel free to convince me otherwise by adding some comments here. Partagez cet article / Share This

The good: pulling up to the Marriott and having them handle our bags and valet the car after a nice evening out with friends.

The bad: Discovering the sheets of one of the beds were dirty.

Worse: we asked for new sheets, they handed us a stack and ran off.

Teh funny: just as we finally got housekeeping up and they apologise, etc. Leif threw up all over the other bed. Hard to stay upset at that point.

surgery updates will be on Angie's lj, auzure_skies

• Comic for 02 Mar 2008
  I KNEW it!
• Coming Soon from VW: A 69.9 MPG Diesel Hybrid
• Real-world Performance Tuning with Callgrind
  Neat, but good old gprof would have caught that kind of thing too.
• Optical Illusion
  It works.

Seems as if the Chemnitz Linux Days somehow turned out to be the only Linux event I still attend regularly. These days I miss out on most of them, simply because of a total lack of spare time, however, I somehow always make the CLT ... no matter how big the hassle may be! They're just worth it :) My talk went well, even though I actually got a bit pressed on time this year and had to cut the Q&A part. The (German) slides for my talk are as usually on my talks page.

So, sometime over the past few weeks I clocked up ten years as a Debian developer:

From: Anthony Towns <aj@humbug.org.au>
Subject: Wannabe maintainer.
Date: Sun, 8 Feb 1998 18:35:28 +1000 (EST)
To: new-maintainer@debian.org
Hello world,
I'd like to become a debian maintainer.
I'd like an account on master, and for it to be subscribed to the
debian-private list.
My preferred login on master would have been aj, but as that's taken
ajt or atowns would be great.
I've run a debian system at home for half a year, and a system at work
for about two months. I've run Linux for two and a half years at home,
two years at work. I've been active in my local linux users' group for
just over a year. I've written a few programs, and am part way through
packaging the distributed.net personal proxy for Debian (pending
approval for non-free distribution from distributed.net).
I've read the Debian Social Contract.
My PGP public key is attached, and also available as
<http://azure.humbug.org.au/~aj/aj_key.asc>.
If there's anything more you need to know, please email me.
Thanks in advance.
Cheers,
aj
-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
On Netscape GPLing their browser:  How can you trust a browser that
ANYONE can hack? For the secure choice, choose Microsoft.''
        -- <oryx@pobox.com> in a comment on slashdot.org

Apparently that also means I’ve clocked up ten and a half years as a Debian user; I think my previous two years of Linux (mid-95 to mid-97) were split between Slackware and Red Hat, though I couldn’t say for sure at this point. There’s already been a few other grand ten-year reviews, such as Joey Hess’s twenty-part serial, or LWN’s week-by-week review, or ONLamp’s interview with Bruce Perens, Eric Raymond and Michael Tiemann on ten years of “open source”. I don’t think I’m going to try matching that sort of depth though, so here are some of my highlights (after the break).

---

• Starting small: my first package was distributed-net-pproxy, which would claim a bunch of work units which could then be distributed over the local LAN. Useful if you’re in Australia in the mid-90s and being charged by the minute for Internet access. distributed.net didn’t allow general distribution, so I asked for (and received) explicit permission to include it in Debian. (distributed.net had a ten year anniversary last year too)
• Diving straight in: I got sucked in to the mailing lists pretty quickly, and within a couple of months was up to my neck trying to redesign the way we did releases; oddly enough that didn’t turn out quite so easy, but at least it ended up with some concrete proposals within a couple of months, pretty much synchronously with the hamm (2.0) release going out (and, I guess, about a year after I’d started using Debian…). At around the same time was, I think, my first recorded comment about trade offs regarding freeness…
• cruft: My first bit of Debian specific code was cruft (that its name, not it’s value…), which worked okay as a prototype, but got snagged up in debian-policy trying to get packages to make a note of files they’ll put on the system without telling dpkg (eg, /etc/passwd, /var/cache/apt/archives/*.deb, etc). That pretty much sapped my interest in it, and cruft stagnated until Marcin Owsiany picked it up in 2005.
• Played for a sucker, part one: a few months later I was messing around doing QA stuff and fixing bugs and as part of that did an NMU of netbase (which at the time directly contained all sorts of important tools like ping and inetd directly). That went something like:

  From: Anthony Towns
  Date: Sat, Nov 21, 1998
  There are a few bugs accumulating against the netbase package which
  you're maintaining. I was wondering if you'd mind if I made an NMU
  to fix some of them for the upcoming slink release?
  

  From: Peter Tobias
  Date: Sat, Nov 21, 1998
  No, please go ahead ... I'm quite busy right now and I would really
  appreciate any help. Please let me know if you need additional information
  about the package.
  

  From: Anthony Towns
  Date: Sun, Dec 6, 1998
  There's an NMU sitting in Incoming now. It fixes a few bugs, viz:
  [...]
  

  From: Peter Tobias
  Date: Fri, Dec 25, 1998
  due to my current job I don't have much time to work on my debian
  packages. In order to have more time for my other debian packages
  I would like to give away the netbase package. Are you interested
  in maintaining this package?
  

  From: Anthony Towns
  Date: Fri, Dec 25, 1998
  Ummm. Sure. I guess. (or, iow, *Eeeeeeeeeeeeek*!!!)
  
  

• ifupdown: As part of maintaining netbase I tried to figure out a way of fixing bugs like 31745 and 39118. Basically, Debian used to do networking by generating a script on install that you could modify by hand, and that was it – so when the commands needed changed between 2.0 and 2.2 (no more “route add -net”), you couldn’t make that upgrade “just work”. Red Hat handled it with “ifup” and “ifdown” commands that would look at a whole bunch of shell-format variables in /etc, which worked but wasn’t elegant, so I came up with something I thought was actually pleasant. It’s fundamental attitude is to be a parser – the networking commands are specifed as compile-time configuration, the description of your network is your runtime configuration, and ifupdown just puts those all together without trying to actually understand what’s going on. To some degree, that works really well – it keeps all the knowledge separate so when you’re writing an /etc/network/interfaces, you’re not worried about how DHCP works; in others it breaks down – in particular if bringing up an interface fails part way through, is it up, or down, or something else entirely?
• bugs.debian.org: I’m not entirely sure why, but in August ‘99 I decided to start running a script to stop old bugs from being permanently deleted:

  From: Anthony Towns
  Subject: BTS and old bugs
  Date: Tue, 24 Aug 1999 22:33:16 +1000
  To: debian-private@lists.debian.org
  ObPrivate: Erm. I'm not sure. It is only even vaguely relevant to
  developers.
  Since bugs #9705 and #36727 don't seem like being fixed any time soon
  and Darren hasn't managed to convert the BTS to using debbugs.deb yet,
  I've made a little script to stop us from continuing to lose bug
  reports, and am running it in my crontab on master.
  ~ajt/debian-bugs/archive/ contains hardlinked copies of the bugs in
  ~iwj/debian-bugs/spool/db (except split into sub-directories). When
  the bugs get expired from the BTS, the hardlink in ~ajt remains, so
  the file doesn't get lost forever.
  In the week or so I've been running it, some 500 odd bugs expired [0].
  

  Next month I sent Darren Benham a first version of bugreport.cgi, and at some point around then must’ve sent off a pkreport.cgi too; by the month after (October) I’d evidently been added to the debbugs group, because I was merging my archived bugs into the official debbugs directories.
• testing: So a year and a bit later and there had been some more discussions about making major changes to our release process, and since I’d done some more algorithms subjects at university by this point, dove in a bit more seriously. For me, the main challenge seemed to be keeping dependencies consistent, and it turns out validating dependencies and conflicts is an NP-complete problem, and solving that reasonably efficiently seemed like a good first step. By October ‘99 I’d come up with a first pass solution, which I think was still in Perl at the time. A couple more rounds of playing with consistency checking stuff ensued, resulting in some regularly updated lists being generated by December, and by March 2000 or so that had graduated to a simulation of testing as we know and love it today.
• Played for a sucker, part two: so after a few months of maintaining a testing suite while potato (Debian 2.2) was getting finalised for release I figured it’d be useful to get broader release experience, so asked Richard Braakman if I could help out with the last bits of the potato release. At which point he said “sure”, gave me James Troup’s email address for accepting/rejecting packages etc, then buzzed off to a mobile phone related junket in the US, and laid low until the release was actually out… A cunning plan, for sure. Happily, that didn’t take too long – I think I started around June, and potato was finished baking for release at LinuxWorld Expo in August, though it did involve about 2000 lines of archive changes and stuff mailed to James over the period, along with half a dozen mails to -devel-announce.
• Junket: In the middle of that was my first ever debconf – or technically the Debian portion of the 2000 LSM/RMLL in Bordeaux, aka Debconf 0. It was awesome – met heaps of cool people, got to practice my high school French, and enjoy some lovely red wine while gossipping about free software. Also heard RMS sing the free software song live. But the wine was great!
• katie/dak: The biggest problem with the “simulation of testing” mentioned above was it was held together with paperclips and sticky-tape; or less metaphorically, shell one-liners and hardlinks. Since packages would originally get uploaded to unstable, and then move into testing, and then get deleted from unstable, you’d end up at least doubling the bandwidth required to mirror Debian, because each package would get sent to mirrors once for unstable and once for testing. Which is fine for a simulation, but for deployment, well, we needed package pools, which in turned required a rewrite of dinstall. James did all the initial work, apart from some of the schema design and the scarier SQL, and by November had it deployed for the non-US archive, and got it onto ftp-master in December. At which point the time was ripe for hooking up testing into the archive proper, which is about the point that the testing scripts got named “britney” so as to fit in with all silly names in the da-katie suite. I’m pretty sure the rationale was that I did the final coordination of the potato release (archive changes, cd images, announcement, etc), I spent from about 3am to 10am listening to a handful of Britney Spears songs on repeat. The phrase “scarred for life” might come to mind. Since that point, there’s been lots of evolutionary changes to both dak and testing (including a rewrite of the perl parts of testing into python), but it’s all built fairly naturally from that point.
• debootstrap: I’m pretty sure my motivation for writing debootstrap was a mix of just wanting to avoid having to worry about out of date base tarballs for the purposes of keeping testing in-sync, and wondering if it was actually possible to write a script to bootstrap a Debian system from the sort of minimally functioanl environment the installer has to put up with. In the end, it turned out pretty cool – it was used by the final boot-floppies, it’s part of d-i, it makes tools like pbuilder possible, I think it helps embedded folks heaps, it’s spawned some imitators, and generally been a pretty cool exercise in hackery.
• Freedom and purity: About six months earlier, there was a big flamewar and an attempted vote on whether to remove non-free from the archive. I’d written a rebuttal and counter-proposal, but it all ended up collapsing in a heap, due to disputes about the constitution. For some reason I feel like this mail was more interesting than all the previous ones combined… That ended up needing a whole bunch of changes to the constitution: one to make it clear under what circumstances the social contract can be changed, and another on what happens when one option on a vote requires a supermajority while another doesn’t, and working that out ended up taking from October 2000 until October 2003. It was actually kind-of interesting; trying to analyse a good voting system that works in the real world has all sorts of interesting maths to it, and there’s a whole bunch of election methods guys that have studied it in a bunch of depth. And since its elections, you can have fun with all sorts of scenarious of corruption – like what if the secretary’s trying to change the results. In practice, the difference between good and bad election methods seems to turn out to be negligible, but why wouldn’t you have the best one you possibly can? A couple of months after those changes were done, dropping non-free got reproposed, and I did another counter-proposal; this time they were actually voted on, with the counter-proposal winning, by a little under a two-to-one margin. Which means we get to get rid of non-free by making it completely superfluous, rather than just near enough.

Hrm, this is going on longer than I’d hoped. Oh well, to be continued!

As it was expected, I moved from MovableType crazyness into Tumblr. Ha, so this is now a tumblelog (the world of Intenet sometimes amazes me :P). And as it was expected I brough Blog::Normalize::Tumblr into life. Blog::Normalize is becoming a nice little toy I like to play with. My imported data came from MovableType which was came from Wordpress. Cleanly enough, I d be able to export Tumblr posts (or categories/tags or anything else in the future) into Wordpress again and that d be a nice circle. B::N::Tumblr was made, differently from the other blogging systems modules I created before, by scrapping, that s the transparency that the model of B::N would give users and developers. After I made the whole scrapping work, and by tracing my HTTP traffic, I realized that Tumblr has an API which allows to read and write posts, lol. I d be starting using it soonish and creating WWW::Tumblr, maybe even today. TextMotion support is also on the way. B::N 0.0rc2 should be mirrored by CPAN soon.

I've been re-reading RFC 2822 again over the weekend, for obvious reasons, and I'm amused I've not noticed this section in the past:

3.6.5. Informational fields

The informational fields are all optional. The "Keywords:" field contains a comma-separated list of one or more words or quoted-strings. The "Subject:" and "Comments:" fields are unstructured fields as defined in section 2.2.1, and therefore may contain text or folding white space.

subject  = "Subject:" unstructured CRLF
comments = "Comments:" unstructured CRLF
keywords = "Keywords:" phrase *("," phrase) CRLF

Now we all know that emails have subjects, but how many people have ever used the Keywords: header, or the Comments: one? It'd be nice if we could use these fields in mails - I can immediately think of "keywords" as tags, and I'm sure I'm not alone. I've looked at multiple "tags for mutt" systems, but all of them fall down for the same reason. I can add tags to a mail, and limit a folder to those mails that contain a given tag. But I cannot do that for multiple folders and that makes them useless :( Has anybody worked on a multi-folder tag system for Mutt? If so pointers welcome. If not I'd be tempted to create one. I guess implementation would be very simple. There are three caeses:

• Adding a tag
• Deleting a tag
• Finding all messages with agiven tag.

The first two are easy. The second could be done by writing a cronjob to scan messages for Keyword: headers, and writing a simple index. That could then be used to populate an "~/Maildir/.tag-results" folder, via hardlinks, of all matching messages. Better yet you could pre-populate ~/Maildir/.tag-$foo containing each message with a given tag. Then theres no searching required! (Although your cronjob would need to run often enough when the tag were added to a message it would appear there within a reasonable timeframe. Update: I've written the indexer now. It works pretty quickly after the initial run, and is quite neat! tagging messages with mutt.

A few clarifications on TDebs in Emdebian:

1. Emdebian needs TDebs now and although discussed in Debian, there is no implementation at this time. Therefore, Emdebian has had to go ahead and implement what we need from TDebs in a manner that should be compatible with Debian TDebs when they eventually arrive.


2. .mo files are architecture dependent and this is a problem for embedded devices, therefore the Emdebian TDeb support must take account of these problems whether or not Debian does so as well.


3. Emdebian will continue to need to cross-build existing Debian packages and if that means regenerating the TDebs to ensure compatibility with embedded devices, that will be done too. It is quite likely as Emdebian will certainly be dropping translated manpages and other content of the proposed Debian TDebs.


4. Emdebian TDebs - as the only implementation currently available - do not support anything except gettext. Again, Debian is likely to provide such support but it is not important to Emdebian because packages that do not use gettext are not in the package set likely to be useful on an embedded device.


5. Tests on non-embedded boxes are irrelevant - yes, .mo files work on any Debian architecture that you care to mention. The problem is that the conversion that is so invisible on a desktop machine becomes a real problem on an iPAQ.


6. I started off thinking that Emdebian TDebs could be Arch:all and the existing packages are Architecture: all but this is set to change. Please don't make the same mistake again and again.

I'm grateful to Frans for his comments during my FOSDEM talk - it will involve extra work to fix the Emdebian TDeb support but it is worthwhile.
Emdebian TDebs are just like Emdebian debs - they are customised versions using Emdebian methods that turn a stock Debian package into something suitable for embedded devices. Debian debs differ from Emdebian debs. Debian TDebs will (when they exist) differ from Emdebian TDebs but the principles of splitting out the .mo files and handling installation etc. are similar.
Packages files
Emdebian needs a different solution to the Debian method, at least initially - principally so that we can have a solution that works now, without extensive changes to the rest of Debian. That solution is available in Emdebian.
Selecting languages
The Debian TDeb proposed method is not implemented currently and GLib includes simple support for retrieving the list of languages selected. Again, Emdebian has implemented a solution that works now, not something that is only a proposal on a wiki page.
Eddy, AFAICT almost nothing has happened to bring TDebs to Debian since Debconf7 and until something concrete exists in Debian, Emdebian simply needs something that works - now.
So:
Q: Are .mo files architecture dependent?
A: Yes.

Q: Does it matter?
A: Yes, for embedded devices.

Q: What about this test or that test?
A: Irrelevant because the tests are done on Debian boxes that convert the data transparently, not an embedded device where the time delay would be problematic.

Q: The packages fill will explode!
A: Yes, it would but both Emdebian and Debian have solutions for this problem.

Q: How to select languages?
A: Normal methods using dpkg and locales, but these are also likely to be customised for embedded usage.

Q: Do tdebs support anything else than gettext?
A: No. Emdebian TDebs only support gettext until such time as Debian has a fully implemented solution that can be customised for embedded devices during the normal Emdebian cross builds.

Updates:

1. the arch issue raised by Frans was not the object of my post. Also, not all points are invalid/reiterated, just the ones iterated here. Thanks Frans.
2. add a note that there is an image that proves that .mo endianness is irelevant - usefull for readers that might miss that

---

While looking at Neil Williams' talk(hi-res/lo-res) from FOSDEM about cross building and tdebs I was STUNNED about the many (not all, thanks Frans) points that were reiterated during that talk when there were already answered.

Well, I guess you have to repeat yourself a lot to get your ideas through to the other side. So, let's do that.

All (except the first) of the following have been already answered one way or another on the TDebs wiki page.

Q: .mo files are arch independent or not? Neil asks again on his blog.
A: It doesn't matter, does it?

0 eddy@bounty ~ $ file /usr/share/locale/ro/LC_MESSAGES/wormux.mo
/usr/share/locale/ro/LC_MESSAGES/wormux.mo: GNU message catalog (big endian), revision 0, 228 messages
0 eddy@bounty ~ $ uname -a
Linux bounty 2.6.24.2-bounty #1 SMP Wed Feb 13 02:34:09 EET 2008 x86_64 GNU/Linux

(there is a picture here which proves my point, if you can't see it, click here).



Q: The packages file will explode
A: No, that's addressed.

Q: How do you select languages?
A: Simply use what we have and expand on that.

Q: Do tdebs support anything else than gettext?
A: Yes.

Adeodato correctly points out that building under a Sarge chroot, and expecting the package to work on Sid, might not always[1][2] work mainly because of ABI changes and similar changes. Thus, I am forced to clarify this a little.


Generally, the binaries in the packages we produce do not dynamically link to anything other than libc6, libstdc++5 (yes, 5, not 6) or some internal libraries, so we don't have to worry about ABI changes, at least, not yet.


So, a disclaimer is in order: unless you know what you're doing, you probably are better off building packages for each of the supported Debian distros.

Thanks Adeodato for the heads-up.

[1] unless your package is a special case
[2] or, better said, in most cases

---

udate: fixed the link to dato's post

Update:
A disclaimer/warning is needed: UNLESS you KNOW what you're doing, you probably are better off building packages for each of the supported Debian distros.

---

I know it sounds cheesy, but I couldn't find a better name.


At my workplace we are packaging software to work for as many distros as possible at one time. As a consequence the .deb packages we produce should work fine on all Debian distros: oldstable, stable, testing, sid.

To make sure we achieve that, we are building them in an oldstable chroot. OTOH, using pbuilder is very demanding on I/O, especially when entering the chroot and when exiting it. That slows down a lot the build system and is time to change that.


One reliable alternative is to use cowbuilder (part of cowdancer package). What is interesting is that cowbuilder relies on the existance of /usr/bin/cow-shell inside the chroot, so the cowdancer package needs to be installed both in the chroot and the host machine.

But cowdancer was not a part of sarge, so, if you try to create a new sarge cow directory with cowbuilder, it will fail at the end saying it didn't found the cowdancer package. Also trying to login via cowbuilder --login will complain it didn't found /usr/bin/cow-shell.


The fix for this is simple, once you figured it out and saw that cowdancer is available in sarge as a backport:

cowbuilder --create --distribution sarge --basepath /var/cache/pbuilder/sarge.cow --othermirror 'deb http://www.backports.org/debian sarge-backports main'

You may prefer to be sure that the only thing from backports is cowdancer and use a more hands-on approach[1]. Also, this will eliminate the need to correct later the apt sources to exclude backports[2].

Write the same command as before, but omit everything starting with --othermirror. Then install by hand the package in the chroot.

twix:/home/eddy# cowbuilder --create --distribution sarge --basepath /var/cache/pbuilder/sarge.cow
twix:/home/eddy# chroot /var/cache/pbuilder/sarge.cow
twix:/# wget http://ftp.de.debian.org/backports.org/pool/main/c/cowdancer/cowdancer_0.23~bpo.1_i386.deb
twix:/# dpkg -i cowdancer_0.23~bpo.1_i386.deb
twix:/# rm cowdancer_0.23~bpo.1_i386.deb
twix:/# exit
twix:/home/eddy# cowbuilder --update

Since after the bootstrap all .deb packages will be in the apt cache in the chroot, you might want to save some disk space:

twix:/home/eddy# cowbuilder --login --save-after-login
twix:/# aptitude clean
twix:/# exit

That's it!


If anything is broken somehow, missing or whatnot, cowbuilder --login --save-after-login is your friend.

[1] the initial bootstrap does not pull from backport anything else but cowdancer
[2] since you want to compile for plain sarge, not sarge+backports ;-)

From the start of the DebianEeePC project, we have used a combination of the irc channel and our wiki site to our great advantage. The DebianEeePC/HowTo/Install document has been actively maintained as we go, serving not only as a good reference for new users, but also for existing users and developers to see where improvements are being made and what is left to work out. Recently, we’ve started using the wiki for task management as well. Patterned after DebianInstaller/Bugs, we now have DebianEeePC/Bugs where we link to reports on the BTS for packages we maintain and our own usertags on packages we don’t maintain. As well, we are keeping a DebianEeePC/Todo to manage our tasks. I see from a search through the wiki that lots of other Debian subprojects keep Todo lists, but most of them have little more structure than point-form lists. A few, though, have structured these pages a bit more carefully. For instance, some of these use tables listing who each task is assigned to, when it was assigned, and when it is completed. Our point-form list is a bit more free-form regarding task assignments. Participants can register their interest in a given task and what they are doing as a subpoint of the task. As for state changes over time, we rely on the revision history on “info” page for people to be able to see state changes for particular Todo items. When something is done, it just gets dropped from the list. I haven’t exhaustively reviewed everyone’s Todo page, but from my brief survey I haven’t seen a couple of things I’ve added to try to help people choose what to do next. The first is to tag items with six difficulty/importance pairs, rating each actionable item from Easy/Urgent to Hard/Wishlist. The second is to state dependencies between items using anchors. It would be nice to see any of you are doing something similar and hear about whether it has worked out well for you. I’m happy with how the irc/wiki combination has helped with project management. In the past with a different project I’ve made an abortive attempt to use the task management system at Alioth, but it just seemed too cumbersome and nobody ended up using it. With the wiki, it appears barriers to participation in task management are sufficiently lowered that everyone is willing to help keep it up. And with irc, we can keep on top of defining and assigning (or more usually volunteering to do) various tasks, and making sure the wiki is kept completely up to date. It takes a bit of discipline to do, but after the habits are established, it gets easier, and the rewards are well worth it.

Someone asked on the PyGTK mailinglist if it is possible to reuse certain parts of a libglade window several times within an application.
It certainly is, and it's not even hard to do!

I've quickly written a demo application to show how it's done.
The user interface designed in glade is really simple, a textbox with two toggle buttons underneath. Activating one button will display a second, disparate textbox beside the original one. Deactivating it will remove that second textarea.
The other button will display and remove a copy of the first textbox which was there from application startup.
The full widget tree of this interface is shown in the first screenshot. The actual code to the demo application is rather brief.
The main point to keep in mind is that you can't actually reuse the same widget, more than once, at one time. You could reuse it if you'd make sure it's never used more than once at the same time, and keep track of it (you also have to make certain it doesn't get accidentally destroyed along the way!)

What the demo really does, and what libglade allows you to do, is use (parts of) the same interface definition over and over again to build distinct PyGTK objects and add them to the existing interface. At least the PyGTK implementation of libglade, and possibly the native C libglade as well, actually caches the interface definition in case you'd want to reuse parts of it for additional object creation.

Let's have a closer look at how it's done:

import gtk, gtk.glade
class ReuseDemo:
  def __init__ (self):
    self.gladefile = 'glade-reuse-demo.glade'
    self.xml = gtk.glade.XML (self.gladefile)
    self.win = self.xml.get_widget ('firstWindow')
    self.theContainer = self.xml.get_widget ('theHBox')
    self.xml.signal_autoconnect (
                     dict (gtk_main_quit=gtk.main_quit,
                     btn1_toggled=self.toggle1,
                     btn2_toggled=self.toggle2))
    self.buttons = (self.xml.get_widget ('tbtn1'), self.xml.get_widget ('tbtn2'))
    self.childTree = None
    self.win.show_all()

First step is to import the gtk and gtk.glade modules.
The actual demo is in a little class; it's constructor starts by storing the name of the glade file, because it's needed later to construct the additional objects from (even if the caching should mean it isn't really re-read anymore). The xml tree from this file is parsed by pyglade and the window object is retrieved from the first of the two windows defined in it. At this point the window is already a PyGTK object!

The container that needs to have objects added to and removed from is also retrieved and stored as a class attribute. The signals for the two toggle buttons and to allow a graceful exit by means of the windowmanager close button are connected to their handlers, and the two togglebuttons' objects are also retrieved and stored away for later reference. Finally, a variable to hold a reference to the secondary textbox objects is initiated, and the window is shown.

  def toggle1 (self, btn):
    self.toggle (btn, 'txtContent', 1)
  def toggle2 (self, btn):
    self.toggle (btn, 'txtOther', 2)

The two toggle button callbacks call a single method, with the gladeXML tagname for the respective textbox object each one needs to display or remove and an index number for arguments (in addition to the togglebutton object reference that the callback received as it's first argument).

  def toggle (self, btn, tagname, idx):
    self.buttons[(idx%2)].set_sensitive (not btn.get_active())
    if not btn.get_active():
      if self.childTree:
        self.theContainer.remove (self.childTree)
        self.childTree = None
    else:
      objXML = gtk.glade.XML (self.gladefile, root=tagname)
      self.childTree = objXML.get_widget (tagname)
      self.theContainer.pack_end (self.childTree)

The important logic is in the final method. First, the button which is not toggled is disabled or enabled for user interaction, depending on the activated state of the toggled button. Because the indices passed on by the two toggle buttons' callbacks were one-based, while the python tuple that holds references to the toggle buttons is zero-based, the remainder of a division by two of the callback index will automatically point to the button that was not toggled. Alternatively the values 1 and 0, in that order, and thus pointing directly to the tuple indices could also have been used as index arguments for the two callbacks.

The necessity of disabling the other button when one is activated, and therefore two textboxes are displayed, is because the demo isn't written to support displaying more than two textboxes at the same time, but especially removing the correct textbox when three would be visible. If it were extended in that sense, the need to disable the other button would disappear.

Next the activated state is tested; if the button is deactivated, the second textbox is removed from the container and the reference to it removed, while if it's activated, a new object is instantiated from the gladeXML description and added to the container.
Here's where the gladeXML tagnames come in: to recreate only part of the widget tree, and retrieve the actual widget from the parsed tree. Note that you must reconstruct the parse tree here; retrieving the same object from the original parsetree and trying to add it a second time to the container will result in a GTK+ warning (on the console) and nothing being added at all.

That's all there is to it, really. All that is left is to instantiate a class instance and start the GTK+ mainloop:

if __name__ == '__main__':
  ReuseDemo()
  gtk.main()

The second screenshot is an example of how the application might look in one specific state.

A tarball with the glade and python code is available from the sysfs download area.

When installing postfix and configuring it to act as a "Satellite system", all mails, including messages to root, will go to the remote mail delivery system. Also, there might be a local user account that absolutely doesn't exist on the remote MTA and should stay on the local machine, but, by default, this doesn't happen.

This is not good.

What is needed in such a case is virtual_alias_maps and a /etc/postfix/virtual file such as:

root    root@localhost
root@fqdn.domain.name    root@localhost
eddy    eddy@localhost
eddy@fqdn.domain.name    eddy@localhost

Don't forget to run postmap /etc/postfix/virtual, after restarting the system.


This tip is particularly useful on laptops.