Just a quick note for Google on setting up a newly purchased iPhone on an AT&T GoPhone pre-pay plan, rather than the contract plan. Although the plans kind of suck, you might like to do this if you don't have a social security number or credit history. Several forums mention using an all-9's SSN or an all 1's SSN in the signup field. As of 4th March, 2008, these are not working. You need a different SSN which can be provided by AT&T (a hint, it has a lot of 1's and a 4, although I get the feeling they change this as too many people discover it). This will have the effect of failing the credit check, and even though you have to go through and agree to all the contract terms it will then present you with prepay options. Hopefully that saves some people time setting up their new iPhone!

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 just released version 0.26 of Wammu. This release fixes various problems found by users. Full list of changes:

• Various attempts to make Windows version back to usable state, but it is not ready yet as there are quite random crashes in python-gammu on Windows. Anybody with knowledge of python modules on Windows who is willing to help is welcome.
• Dropped GNOME Bluetooth (btctl) support, it crashes too often.
• Fix icons size to be all 16x16.
• Fixed crash when D-Bus can not launch notification service.

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

Debian testing transitions: OCaml 3.10.1 ... and 3.10.2! The shape of OCaml 3.10.1 in Debian wrt the testing transition is getting better. As you can see from the OCaml status page in Debian we are almost there. This has been the first OCaml transition (almost) entirely done with binNMUs. We requested about 100 binNMUs, with the corresponding dep-waits, and the buildds did the fine exercise. Since binNMUs do not rebuild arch:all packages, some remaining bits had to be uploaded by hand, I've finished that fine exercise last Sunday. In 5 days from now or so the wait time for that bits should be over and OCaml 3.10.1 should happily transition to testing. The binNMUs requests, as well as the dep-waits, have been generated mechanically using a script contributed by Stephane Glondu, exploiting the build-dependencies information we already had. A small bug in the various involved scripts let a missing dep-wait slip through and we had to re-request builds for ocamlnet, but beside that all went fine ... it will go even better next time (now that the bugs has been fixed). ... and speaking about the next time :-), OCaml 3.10.2 has been released a few days ago (what a timing, eh?). Yesterday I've uploaded it to experimental, you can get if from there to test if everything is fine with it. As soon as the current transition is over we can right ahead requests the new binNMUs and hope to have 3.10.2 in Lenny.

I was snowboarding with some friends last week, and in the evenings I had a little rush of uncontrolled creativity: I wrote a new entry in my (German) tech parody news about guitar hero in music education and two new parody songs: Pain of Boarding instead of Sound of silence and a snowboard-variant of I will survive . I ve also hacked up my XML/XSLT/make-website-system to include the songs, so you can find all my songs there now as well.

I like autotools, I use them widely and I'm happy that I understand autotools sufficiently that I can be confident in using them and helping others with theirs. All my own upstream C projects rely on autotools and I have a personal rule that I always preserve make distcheck compatibility during CVS/SVN changes and without fail prior to ALL releases.
Lenny will be the second Debian release with which I've been involved and as I prepare to round on the RC bugs once again, I'm noticing a pattern in autotools bugs from other upstream teams.

1. If more upstream projects enforced rigorous testing with make distcheck, a lot of bone-headed numbskull errors would be prevented in the upstream codebase. Fixing make distcheck isn't that hard because it is a test of the build system files, not necessarily the source code. Once an upstream build is fixed, subsequent make distcheck failures are both rare and serious. Other failures in the test suite should be easier to spot too. The important point is that make check only tests the current build on the upstream system. make distcheck goes a long way to ensuring that the package will build in the same way on lots of systems, including cross builds.


2. autotools expects such fixes to be made upstream and fixing things after the release can be a serious PITA, so fix it before release.


3. The single greatest weakness of make distcheck and autotools in general is bit rot. It is so important for upstream to refresh the autogenerated files on an intermittent basis. With a big development team, this can be easy - especially if new people are regularly joining and building the source for the first time from CVS/SVN. Once that rotation stops, the difficulties of trying to fix the upstream code get more and more noticeable. Maybe one day autotools will fix this and become more resistant to bit rot but, for now, it is a significant problem.


