At work, I recently encountered #261107 on our distantly Debian-derived server and workstation distros. It really annoyed me because installing the mysql-server package fell over in a screaming heap when it went to create the mysql user. I'd seen a bug filed internally, relating to this particular use case, and initially I thought, based on the output, that it was the MySQL package's pre-install script not quoting the string "MySQL Server", but upon further investigation with strace, it turned out to be adduser's internal call to chfn that was failing, all because of the lack of a controlling terminal. Anyway, a colleague fixed the problem, and pointed me to the abovementioned bug, and this is what strikes me as so strange: the bug has been open for approaching 3 years. I can't reproduce this bug with a stock sarge or etch install, yet I can reproduce it on an Ubuntu Dapper-derived system at will, by calling chfn -f with /dev/null redirected to stdin. If this bug was biting with any sort of regularity, there'd be people rioting, because their adduser calls would be falling over, left, right and centre. Yet it was obviously reproducible for the bug submitter, and I can reproduce it at work. There's more to it than the lack of a controlling terminal. The plot, it be thick. Update Mystery solved. Apparently if you specify terminal restrictions in /etc/security/access.conf (even explicitly restricting it to "ALL"), pam_access gets all bitter and twisted if there's no controlling terminal for the thing being authorized. Wicked.

Gar. I had to go downtown today to sign some legal papers with our lawyer. He's taken a gig as the interim chief of staff for the president of Concordia University, but he's kept a few of his older clients, including us. Maj and I stopped at the bank beforehand to sign some mortgage papers, and then we went to the SAQ across the street to buy some wine. We then piled back in the car, drove downtown, and with a little time to spare we stopped at Zyng for lunch, walked around St. Catherine a little bit, did some furniture shopping, and then met our lawyer near his office. We had a good coffee together and saw the new engineering building there -- it's quite nice. When Maj and I got back to the car, I realized that I didn't have my remote starter for the car -- which also disables the car alarm. This little gadget has been a real pain for me since we got the car -- the thing that attaches it to the keychain almost instantly broke, so I've had to carry it around separate from my keys. And now it was gone, and I had no idea where it was. So we retraced steps -- another 45 minutes walking around to the noodle joint, the furniture store, the Concordia caf . Nothing. We looked around on the street for a while, then jumped in a cab and came home. Maj had her keys here, so I borrowed them, cabbed back to where the car was parked, and as I was getting into the car I saw this: That's the clicker, right under that SAQ brochure about Italian wines. DOH! Moral of the story: attach your car-alarm clicker very carefully to your keychain. Sure, not much of a moral, but it's what I learned today. tags: car alarm clicker montreal concordia zyng car