4. As a consequence of file rotation, it is seldom a good idea to keep any autotools generated files in any form of RCS, even distributed ones. This is where I fall foul of many who want to package directly from SVN CVS foo. The mantra of lots of RCS helpers is "everything must be in the RCS" which is just plain wrong IMNSHO. The only things that must be in any RCS are the bits that upstream needs to write. So Makefile.am is, Makefile.in is not. configure.ac is, configure is not. Same for libtool, ltmain.sh, config.* and a host of other autotools generated files. If autogen.sh can generate or symlink them, don't have them in RCS. If, as upstream, you have not had to edit the file or copy it into place using a patch supplied by someone else, it should not be in the RCS. This discipline ensures that when someone starts from a fresh checkout, the build system is refreshed (and is why many autotools upstreams add a "make rcsclean" rule that goes one stage beyond make distclean by going back to raw RCS). If you maintain a helper that is meant to build packages like this, ensure that the helper has support for getting from raw RCS to make distcheck and ensure that the helper uses the tarball created by make dist not one of it's own.

Yes, bit rot is the curse of all software but when combined with the lack of usage of make distcheck prior to upstream falling quiet, I sometimes wonder about the merits of trying to fix bugs in the build system of packages with a most recent upstream release that precedes Etch. I get a real chill thinking about upstream packages with a most recent release that precedes Sarge.
So, if you're working on an upstream project using autotools, just do everyone a favour:

 svn cvs  ci -m "make sure things work"

make uninstall

make distclean

./autogen.sh

./configure --prefix=... 

make

make check

make install

make distcheck

Repeat the last stage until it completes without errors, commit the changes and retest from the beginning.
I'm not proposing something I do not do myself - as above, I do these tests on my own (released) upstreams on a regular basis. I just wish more upstreams would do so too. If every upstream did this prior to that final release, it would be so much easier to do all kinds of cool things with your code, long after you lose interest in it yourself.

Last week, the Free Software Foundation announced an important new initiative called End Software Patents whose goals are pretty evident from the project's name. So far, the initiative is backed by the FSF, the Public Patent Foundation, and the Software Freedom Law Center. There are several organizations who are taking on specific bad patents but ESP is unique in that it is activitely working toward the abolition of software patents in the United States. While the organization is focused on work in the US, it's deeply important globally -- much of the world's patent law is "exported" from the US. The FSF is stretching extremely limited resources in backing ESP to help it get off the ground because we believe two things:

• First, software patents are a fundamental threat to free and open source software (but not just to free and open source software). The FSF must oppose software patents because they provide a fundamental threat to free software's continued success. That sounds like hyperbole but is unfortunately not.
• Second, we can win this fight. For a whole set of reasons, the successful abolition of software patents is a goal that, while extremely ambitious, is also within grasp. These issues, of course, are much bigger than free software. Companies spend billions of dollars in litigation over software patents that are not novel and that should not exist. ESP can reach out farther than the FSF alone and build a coalition that can destroy software patents for the good of much more than the free software community.

Please read the new ESP report on the state of software patents written by the ESP Executive Director Ben Klemens to understand why we are optimistic. And please, support ESP financially in this fight. ESP's continued work is not ensured past the immediate future. Your support will help endow a bright future for the next generation of software developers and users.

What's the best way to join a community, any community? Little by little.
I have been working with Ruby on Rails for well over a year already, even given a talk (at Encuentro Nacional Linux y Software Libre ENLi) inviting other people to use this very nice and well thought out environment. But, so far, I've been only a end-user, not really giving anything back besides minor bug reports.
Well, it's not as much as to say that I'm now a contributor - this is just a first statement of intent. I have worked a bit on several bits of code I keep repeating and hand-copying over my different Rails projects. Of course, that's completely not DRY - And completely not nice. So I decided to stop advancing on several projects, and learn my way on stting those bits of code as Rails plugins.
So far, it's been quite simple - and a good excercise on proper separation. I started, of course, with the easiest bit of code I could think of as useful in a general sense, and packaged it up as acts_as_catalog (of course, proper SVN tree and very basic, introductory README. And, of course, as I keep progressing with this work, I'll keep adding some plugins to my currently quite empty RubyForge page.
Anyway... Little by little, time will come where we have to think more seriously on how to properly bring together the Ruby on Rails style to work more tightly with Debian. Currently, the two have such different points of view on how to manage and ship components that I am not sure we will be able to truly bridge them together... But it is definitively worth trying. Hmh, looks like a task for Debconf! ;-)

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

One final post then I'm done discussing mutt. (Primarily because too many people failed to understand the problem, I guess I wasn't being as good at explaining as I could have been.) So the goal was to be able to tag individual messages within mutt, such that a short while later a new folder would be created containing all messages of that tag, regardless of which folder the message(s) are in. Actually finding the tags and creating the virtual folders is easy to do. I wrote a simple indexer which scans for tags in messages and creates hardlinks as necessary. The problem with this is that many operations on those hardlinked messags would create a new copy of the message and operate on that - trashing the hardlink. For some operations that's just fine. But I did specifically want to be able to untag a tagged message and not have to hunt around for the original. (e.g. remove the "todo" tag from messages where I'd done the relevant action.) So after a bit of trial and error I came up with a patch which allows the editing of a message in-place, in the hardlinked folder, without trashing the hardlink. This patch just invokes "$EDITINPLACE <filename>" where "filename" is the name actual file the message I'm working on is stored on disk. (i.e. ~/Maildir/.people.thewomanmeg/cur/1.2.3.txt). By setting the EDITINPLACE variable to point to my ~/bin/editlabel script I may easily remove any tags from the hardlinked-message and have it apply to the original. Job done! There are some limitations with this approach that are worth mentioning though:

• IMAP? Ha! Nope. We only work on Maildirs.
• The header-cache facility of Mutt breaks my "find the filename of the Maildir message" function. Not sure why, so I just disabled it.
• Many operations on the virtual mailbox will still break the symlink; because they don't edit in place.