RSS validated So, after starting an RSS 1.0 feed for my blog, I was having some problems using it in different readers. A few Google searches later landed me at the [$$vote for http://validator.w3.org/feed/, which is totally cool. Why didn't I know about this before? It turned out that my Tag URI format was invalid. I was using tag URIs for RSS item identifiers, and I'd left off the all-important validity date. So I had to update those. It seems to be working pretty nice, now; the validator gives the all-good sign for both my RSS 2.0 and RSS 1.0 feeds. tags: rss validation w3c

Greek Wikitravel Expedition So, I'm going to be interviewed this week for Hellas Spectrum, a Greek-language television show here in Montreal focusing on the local Greek community and culture. (I know - wow!) Apparently the interview will be "mostly" in English, with "a little bit" of Greek. Uh-oh. I studied some Greek in college, and I spent a summer in Crete and made my way pretty nicely, but I definitely haven't used the language in years. So this should be fun. I'm pretty embarrassed that I'm so inept in my ancestral tongue, and I hope that Amita June learns more than I have. The whole thing has reminded me that we don't have a Wikitravel language version for Greek -- yet. So I started a Greek Wikitravel Expedition to try to collect a group of users to make the wiki work. I've asked already on Greek Wikipedia, and I hope to find some more centres of Greek Open Source/Open Content culture on the Web. Greek people are disproportionately represented in science, engineering, and technology, so I think there will be a lot of interest. So, question for the LazyWeb: where are the good Greek Open Source/Open Content community Web sites? Influential Greek bloggers? What's the Greek Barrapunto? How can I get more interest in this project in the Greek Internet community? Contact me and let me know. tags: greek wiki wikitravel

I have long recognized that to be usable by young kids, xjig really needs a better user interface. So I wrote a launcher, xjig-menu to address the problem. It adds a file open dialog (via zentiy) and support for more file formats (via imagemagick). Update

I have put this script in subversion and added a man page. Check it out:

  $ svn co svn://svn.debian.org/pkg-games/people/synrg/xjig

or browse the repository.

Man, I totally missed the announcement that Netscape.com now supports OpenID. This is pretty great -- Netscape is probably the biggest OpenID consumer on the Web, after Technorati. And Technorati only uses OpenID for a few limited purposes. Good news for Netscape.com and for OpenID. tags: openid netscape consumer

Science of Sleep I just finished watching The Science of Sleep. I liked the animation, and the writing -- the ambiguity of the sleeping state and the waking state. And I like Gael Garc a Bernal. But I also realized that films about people on the brink of mental illness are really distressing for me. Otherwise, it was a good movie. tags: science of sleep film

Speaking of sleep I've been finding the Nokia N800 really difficult to use as a mobile computer -- or, rather, as a mobile toy. I haven't been getting as good WiFi coverage with it as I'd like, when taking it around, so it's not that fun to play with. I took it to the bank so I'd have something to do while waiting in line, and I couldn't get a network connection. So yesterday I imported my OPML feed from Sage into the RSS reader on the N800. I figured that even without connectivity I'd have something to read on the computer. But my feeds (about 20-30; is that a lot?) slowed down the N800 to a crawl. When I rebooted the machine, it got in the same boot loop it had problems with before, and wouldn't start. I had to re-flash the hard drive again, but luckily this time around I had a recent backup. Unluckily, it doesn't seem to want to restore the backup. It's frustrating. tags: n800 opml boot

AFD So, there's not one but two April Fools Day articles on Wikitravel. Last year, we had an excellent guide to San Serriffe posted, but I think this year's joke guides to Earth (for aliens) and Hell (for everyone) are pretty good, too. tags: april fools day wikitravel

Had a great time at DemoCampMontreal2 tonight. There were a ton of people there, the demos were great, and the bar at the SAT was open for business, so it was possible to drink beer and watch demos. There were all very solid projects with lots of interesting stuff going on. My favorite aha! moment came from Hugh McGuire showing off Collectik, his new social-podcast-aggregation platform, when he demo'd how he uses the site, and I realized that that's how I want to organize my podcast listening, too. I also liked Kakiloc, a location-oriented social networking site. They let you tell your friends what you're doing and where you are, and the friends can see it on the Web, by SMS, or through IM. Sound familiar? Yeah. Kakiloc's advantage is that they have more geo-oriented interface, and some extremely powerful rules that trigger activity when you (say) get close to someone in your circle of friends. However, I think in a world of Worse Is Better Kakiloc is going to have a hard time making a sale. Twitter already has the mindshare in this market, and the network effect makes it more valuable for people to stay with the popular platform. I also really dug the films from OpenSourceCinema.org, although they skirted the "demo" concept pretty scarcely. One thing that was neat was that the OSC Web site was built by a real-life barn-raising: Sylvain Carle put out the call for some help, and people convened on his house to build the Web site. Cool idea. All in all I had a really good time. DemoCampMontreal2 worked out well. tags: DemoCampMontreal2 kakiloc collectik opensourcecinema

Bait and switch So, on the way out the door to DemoCamp, I grabbed a handful of loonies out of my bedside change basket for the parking meters downtown. When I got to SAT, though, I realized that the "loonies" I'd brought were in fact Sacagawea dollars. I'd gotten them as change from the ticket machines on the Las Vegas monorail. Doh! Fortunately, downtown Montreal parking meters take credit cards, so I was OK. tags: loonie sacagawea parking meter monorail

Feisty Upgraded to FeistyFawn on Wednesday. Worked fine, nice smooth upgrade (who expects that?). Nothing revolutionary, but the software works well. tags: feistyfawn ubuntu upgrade

• The latch is badly designed
• MacOSX 10.4.9
• heavy (compared to an X40)
• 2 USB ports? That’s it? I accidentally jab the Firewire port with my USB devices
• That camera looks tiny
• Amazed how it detected the open wireless network. nice.
• Slow
• Track pads are terrible. Even my Dad concedes he hates it. Give us a nipple anyday.
• Plugging in my external USB fat32 hard drive didn’t work! With nfs to access my media, I was surprised how to listen an mp3, you have to copy the file into Itunes. Omg. And watching a movie. Quicktime with no fullscreen playback. OUCH.
• I’ve had to get used to looking at the top bar carefully
• ctrl+trackpad button is right click. OMG. Pain.
• samba doesn’t seem to work right
• I can’t figure out how to scroll through photos. I think there is some crap Canon image software (why do camera manufacturers seem compelled to ship terrible software with their hardware?) getting in my way here.
• Quite noisy when doing something
• Software update doesn’t seem able to resume unlike Debian. :(
• It absolutely HOGS the Internet connection! WTF! Do I have to implement QoS now? How can my Debian machines share the Internet and Wireless nicely, but not this Macbook?
• Can’t shut it down after an update
• Zoom is pretty cool for my dad
• I am slowly starting to discover the shortcuts and how to manage Windows. Alt+Tab fealt wrong though. Can’t launch dictionary. Maybe it’s not installed?
• The interface isn’t that great. Intuitive my ass. They often move the close button about.
• Updating Itunes, “Please quit iTune before conti…” Pity it can’t update a running application like Debian.
• Installing .dmg files isn’t nearly as easy as apt-get
• When I close the lid, it stops doing what it supposed to do. I HATE THAT. If you have power, do not suspend whatever.
• The shell and some sensible default applications like vim is quite nice
• I’m not a fan of the widescreen dimensions.

Btw this is my Dad’s Macbook. I’m still married to Debian SID and a Thinkpad.

Life sometimes goes in a funny direction, like a full circle d j vu: 20 years ago, I was studying Technology of Computerized Systems (a combination of electronics and programming). Now, 20 years later, I'm starting a dream job as the Business Development Manager of Artec Group and their core business is you guessed it exactly that. The really cool thing about Artec, from a Free Software advocate's point of view, is that they contribute firmware and drivers for their products to LinuxBIOS and the Linux kernel. At this point, my initial tasks will focus on marketing and selling Artec's flagship OEM product, the ThinCan. What is the ThinCan? Actually, you're already familiar with one iteration of the product: the Linutop is a branded ThinCan, delivered with a custom hardware configuration, plus custom casing artwork designed by Fr d ric Baille of Linutop SARL and loaded with Fred's favorite Xubuntu configuration. In the Linutop's case, their business model is to fill the market niche for a simple Internet surfing platform that fits 80% of average people's daily computing needs, so the hardware configuration they ordered reflects that. Still, as several readers of this blog noticed, the "Linutop" could make a fantastic thin client and, sure enough, that was the main purpose behind the ThinCan's original design; it sells well in the Fortune-500 market as an RDP client running under Windows CE. However, until recently, there simply wasn't much demand for a contemporary X11 terminal solution based on the ThinCan. That is, until LTSP took off, thanks to the contributions of Edubuntu and similar educational Linux distributions. Sure enough, someone spotted the opportunity and contacted Artec to order a branded ThinCan iteration with Etherboot and PXE support, which they call the Linuterm. By the way, for those who need a really cheap OEM thin client, I've got a great spring clearance offer for you:

Artec has about 500 pieces left of their older DBE60 ThinCan model, based on the AMD Geode SC2200, and we're selling them at 100 euro / piece, plus VAT and shipping.

The DBE60 is configured with three USB 1.1 ports, one parallel printer port, one 100baseT Ethernet port, one VGA port (up to 1024x768 @ 16bpp 60-85Hz or 1280x1024 @ 8bpp 60-75Hz) and one 1/8" stereo audio output jack. Its BIOS provides Etherboot support and its motherboard is populated with 64MB of RAM and 32MB of Stratoflash. It comes delivered with a European AC adapter. The Geode SC2200 is fully supported by the Linux kernel with the sole exception of a missing ALSA snd-scx200, but this could easily be ported from AMD's deprecated OSS driver and X.org support is provided by the "nsc" driver.

Minimum order size is 10 pieces. Contact me via my full name (unaccented, with one hyphen and one dot) at artecgroup.com quoting this special offer.

PS: someone was asking if that DBE60 special is also available in the aforementioned Fortune-500 configuration. It indeed is: add 16 euro / piece for the Windows CE 4.1 license with an RDP client.

Just uploaded simple-cdd 0.3.0 to experimental, as a simple-cdd user since Sarge days, I've helped a lot Vagrant with Etch support that required a huge amount of development due to the d-i and debian-cd changes. Thanks for those who helped us with testing and patches!

If you're lost, simple-cdd is a limited though relatively easy tool to create a customized debian-installer CD. It supports multiple install profiles for your CDD project (We can ask your user which to install, you can simple have one or preseed it); You can preseed the packages that will be installed as you can do using d-i; i18n support for those who want custom Debian localized images; multiarch support; postinst support for profiles; simple-cdd-profile udeb take care about extra packages installation, it doesn't need tasksel.

So say we all!

Dear Lazyweb: Is it really impossible to find a full-sized USB keyboard with a built-in trackpoint mouse device but no touchpad? The logical manufacturer would be IBM/Lenovo; however, the current Lenovo keyboards either provide no built-in pointing device or have both a trackpoint and a touchpad (”UltraNav”). I’ve checked in all the regular places: eBay, Pricewatch, Amazon, Froogle, craigslist, etc., and no one has a keyboard with just a trackpoint. I’m sure I’m not the only one with this simple request. This eBay auction is the closest I could find. That keyboard is “French Canadian,” which might not matter, but it is also a “SpaceSaver” model with no numeric keypad and is generally more compressed than I need. On a related note, it is next to impossible to find a Touchstream Keyboard anymore, another brand I was interested in. I often run into this sort of problem. It undermines my faith in the web as approximating a perfect marketplace.

Who of us, computer literate people, is not used to multitasking when working? We are bombed with information from different sources when in front of computer and we try to get the info as soon as it is produced. But this is no the only environment when you made things in a multitask way: I am sure you have tried to cook while you clean or you read Slashdot at the same time, however not the way your mother does (it is not that my mother reads Slashdot, though), who puts on the fire something that is long to be cooked, and then goes for house cleaning. You try to do that almost at the same time in realtime: pity you don't have a core duo brain and body. The problem is that all we think that this way we perform more: "hey! we are doing a lot of stuff at the same time!" You reply the email as soon as it arrives, though you were writing that report your boss asked you in about that issue, and at the same time you can even drink a coffee, and IM your friend about which movie are you going to watch tonight. But this article in New York Times can help you to see that this is not true. As any CPU out there is penalized when multitasking, as it has to change context, the same happens to us, but for our brain that gap is longer. It is not a good idea to try to multitask and at the end not achieve any of the goals we made. Perhaps this is the reason that can explain Debian Etch release delay. Stop multitasking!

In June I plan to attend the DebConf 7 in Edinburgh. I like train riding and after all it s good for the climat, so I ruled out flying.If you want to go to UK by train, you have to take the EuroStar through the tunnel. The Deutsche Bahn offers a nice package including a sleeper train for 86, so I got that part covered. But that only gets me to London, and I need to go to Edinburgh.So today, I orderd a one way ticket from London to Edinburgh for 28.50 from GNER, one of the private british rail companies, and payed by credit card. Right after I sucessfully booked the ticket, I noticed some problems with the shipping address: An Umlaut in the street name has turned into weird characters and it did not display the counry (Germany) that I m sure I selected. So I immediatelly sent this mail to GNER:

Hello, I just booked this ticket online. It seems there are problems with the German address, though. The correct address is: Joachim Breitner
Ehb hl 33
71083 Herrenberg
Germany (you can replace by ue if necessary) My Booking Reference: xxxxxxxx Thank you,
Joachim Breitner

And got this response:

Dear Joachim

Thank you for your recent e-mail regarding delivery address of tickets.

I can confirm that we do not deliver tickets overseas. However, since our system is automatic, as soon as you click on the 'Buy tickets' button, the tickets are printed and sent in post.

Please remember that once the booking is confirmed, the delivery address/method cannot be changed.

In this case, if we receive the tickets back from the General Post Office, they can be reissued to a UK address and if we do not receive the tickets back, you will have to buy new tickets as your tickets are non refundable.

Please reply to this e-mail with a UK address, where you would like the tickets to be delivered so that I can update it on the notes, and the tickets will be posted, once received back. If we do not receive the tickets back, you will have to buy new tickets.

If you have any further queries, please do not hesitate in contacting us.

Kind regards

Saurabh

Now I really wonder:

• If they don t send tickets abroad, why do they allow me to enter a German address?
• Should I ask my credit card company to deny the payment (if that is possible)?
• How do I get my ticket now?
• And do we really want to privatize the Deutsche Bahn?

Update: I gave them an address in the UK now, I hope it works out (thanks Ben). And the Deutsche Bahn is already privatized, just not publicy traded yet and is 50% owned by the state, I was confusing that.

I've been writing a lot about this lately, I know, but it's an interesting landscape.

I had previously discarded git, but in light of git-cvsserver (which provides a plausible way for Windows people to participate), I gave it a try.

The first thing I noticed is that git documentation, in general, is really poor. Some tutorials that claim to cover git actually cover cogito. Still others use commands that are much more complex than those in the current git -- and these just the ones linked to from the git homepage.

git's manpages aren't much better. There are quite a few git commands (such as log) that take arguments that other git commands accept. Sometimes this fact is documented with a pointer to these other commands, but often not; a person is left guessing what the full range of accepted arguments are.

My complaint that git is overly complex still exists. They've made progress, but still have a serious issue here. Part is because of the docuemtnation, and part is because of the interface. I wanted to export to diffs all patches on the current branch in a repo. I asked on #git, and someone suggested using the revision specifier ..HEAD. Nope, didn't work. A few other git experts chimed in, and none could come up with the correct recipe. I finally used -500, which worked but is hackish.

git's lack of even offering support for a human to indicate renames also bothers me, though trustworthy people have assured me that it doesn't generally cause a problem in practice.

git does have nicer intra-repo branching than Mercurial does, for the moment. But the Mercurial folks are working on that anyway, and branching to new directories still works fine for me.

But in general, git's philosophy is to make things easy for the upstream maintainer, and doesn't spend much effort making things easy for contributors (except to make it mildly easier to contribute to a large project like Linux). Most of my software doesn't have a large developer community, and I want to make it as easy as possible for new developers to join in and participate. git still utterly fails on that.

I tried bzr again. It seems that every time I try it, after just a few minutes, I am repulsed. This time, I stopped when I realized that bzr doesn't support tags and has no support for emailing changesets whatsoever. As someone that has really liked darcs send (and even used tags way back with CVS!), this is alarming. The tutorial on the bzr website referenced a command "bzr help topics", which does not work.

So I'll stick with my mercurial and darcs combination for now.

I announced the first version of a hg send extension yesterday as well. I think Mercurial is very close to having a working equivalent to darcs send.

Awhile back, one of my favorite bloggers, Philip Dawdy of Furious Seasons, deviated from his usual posts that place a big fat critical magnifying glass under the marketing (and other shady) tactics of Big Pharma and wrote a very thoughtful, (also furious) account of Web 2.0 claiming:

this whole Web 2.0, social networking, virtual community business is essentially a pornography of the self a projected, fictionalized self that is then worshipped by the slightly less-perfect self.

It is a little off the top at times but makes some really good points that I agree with (and generated a really interesting discussion). It merits reading alongside Danah Boyd’s recent rumination on the very same topic, fame, narcissism and MySpace, where she seeks to address narcissism but she deflects blame the suite of technologies and places it instead on the broader set of cultural practices that sustain this accentuated inward focus:

My view is that we have trained our children to be narcissistic and that this is having all sorts of terrifying repercussions; to deal with this, we’re blaming the manifestations instead of addressing the root causes and the mythmaking that we do to maintain social hierarchies. Let’s unpack that for a moment.

These two read nicely with an older piece in Harpers Attack of the superzeroes: why Washington, Einstein, and Madonna can t compete with you . The author, Thomas de Zengotita claims “Being famous isn’t what it used to be” because new technologies of mediation and reflexivity (and by new, he means a lot more than web 2.0, it includes reality shows, focus groups, karaoke, the hyper-representation of the real stars, alongside the usual suspects) and concludes that we life as if we were always on stage, concluding somewhat disparagingly “We are all method actors now.” Of course, this is an important part of the story but not the whole story. There are times, for example, these social technologies help to patch up what is arguably as common in North America as is this narcissistic self, which is the fragmented self, that comes into being, for example because many of us, migrate here and the, for example, for work. So a social networking site like Facebook, provides somewhat of a stable point of reference, where there are individuals collected, in the same place, even though the people are no longer really in the same place. It is at least a recognition of certain relationships whose “local” face has now passed but instead of completely completely fading into the realm of memory, the past lives on, albeit in transformed ways, within a virtual space. This facet of social networking is not particularly narcissistic, but is building new technologies of memory that I think works somewhat against the conditions that fragment the self. And while the patching up of the person may make an individual “whole” and “individuated” it seems it is a form that is much more mundane than the “pornography” or “narcissism,” explored above, though of course, they do abound–but karaoke, that is always pornography of the self. But… porn can be fun.

PCWorld provides a list of the 50 most important people on the web. Topping the list, unsurprisingly, are Eric Schmidt, Larry Page, and Sergey Brin. Other usual suspects include Steve Jobs, Bram Cohen, Jimmy Wales, Bruce Schneier, and Craig Newmark. I was disappointed that there wasn’t a single practicing attorney on the entire list. The closest they got is Larry Lessig, who is admittedly a lawyer of sorts, but at least in my mind more of an academic. A couple of others appear to be former lawyers. I’d like to think we lawyers can make enough of a positive difference to be “important.” The optimistic view might be that practicing attorneys need to keep a lower profile on the sorts of issues that attract PCWorld and the like and are thus unlikely to be recognized publicly. The pessimistic view is that the technologists and business people just matter a lot more.

The e2fsprogs package in Etch features the ext[23] resize2fs, see it in action on a mounted /usr partition:

nancy:/root# egrep usr /proc/mounts 
/dev/mapper/nancy_vg1-usr /usr ext3 rw,noatime,nodiratime,data=ordered 0 0

Now let's extend a bit that logical volume:

nancy:/root# lvextend -L+700M /dev/nancy_vg1/usr       
Extending logical volume usr to 4.68 GB
Logical volume usr successfully resized

Next easy step is to invoke resize2fs

nancy:/root# resize2fs /dev/nancy_vg1/usr 
resize2fs 1.40-WIP (14-Nov-2006)
Filesystem at /dev/nancy_vg1/usr is mounted on /usr; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/nancy_vg1/usr to 1227776 (4k) blocks.
The filesystem on /dev/nancy_vg1/usr is now 1227776 blocks long.

Update: Mika of course already blogged about ext3 online resizing. Bug #400797 is a very good reason not to use ext2resize. I remember a post from Theodore Tso on it's bad code quality. Don't trust it.

... or why PHP sucks so much?

It is quite common (at least for me) finding abused web applications on shared hosts around. The most typical case is finding some kind of IRC bot running as www-data and a few unauthorized files around used for phishing, cross-site scripting or what else. That motivated me to try playing with mod_chroot in order to minimize the possibility of webapps abuse from our friendly kiddies^Wcrackers. Mod_chroot is a nice tiny Apache module whose purpose is the confinment of webapps within a limited tree, where nothing but a few files and dirs are available to try exploits and abuse badly written code.

Unfortunately, I found that mod_chroot poses one major problem (among others, see its CAVEATS doc): the sucking mail() function is not working out of the box, because PHP folks - God knows why - decided to implement that stuff by calling a local /usr/sbin/sendmail program within a shell call. The most sane option is simply ignoring the issue and living happy with a disabled local mail() function. A nice solution in that case is using a PEAR Mail module, which is able to send mails via SMTP in much more elegant way. Unfortunately, there are quite a good number of morons out there, and that could be not a viable option if you are the system administrator of a bounce of shared hosts which are exposed to those morons, who absolutely need a working mail() function.

After a few googling around, I did find that many people had the same problem, but none found (or explained) a working and neat solution for a working mail() implementation, so I'm writing some notes about that. My implementation is based on a nice tiny program (mini_sendmail) which has the great advantage of not requiring a configuration file or a spool directory to work. It also works without suid bit on, which is a good thing as well. It is statically compiled by default, so it simplifies things a lot. In order to have mail() working you need also to install a (statically compiled) shell, e.g. bash-static as sh under the /bin directory of your chroot tree (a more tiny shell would be appropriate). I commented out the silly username autodetection code in the mini_sendmail.c source, because it creates some problem within an empty chroot tree (it failed with a "can't determine username" message with or without the /etc/passwd file available).

Now, the next step is using an entry like

sendmail_path = /usr/sbin/sendmail -t -fwww-data@your.domain -s127.0.0.1

in your php.ini file. You can also use another IP address if your SMTP server is not your localhost or you used some more exotic routing setup. Having a suitable /etc/hosts is also useful. A final trick is adding a var/lib/php4 or what ever directory is required to store PHP session files. No other files should be required in order to have all working. Of course, you have also to use inet sockets for any required connection (e.g. mysql) but this is typically the default in etch. I would also suggest to add only ad hoc statically-compiled binaries within the chroot tree when required, else you will need to store all required shared libs: in that case you will need to find binaries requirement by using ldd and chroot to find loading/running errors by means of an usual trial-and-error cycle.

The aim of Debian is to integrate software produced by other projects to create a complete operating system based on free software. In recent years, the project has faced increasingly delayed and unpredictable releases. Most notably, the release process of Debian 3.1 was characterized by major delays. Initially announced for December 1, 2003, the software was finally released in June 2005: a delay of one and a half years. Since then, the project has made a number of improvements to its release process.

Version	Date	Months
1.1	1996-06-17
1.2	1996-12-12	6
1.3	1997-06-02	6
2.0	1998-07-24	14
2.1	1999-03-09	7
2.2	2000-08-14	17
3.0	2002-07-19	23
3.1	2005-06-06	35

Past Problems

• Release management was not very organized and release updates were posted only infrequently. Because of this and the lack of a roadmap, freezes were often announced out of the blue.
• Due to the unorganized nature of the release, several new and unexpected blockers were found during the release process, leading to delays.
• The unexpected delays meant that software was frozen for a long time, in the case of Debian 3.1 for over a year. When this release was finally published, many components were already out of date and would often not meet user demands.
• The fact that Debian has experienced significant delays with several of its recent releases has led to problems with the image of the project. There is a perception that Debian is slow and cannot meet deadlines. This is also associated with frustration in the developer and user community.

Solutions

• The project has implemented better release management structures. In particular, Debian moved from a single release manager to a team during the 3.1 release cycle. The release is now handled by two release managers with the help of several release assistants.
• A release date for the next release was set well in advance and there is more planning.
• Release announcements are sent more frequently and various information sources have been implemented through which developers can stay informed about the release status.
• Release targets have been defined better and there is a distinction between blockers and goals. Only blockers hold up the release whereas goals can be postponed for a future release. For example, the XFree86 to X.org transition and the integration of AMD64 support were blockers, while LSB 3.1 compatibility and SE Linux support were only goals for Debian 4.0.
• The release team has shifted the responsibility of achieving targets to specific developers and teams. There are also better criteria now defining these responsibilities. For example, criteria have been published that architectures need to fulfil for inclusion in Debian 4.0 and there is a page indicating the status of each architecture.
• The release team is increasingly giving encouragement to developers to help out with software packages and bugs which normally do not fall into their domain.
• A staged freeze has been implemented according to which software is frozen in stages according to its importance. The toolchain and base system are frozen earlier than the majority of package. The majority of software is now frozen when most blockers have been resolved.
• The use of the experimental repository has been promoted to make sure that the main development repository is in a good shape most of the time.

Outstanding problems

• Developers still need to be convinced that targets can be met, that deadlines are real and that Debian can release on time.

(Update: Yes, Gunnar, the policy says that the debian/rules file must be a makefile, so if you do something else, you have a serious bug because of a policy break. Of course, probably there is nothing that should stop one from using, let's say bash, or python or perl, from a technical PoV.)

Erich has a wish list for Lenny.

What draw my attention was the very first "define and deploy a standard way of packaging software, that can be used for like 90% of packages", later he mentions rationale "other distributions (e.g. *BSD ports, Gentoo?) are ahead of us in this respect, having a standard way of packaging and building things and keeping track of changes."; these two quotes contain the real essence of Gentoo's success in the area of fast development.

A half a year ago I did an experiment in packaging a rpm, a deb and an ebuild for the same piece of software. What I observed back then made me think a lot about the entry level knowledge needed for a person to create a decent package for those types of package systems.

With the risk of being flamed by many people that will miss my point, I will tell you from the start that the deb would have been the most painful if had to start from scratch. Second would have been the rpm due to lack of good/updated documentation and the clear winner in lack of pain points was the ebuild. In reality places were switched between the deb and the rpm.

And before I start, please understand that what I want to point out is that the building system in debian is showing its age and we should do something about it, and is not about pointing people to documentation; it is about making things behave more sanely by default and not about having to read a whole day to understand why the package fails to install a file you just added then to find that you had to add the destination path to a debian/dirs file etc...


The deb had to be the most difficult. Not because I didn't do it before, or because it was hard, but because there are a lot of things that need to be done because the package management is not smart enough to do it by default (i.e. class inheritance does not exist, like is the case for the ebuilds or the macros for rpms).

The Debian approach is backwards, is reversed with regard to the others and the way it should be by default, to allow easier understanding of the packaging. You can, by default, make a package that is tweaked a lot. There is no concept (if you don't count cdbs which is boo-ed a lot by some people) or possibility to just say "make this package a package that is a standard linux app with the regular ./configure && make && make install recipe". And I don't count such a recipe the templates based on dh_make, that is way too verbose. A new maintainer wannabe has difficulties understanding why are those lines in there, and what they do, and most importantly, why is that order correct and no other. Another question which is legitimate is "is that the minimum or can that be trimmed"? (Follow debian-mentors and see how many people leave the .ex files just because they are afraid they will not know how to generate them again.)

Even the rpm has a concept of standard stuff to do for a package, there are some macros that implement that. And that is more logical for an untainted mind (as in not yet debianized) than what we have in the dh_make template, or worse, a clean and new debian/rules file. Why should one care to learn the ways and philosophy of make just to make a small package?


Let me tell you something that will feel like knife stab for many people in our community: the clear winner was the ebuild, not because I was smart or exciting, but because:

• it was dead simple to make a working one
  
• the documentation is really verbose and complete
• there is a default behaviour for every ebuild, even for a minimalist ebuild
• if your ebuild has a special need, the ebuilt can override the default behaviour by redefining the function (target, in debian/rules-speech), but you don't need to, in most cases
• there are some already defined classes which can be inherited to obtain a tweaked default behaviour (imagine typical cmake build system, typical autotools build system, typical kde build system - and iirc, this can include build dependencies)
• all the information about the package is centralized in one file which is human readable from the start, plus that is obvious, or one can understand fast what a field/function/variable means from the start, without digging through the documentation continuously
  

I did the ebuild in one day's work (it was less, but some will not believe me, so I'd say 1 day is reasonable enough) starting from absolutely 0 knowledge about the packaging system (if you don't count knowing to emerge package as knowledge).

What is done properly in the portage system is the fact that there are some default classes which your ebuild can inherit to behave more like a certain type of packages (base - a generic recipe, gnome, kde, games, sourceforge - they download tarballs directly, if needed - ...)

Why this is not possible for deb right now? Simple, we have it as a rule in the policy that the debian/rules file is a makefile. So even if one would implement a class-like model for deb packages, you'd still have the debian/rules file as a make file...

Gentoo implemented initially portage's default behaviour (and as a consequence, the "classes") in shell, later they migrated some parts to python and the whole portage is implemented in python now (while classes are implemented in bash). I am not saying that we should put python in essential, God forbid, probably the emdebian guys would stab me :-), I am saying that possibilities exist, alternatives should be possible.

I know, some will just say "show me the code", "making such a change over the entire archive is insane" or "the makefile is a really good way to do things like installing and building, after all, that's what it was designed for". Yes, all of these will miss the point, which is having nothing-to-do as a default policy for a package is a bad policy, it should be an empty/default package will use a standard recipe to build itself, and that recipe should be implemented in the build system.


And if you still don't believe me, just look at these few ebuilds and tell me you'd not be able to write them after a quarter after seeing one the first time and skimming over the docs or/and knowing what a regular gentoo user knows (what a keyword is, what is a slot). Also compare with the debian counter parts and don't forget the different building aids that we have.

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/amphetamine/amphetamine-0.8.10.ebuild?view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/control?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/postinst?op=file&rev=0&sc=0

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/holotz-castle/holotz-castle-1.3.8.ebuild?rev=1.3&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/control?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/late/late-0.1.0.ebuild?rev=1.10&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postinst?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postrm?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/ppracer/ppracer-0.3.1.ebuild?rev=1.15&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/ppracer/debian/rules?op=file&rev=0&sc=0


One more thing, the ebuilds mostly need not be updated when an upstream release occurs, they just need to be copied and given a different filename.