I've documented things in a rather random fashion, and I've made a backported package of mutt with my patch available online too. Primarily so I dont lose the source like I did with my mutt-ng backport. Pointless Work I spent about 30 minutes rebuilding mutt to use a bubble-sort on the folder list which is displayed in the sidebar. Only when I was just about to install this patched build did I realise that the mailboxes were displayed in the order they are listed in my .muttrc file. One quick edit with Emacs and the folder list was sorted properly. Boy is my face red.. ObRandom: I'm loving my deaf-friendly alarm clock. It rocks. Place it under your pillow and it vibrates to wake you up. Simple. Effective, and above all it doesn't disturb my partner up when I get up to catch an early morning train. (Thought to be fair I usually wake her up anyway; can't leave without a goodbye kiss!) I'm still waiting for the vibrating ring, but this is good enough in the meantime.

So, as I previously mentioned I want to be able to tag messages in Mutt. There exist folder-based solutions already, using the X-Label header. There doesn't appear to be any existing solution allowing you to view all messages with a given tag across mailboxes. So I wrote a simple shell script to create virtual mailboxes, such as ~/Maildir/tags-debian for all messages with a debian tag, using hardlinks. My conclusion is that this solution will not work properly in practise, primarily because of deficiencies in mutt. The simple case works just fine. I add a tag to a message, and later when the indexing job runs the virtual folder is created. I can open it and work on it just fine. So where's the problem? Well in my case I tend to tag messages with a label such as "todo". Once I've done whatever I was supposed to I can remove the tag. Using this hardlinking scheme I cannot remove the tag(s) in the virtual folder - I have to remove it in the original message which is a real pain. Why? Well quite simply mutt will not let me work on my virtual message without destroying the hardlink.. If I use the edit function, for example, I am presented with a copy of the mail for editing - and the hardlink is replaced when that copy is saved. Even the edit-label patch which allows you to edit the X-Label header from within mutt ends up replacing the hardlink with a new file! So whats the solution? Well I guess I want to be able to run an external command against a message in mutt - passing the filename of the Maildir message as an argument. That way I can edit the live file. Right now I don't believe that is possible, but I'd love to be told different. If anybody has any solutions of editing, or even just deleting, a header from a message within mutt - in such a way that the hardlink isn't destroyed please do let me know. Simple reproducer:

mkdir -p ~/Maildir/.foo/cur
mkdir    ~/Maildir/.foo/new
mkdir    ~/Maildir/.foo/tmp
cp 'validmessage' ~/Maildir/
ln validmessage ~/Maildir/.foo/cur

Now edit the message - start mutt open the message in the index and press 'e' - the hardlink is now gone. Replaced by a new file with the contents, so the original mail message is unchanged. Update: I've got an "edit-inplace" primitive working, via the very hacky header-fu patch. It is not complete, but it demonstrates that it can be done. My world is now complete.

Long live to doc-base Runa wonders: Why aren't we using doc-base? . It's indeed a good question. In the past I've pushed for using doc-base in several places, including obviously packages of mine, but also recently generating by default doc-base entries from OCaml libraries using debpkg ocamldoc, and finally also more than 100 doc-base entries shipped by w3-recs alone for the contained W3C recommendations. doc-base is based on a good idea, i.e. annotating the doc we ship with metadata so that it can be more easily browsed, and is (potentially) far better than asking our users to dig into /usr/share/doc/foo. Still, it is sadly true that in Debian is way underused. My best bet at the reason is that in the past the tools floating around doc-base were sucky. However, in 2007 some of them has dramatically improved their quality, with the noteworthy example of dhelp which has been rewritten from scratch in Ruby by Esteban Manchado Vel zquez closing tens and tens of bugs. My exhortation: please, maintainers, go back and consider (again, if needed) to register your documentation with doc-base, it is helpful and it does work. The next (needed) step for the doc-base world domination will be decoupling its classification hierarchy from that of the Debian menu system, keeping the 2 bound is nonsense. Update Runa submitted bug #469018; cool, because I was just going to do that by myself

Anatomy of a Murder. David Denby put it best:

Otto Preminger s Anatomy of a Murder, from 1959, is still the best courtroom drama ever made in this country, and, in its occasional forays out of the court, among the finest evocations of place an Upper Peninsula Michigan resort area in the off-season, leafless, underpopulated, alcoholic, and forlorn. James Stewart, in one of his wonderful melancholy late performances, plays a former county prosecutor named Biegler, a lifelong bachelor who now spends his time with a non-practicing lawyer (Arthur O Connell) and an unpaid secretary (Eve Arden), who sticks around for the wisecracks. The movie is leisurely, detailed, realistic, intensely companionable; you get a sense of how people exist at the margins of a profession without losing their dignity.

Although there are some distinctions between a murder defense in the 1950’s in the Upper Peninsula of Michigan and modern-day patent litigation, the essence of trial technique is really not all that different. Highly recommended.

Prosecutor: Lieutenant Manion, wasn’t your action against Barney Quill much the same thing as your action against Miller or the Lieutenant you slapped at the cocktail party — all done in the heat of anger, with a willful, conscious desire to hurt or kill?

Defendant: I don’t remember my action against Quill.

Prosecutor: How long had you known your wife was stepping out with Quill?

Defendant: I never knew anything like that. I trust my wife.

Prosecutor: You just occasionally beat her up for the fun of it, I suppose?

Defense Counsel: There has been nothing established to permit a question like that. He keeps trying to insinuate without ever coming to the point. Let him ask the Lieutenant, did he ever beat his wife.

Judge: I will sustain the objection. Do you want to re-phrase your question, Mr. Dancer?

Prosecutor: No thank you, Your Honor. I’ve finished.

Technorati Tags: Otto Preminger, Anatomy of a Murder, David Denby

Share This

In November 2007 Roberto C. Sanchez filed bug #451690 in irssi: Please include a doc-base registration file. Including this file isn’t that hard, and while reading the Debian doc-base Manual I found out that “Every Debian package that provides online documentation (other than manual pages) will register these documents to doc-base.” So, if a missing doc-base registration file is important enough for someone to file a bug on, why does my /usr/share/doc-base/ only contain 69 files compared to the 1444 files in /usr/share/doc/ ?

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.