OK, changes in dpkg-dev 1.14.7 have forced my hand a little and dpkg-cross 2.0.0 has now been uploaded to Debian unstable (not experimental).
apt-cross 0.2.9 has been uploaded to Emdebian unstable - dependent on
dpkg-cross >= 1.99
apt-cross 0.3.0 has been uploaded to Debian unstable but will spend some time in the NEW queue (hence the 0.2.9 upload to Emdebian). apt-cross 0.3.0 is functionally identical to 0.2.9
emdebian-tools 0.3.9 has been uploaded to Emdebian unstable - dependent on apt-cross >= 0.2.9 and dpkg-cross >= 1.99
All three comprise extensive rewrites. apt-cross, in particular, is barely recognisable. dpkg-cross is a shadow of the former package and v2.0.0 signals the beginning of the long goodbye to both packages. dpkg developers expect to be able to merge all dpkg-cross functionality into dpkg before Lenny. Once that is done, it should be trivial to merge apt-cross behaviour into apt.
Only the new libcache-apt-perl package (containing the modified NorthernCross code from virtuoso) will persist. Once this whole transition is over, I'll upload Cache::Apt::* to CPAN so that it can become its own source package in Debian once apt-cross is removed.

IMPORTANT
dpkg cross-building support is HIGHLY EXPERIMENTAL!
Significant changes are still pending, including remapping the build paths during the
dpkg-buildpackage build and utilising the updated dpkg-shlibdeps code which is a decade ahead of what we had in dpkg-cross 1.39.

1. dpkg 1.14.7 included dpkg-buildpackage as a perl script instead of shell which breaks dpkg-cross <= 1.39 but the new code to support dpkg-cross >= 1.99 is not implemented yet.


2. The breakage that Zumbi experienced when using the dpkg version from
   experimental will now occur in unstable.
   http://lists.debian.org/debian-embedded/2007/09/msg00067.html. Note that this breakage would be severity "critical" if filed as a bug because it prevents not only cross-builds but normal Debian builds.


3. dpkg-cross 2.0.0 fixes this issue. Hence the urgency in uploading dpkg-cross 2.0.0


4. dpkg-cross 2.0.0 removes the old diversions of dpkg-buildpackage and dpkg-shlibdeps.


5. dpkg is set to support the removal of the dpkg-cross diversions and code to support this is coming this weekend. This means that there will be a GAP where cross-built packages will fail to find the correct shared libraries. HOWEVER, installing dpkg-cross 2.0.0 restores the ability to build normal Debian packages whilst keeping dpkg-cross installed. This is a far more important gain than a temporary problem in packages that hardly anyone is using yet (our Emdebian crossbuilt packages).

When dpkg-dev 1.14.8 becomes available, apt-cross, dpkg-cross and emdebian-tools will be updated to depend on this version.

Everyone: please note - cross-building support in Debian will be "fragile" for the next week or so. The rewritten packages are being uploaded against experimental dpkg support I expect bugs.

The benefits of these changes are:

1. The removal of diversions that are a decade out of date.


2. The implementation of virtuoso's NorthernCross code that transforms apt-cross and fixes lots of awkward bugs.


3. The incorporation of cross-building support in the heart of dpkg.


4. The beginning of the long goodbye to dpkg-cross and apt-cross.

RESULTS
With the new packages installed, some packages will produce:

 emdebuild: ERROR /usr/bin/ contains files for the wrong architecture!

i.e. the build appears to succeed but until dpkg-dev 1.14.8 includes support for looking for the correct libraries in /usr/$arch/lib instead of /usr/lib, we get unusable packages. This at least means that packages can be test built and the patches updated.

Bruce Schneier has just written about the Storm Worm [1] which has apparently been quietly 0wning some Windows machines for most of this year (see the Wikipedia page for more information [2]). I have just been asked whether SE Linux would stop such a worm from the Linux environment. SE Linux does prevent many possible methods of getting local root. If a user who does not have the root password (or is not going to enter it from a user session) has their account taken over by a hostile party then the attacker is not going to get local root (unless there is a kernel vulnerability). Without local root access the activities of the attacker can be seen by a user logged in on another account - processes will be seen by all user sessions if using the SE Linux targeted policy and files and processes can be seen by the sys-admin. If while a user account is 0wned the user runs “su -” (or an equivalent command) then in theory at least the attacker can sniff this and gain local root access (whether enough users do this to make attackers feel that it’s worth their effort to write the code in question is something I couldn’t even guess about). If the user is clueless then the attacker could immediately display a dialog with some message that sound urgent and demand the root password - some users would give it. If the user is even moderately smart the attacker could fake the GUI dialogues for installing updated packages (which have been in Red Hat distributions for ages and have appeared in Debian more recently) and tell the user that they need to enter the root password to install an important security update (oh the irony). In conclusion I think that if a user is ill-educated enough to want to run a program that was sent to them in email by a random person then I expect that the program would have a good chance of coercing them into giving it local root access if the user in question had the capability of doing so. Even if a Linux trojan did not have local root access then it could still do a lot of damage. Any server operations that don’t require ports 1024 (which means most things other than running a web, DNS, or mail server) can still be performed and client access will always work (including sending email). The trojan would have access to all of the user's data (which for a corporate desktop machine usually means a huge network share of secret documents). If a trojan only attempts to perform actions that SE Linux permits (running programs from the user's home directory, accessing servers for DNS, HTTP, IRC, SMTP, and other protocols - a reasonable set of options for a trojan) then the default configuration of SE Linux (targeted policy) won't stop it or even log anything. This is not a problem with SE Linux, just a direct result of the fact that in every situation a trojan can perform all operations that the user can perform - and if the trojan only wants to receive commands via web and IRC servers and send spam via the user's regular mail server then it will be a small sub-set of the permitted operations for the user! If however the trojan tries more aggressive methods then SE Linux will log some AVC messages about access being denied. If the sys-admin has good procedures for analysing log files they will notice such things, understand what they mean, and be able to contain the damage. Also there have been at least two cases where SE Linux prevented local root exploits. Finally, in answer to the original question: SE Linux will stop some of the more aggressive methods that trojans might use. But there are still plenty of things that a trojan could do to cause harm which won't be stopped or audited by SE Linux policy. When Linux gets more market share among users with a small amount of skill and no competent person to do sys-admin work for them we will see some Linux trojans and more Linux worms. It will be interesting to see what methods the trojan authors decide to use.

• [1] http://www.schneier.com/blog/archives/2007/10/the_storm_worm.html


• [2] http://en.wikipedia.org/wiki/Storm_Worm

Share This

So the new NAS is happily running Debian now, and I'll write a long blog for anyone who wants to do the same once I have one remaining problem sorted out... Avahi doesn't work. If I start Avahi on the NAS other machines see the announcement and the names it provides will resolve, but after a few minutes they fail to resolve as they timeout. Unless my router is incredibly brain-dead it can't be the cause, because the old NAS is connected in exactly the same way and it works fine. For extra fun, the NAS can't see the rest of the mDNS network. It's almost like the network driver is dropping incoming multicast packets. Before anyone asks, there is no firewall running on the NAS. Does anyone have any ideas? NP: Remembranza, Murcof

Somewhat unbelievably (to me at least) there is still wireless in my mother’s backyard and it has only gotten better and stronger. But let’s face it, writing in garden lounge chairs among the frogs, birds, sun, rain and wind are sub-optimum for thinking and writing, so I am always looking for good and, most especially, gratis wireless. I was pretty psyched to find a new cafe, Camilles Cafe that had decent looking food and proudly advertises Free WiFi. So I went there this afternoon, ordered my cafe con leche, sat down, and ran dhlcient to get my IP address and it served me one in a jiffy. I opened my xchat, said hello to my fellow chatters, and then proceeded to login to my email and I never got further than that because they disabled access to any page that requires a password. I went up to the counter to ask why and the answer I got was “porque un hacker nos ataco.” It is totally retarded that the can’t reenable whatever they turned off after adding some basic security measures. They are losing tons and mean tons of business. One quick visit to the “other” cafe down the street with free wireless Me. Starbucks shows there is much business to be made if you provide free wireless. It is Sunday and there are 12 people here with computers and people of all stripes and backgrounds and they come because the wireless is cheap and fast. Be warned: logging on to the wireless here is totally non-obvious. When you try to log in, you are routed to a corporate Centennial web page that asks for an user-id/password or asks you to create one. So you of course think that it will cost money to do so. But in fact you just create a name, password etc. and then the site never asks you for mullah (nice). There is no sign, instructions, giving you these instructions. You gotta know or you gotta ask one of your neighbors. This odd system has been in place for years and I just wonder when the only free wireless in a coffee shop (at least that I know of) will be snatched away. Hopefully never and hopefully someone else will get the bright idea that if they open another coffee shop and also provide free wireless, they will make a killing. This place is always always, and I mean always, packed. p.s.: make sure to bring headphones/music too unless you are great at working with plently of background noise, which includes the usual starbucks music (about as good as its coffee, not), people chatting, people video-chatting sans headphones, and people watching shows like South Park. It is downright cacophonous..

At Debconf, we (the i18n crowd) discussed about the NMU campaign we ran before the release of Etch (roughly from September 2006 to March 2007). We concluded that running a campaign slightly earlier in the release process would be likely to save us some work. Indeed, experience shows that the initial pings sent to maintainers often trigger uploads to fix the pending l10n issues. So, let's start thinking about it now. For those who don't remember, the rough process is described here. As one sees, it is deeply respectful for maintainers and takes great care to avoid unwanted NMUs. So, to begin, please check the list of the pending po-debconf l10n issues ranked by...a pretty complicated mathematical formula which aims to put packages which would most benefit from an upload in first position... In case one of your packages is listed near the top of that list, just consider uploading it soon. PS: of course, the mathematical formula includes a secret pondering scheme aimed at giving French translations more weight, as anyone would have guessed.

The guys at Free Software Magazine just published a Hecl tutorial that I wrote. They're a pretty good outfit - you won't get rich, but since the article is under a free license, I'll be able to integrate it with the Hecl documentation pretty quickly, which was more important to me than a few dollars here or there.

Back around 1999, I was really interested in getting all of Debian imported into CVS (ugh!) so we could have all the benefits of pervasive version control. I've always been sad it didn't happen, especially since ubuntu did it. Although they seem to get less benefits from it than I would have thought at the time, go figure. I actually feel though that the model Debian has developed with alioth and now with VCS- fields, in which packages use version control, and debian integrates support for it without mandating it, or mandating which version control system is used, is has better legs than ubuntu's model. Ubuntu's model potentially leaves you where freebsd is now, nursing a cvs equivilant along as the world has moved on. Except, well, Debian actually picked a different version control system, and has been stuck with it for years. I refer to the diff, which is great for passing patches around by email, but not so great as a mechanism for recording the history of changes needed to debianise a package. So we have this whole set of things piled on top of the diff, like the loathsome dbs. We also have this whole set of problems in the source package format that cannot be expressed by diff and have to be messily worked around, like not being able to add/modify binary files, and not being able to (re)move files. (Wig and Pen addresses some of the worst limitations of the current format, but AFAIK noone is working on implementing support for generating Wig and Pen format packages, since doing so is unavoidably complicated.) Once I started looking at the diff in .diff.gz as a version control system, the natural thing was to think about adding support to other revision control systems, following down our path of debian supporting maintainers who choose to use a different one. So I arrived at the idea of a .git.tar.gz. Let a debian source package consist of just a .dsc and package_version.git.tar.gz, which contains only package/.git/*. Making changes to the source becomes very pleasant, since you can commit any change you like and not have to worry about how it will be repesented in the .diff.gz. And of course there's all kinds of benefits of having the history and branches and tagged upstream source available in there. Far too many benefits to list here, and only a few downsides. I look at this as very much of an evolutionary change, not a revolutionary change, to the debian source format. Most packages will continue to use .diff.gz for a long while, but packages whose maintainers chafe under that format will have another one to choose from. So, well, I implemented it. A dpkg-source that understands this format is available in the sourcev3 branch at git://kitenet.net/dpkg. I'll be posting some technical details and the patches to debian-dpkg, and I've put a FAQ about it in the wiki. A sample dpkg source package built using this is temporarily here. This demo package includes only the last 200 commits to the dpkg git repo, so it's more than 1 mb smaller than dpkg's normal .tar.gz!

After 6 weeks of teaching and over 2 months in my new apartment, I am making a short escape from NYC to visit my mom and sister in PR. In my Impacts of Technology class, we just finished a week on large-scale and complex technological systems, with a focus on industrial farming. We read a few sections of Micahel Pollan’s fanstastic book, The Ominvore’s Dilemma, which combines the odd qualities of being seductively alluring (thanks to his exquisite writing) and repulsive (thanks to the content, well at least the part on factory animal “farming”). I can’t recommend it enough and look forward to reading the rest, when I find the (magical) time to do so. Now that I am at the airport, I am struck at how little I know about this place, which is also a large and complex technological system and I bet revealing its technological and cultural innards would provide as fascinating (although not quite as gross) of a story as that of factory animal farming. There are many questions I would love answered: How exactly is coordination secured and what are the toughest elements to airport coordination? Where are the lines of cooperation and those of competition between airlines? What factors and values go into the design of the airport? (I know that for one thing, in American airports, there rarely seems to be enough electrical jacks; I am now sitting under the telephones, the only place with jacks in terminal 8 at JFK, and the funny thing is that there are a row of 7 unused phones and only one jack and I am sure it would be more useful to have 1 pay phone and a row of 7 jacks, instead). What sorts of airport technologies have put people out of jobs? What technologies have created new job opportunities? What sorts of social hierarchies are there in airports? Like who runs the big show? Is it a CEO? Or is something more like a university provost? What is standardized by the FAA, and what elements are more flexible, and thus different airport to airport? Is there a sense of camaraderie among airport employees, or are loyalties built primarily among employees of one airline or among the classes of workers? Given that unions are quite strong among airport employees and from the top (pilots) down (food workers), what is the political culture of airports/employees like? (I remember once overhearing a group of machinist and ground crew talking about the ugly face of globalization and NAFTA over coffee and I was dumbfounded and pretty psyched too). Are airports one of the few last remaining places in th US that provides for decent job security? Why do so many of the ground crew have such athletic, bulging calves? Is it a result of the physical demands of the job? Or is it that the type of job ( outdoors with lots of heavy lifting), attract the athletic types? Do they have to pass certain physical standards as to pilots? Was there always first class seats? Or did that come about when flying became cheaper? Are employees trained to deal with irate passengers? In what ways do pilots bitch about the long waits/delays they also have to endure? What can they do when they are waiting, as we did for an hour last night, during the massive traffic jams that are especially noxious in NYC-area airports? Do pilots have any say in the way airports are run? Why do they consistently provide less chairs than are needed in lounges, even in new terminals, as the one I was in tonight? Do air traffic controllers ever meet face-to-face with pilots or do they largely have a virtual relationship? Are programmers who patch, improve, and build traffic control systems housed in the airports, or elsewhere? Airports are not only fascinating for technological and sociological reasons but I reckon there is a lot of interesting psychological work that must happen in airports. I imagine that during those long, endless waits in the lounge, on the security lines, on the tarmac, people must often take the time to reflect, on where am I going, where am I coming from, and not in the literal sense but the metaphorical one. I know that I have spent many hours in airports letting my mind wander to places and thoughts in ways that don’t happen as easily or often elsewhere. And in many instances, I don’t think that this propensity to indulge in some reflective thinking, is a matter of time, that is waiting. For me at least, it is the fact that many times when I fly, I am moving between worlds. While I have flown hundreds of times, I never have been shed of the sense of awe I feel about planes and their ability to shrink space and time so quickly. For me, it is less the act of flying itself (that feels boring, tiring, annoying, mostly because of the insane waits and delays and I never seem to get the right amount of sleep the night before) but the visceral contrast it brings. In the morning my life is of a particular tone and rhythm, currently situated in NYC and by evening, I am back at home in PR, surrounded by thick humidity and the loud sound of coquis. Once there, my as currently configured in NYC, has little direct bearing to those around me. Planes don’t just transport, they shift and convert your inner and outer world… So, if anyone (who got this far) knows of a good social history of the airport, do tell. I would love to read it.

The following companies, or people, are using xen-shell with their Xen hosting product(s):

• xen kibbutz
• xen hosting (me!)
• bit folk
• Datarealm internet services
• Chris Lamb
• Cernio

I'm sure there are more, but I've been lax at keeping track. I do want a list, if only for advertising purposes. I'll update the list here if/when people point out omissions. In other news yesterday I managed to release security updates for KDM & fetchmail which were missing i386 builds. Not good. The problem was fixed fairly quickly once it was actually noticed, with the help of Noah. But I did get several angry emails during the wait. *sigh* It looks like people are starting the notice the downside to having broken security buildd machines which frequently cause these kind of problems for us - so hopefully these kind of errors will diminish in time. (Who am I kidding?)

Via Anomaly Television: The video "This Fortean Island" is a seemingly random mixture of "cultism, death, UFOs, Bohemian Grove, Illuminati, Skull & Bones, Freemasonry, and necrophilia", with Discordianism being the connecting element. You can watch it on Google Video or get it as an AVI.

I’ve recently spent some time on Facebook, primarily out of professional interest (all the cool attorneys are doing it). (I’m also on LinkedIn, but that seems less cool.) Among other odd results, I’ve been getting lots of friend requests from people I’ve had no contact with in ten — and sometimes twenty or more — years. I’m surprised by this because I’ve always been so easy to find. I started my first “home page” in 1994, and as long as the idea of search engine rankings has existed, I’ve been at the top in searches for my name. I’ve also never made any attempt to hide my email address, and retained all addresses for nearly 15 years. Yet, people contact me on Facebook who never before did. I have two nonexclusive theories:

• Facebook just induces more searching for old friends than “the web at large.”
• Facebook allows you to reconnect with people for a minimum activation energy. You don’t have to write them an email, tell them about your life, or engage in conversation. You just click “add to friends” and you’re done. Maybe these people had found me in the past but just didn’t bother to let me know. In fact, in the case of some of these people with whom I haven’t communicated since middle school, I still haven’t communicated with them. We’re just Facebook friends.

Other ideas? I should add that I have made some genuine connections through Facebook as well. Earlier this week, I met a college friend (whose website promises to return to service soon) for dinner whom I hadn’t seen in nearly ten years. I found out he was in town through Facebook.

Share This

Thanks to Faidon Liambotis, pristine-tar has been extended to support recreating pristine gz files, as well as tar files. It's been tested against the entire corpus of .tar.gz files in the debian archive, and succeeds on 98.7% of them. We're using the whole archive as a test suite for pristine-tar, which is such a nice change -- excellent test coverange, and no need to write tests. :-) I've put up all the deltas it generated during its most recent run at http://hydra.kitenet.net/~joey/tmp/tar/. The deltas for all the tarballs in the archive use only 175 mb of space. The next step, once it gets out of incoming will be for tools that inject sources into revision control to get support for generating pristine-tar deltas and checking the deltas in too. And for tools that build packages from revision control to get support for using the deltas to reproduce the original tarball. If you maintain such a tool, I'm happy to help you do that. how pristine-gz works Recreating gz files is tricky, since you generally can't binary diff them as pristine-tar does with tar files. Instead, gzip has to be fed exactly the same conditions that applied when the original gz file was created. This includes time stamps, filenames, file content, and compression level. These are figured out by looking at the header of the gz file. But that's only the easy part, because there's a lot of variation in gz creation programs. The debian archive contains gz files produced on BSD systems by a libz based compressor, other built on MS-DOS, Windows NT, and many other strange and often buggy things. All of these differences result in different gz files. To deal with this, pristine-gz uses a gz creator that can reproduce any of the known variants on demand, and just tries different varients until it finds a match. There are still 132 files that it fails to reproduce, so if this sounds interesting to you, you can try to figure out how they were created and add support for them. It would be possible to make pristine-gz succeed even for gz files it can't reproduce. It could just generate xdeltas to the files it tries, and store the smallest one. I am undecided if that would be a good idea, since the delta wouldn't be very small.

---

Some days ago I started using knode and becoming familiar with nntp.

Since ispCP's lists are hosted at Google Groups I just wanted to subscribe to all the newsgroups using knode. But what a shame... I can only subscribe to Google Groups either by email or by RSS/Atom Feeds :(

At the time of writting I'm filling up the "Subscribe A Mailing List" form at gmane.org.

I actually tough Google would not fall on that 'only from http' tradition it has... but, it indeed did.

For the last month, I’ve been running a non-profit Xen server for a few friends. It’s been working really well but I’ve got three two one no slot left. I think it’s quite good value: £7.88 per month (£17.73 setup) gives you:

• 440Mb RAM
• 15Gb SATA RAID-1 disk space
• Very-low contention Athlon64 X2 4400 CPU
• Fast, London-based bandwidth (provided by Bytemark)
• IPv4 IP address (IPv6 also available)
• Custom reverse DNS
• Backup mail relay
• Choice of distros, Xen-shell remote admin, etc.

If you’re interested, please drop in on #lamby-xen on OFTC. UPDATE: All gone. Thanks for the huge interest.

I love Susan Sontag for her crisp and biting writings. I like that she takes risks and in the process takes you for a ride through her beautiful imagery. I just finished reading Illness and Metaphor and think that her opening is probably one of my all-time favorites

Illness is the night-side of life, a more onerious citizenship. Everyone who is born hold dual citizenship, in the kingdom of the well and in the kingdom of the sick. Although we all prefer to use only the good passport, sooner or later each of us is obliged, at least for a spell, to identify ourselves citizens of that other place. I want to describe, not what it is really like to emigrate to the kingdom of the ill and live there, but the punitive or sentimental concocted about that situation: not real geography, but stereotypes of national character.

Adrian (also sent by email):
Re: 2038 issues on mobile platforms.

It is possible to handle 64bit time on 32bit systems. I got disillusioned with the libglib2.0-0 support (GDate) and I already had a library capable of 64bit mathematics (libqof1) so I wrote QofDate and QofTime that can handle true 64bit date and time calculations, formatting and scanning on 32bit or 64bit installations. I estimate that this gives us enough capacity to handle time for a couple of dozen times the age of the universe to nanosecond precision. The maths can also go backwards as far as it can go forwards so it could handle the date of the Big Bang with nanosecond precision too - if anybody actually works that out.

I'll be using this library in Emdebian to provide support for 64bit maths for gpe-expenses and the pre-alpha gpe-cash (stripped out gnucash for embedded devices) so at least your financial records will be safe.
http://cashutil.sourceforge.net/gpecash.php
http://gpe-expenses.sourceforge.net/

"QofTime is a lot like the unix 'struct timespec' except that it uses a
64-bit signed int to store the seconds. This should adequately cover
dates in the distant future as well as the distant past, as long as
these are not more than a couple of dozen times the age of the
universe. Values of this type can range from -9,223,372,036,854,775,808
to 9,223,372,036,854,775,807."

http://qof.sourceforge.net/doxy/group__QOFTIME.html#gb93e930907d0e2eba07b1fa7496e7822
http://qof.sourceforge.net/doxy/group__QOFTIME.html

QofTime is defined as 64bit on all systems and will not overflow until
the year 292,471,208,679 (not counting leap years). i.e. approx.
9223372036854775808 / (60*60*24*365). This also means that some values
of QofTime cannot be converted to a time_t on systems where time_t is
defined as 32bit.

http://qof.sourceforge.net/doxy/group__Date.html

A QofDate is theoretically able to go forward to the year
292,471,206,707 AD and back to the year 292,471,206,708 BC. Whether
such dates actually exist is outside the scope of this documentation.

http://packages.debian.org/sid/libqof-doc
http://packages.debian.org/sid/libqof1

The German train drivers are going on strike again on Friday, asking for 30% more money. So far, they've been offered 4% and two extra hours of work per week. At least DB had the decency not to sink millions of Euros into an advertising campaign denouncing the union's demands as unreasonable. Which they aren't.

Recently I was talking to an employee at Safeway (an Australian supermarket chain) about Linux etc. He seemed interested in attending a meeting of my local LUG (which incidentally happens on the campus of the university where he studies). I have had a few conversations like that and it seems that it would be good to have some LUG business-cards. It shouldn’t be difficult to make something that is similar in concept to the Debian business cards [1] for use by a Linux Users Group (LUG). That way when you tell someone about Linux you can hand them a card that has your name and email address along with the web site for your local LUG. In other news I will be attending a meeting of the Linux Users of Victoria (LUV) [2] this evening and will have some Fair Trade Chocolate [3] to give away to people who arrive early. The chocolate in question is now sold by Safeway for a mere $4 per 100g (not much more expensive than the regular chocolate).

• [1] http://www.debian.org/events/materials/business-cards/


• [2] http://www.luv.asn.au/


• [3] http://etbe.coker.com.au/2006/08/23/fair-trade-is-the-linux-way/

Share This

In the last few days we (as in DebConf admins Steve Gran, Mark Hymers and myself) have been doing some DebConf maintenance work. Some time ago one of DebConf’s permanent sponsors, ByteMark sponsored a new machine, krabappel, which we use as a replacement for the older machine we have from them, cmburns. It was neccessary, as good old cmburns had a lot of stuff running and so was always pretty loaded. Imagine it running most of our websites, main mail and dns server and then also having 4 vserver instances on it. Those vserver itself where also running things that do use some resources, like our wiki and the main DebConf7 site, the PentaBarf test-host and our LedgerSMB instance. While it was long decided to move stuff our - we just had to find time to do it. This weekend seems to be it, everything is migrated except cmburns itself, as that needs a fix in the reverse dns entries for the new /28 we got. We are using xen-tools to make installation of new images easy. For that I wrote a script that is used as a role script, automating all that various setup tasks that one can automate easily. Which means that it takes about 5 minutes to get a complete new XEN domain up and running. (Add some minutes to add it to nagios2, munin, our mail setup and to sync the userdatabase.) Mark and Steve also did another migration: gallery.debconf.org is now using gallery2. Still needs a nice layout designed looking similar to our normal DebConf website, but that shouldn’t be too hard to get. While they have been on it they also integrated gallery.debian.net, so that it is back up again. Feel free to use both of them! gallery.debconf.org offers space for all DebConf related pictures, be it the main yearly DebConf (and related) or regional DebConfs, like the one planned for Panama soon. gallery.debian.net is a place where pictures from all Debian related events/parties/whatever can be put. Basically - whenever people working on Debian meet (like a BSP, a work meeting, etc) - feel free to put pictures up there. Just put them into a folder matching the year it happened in… Basic goal is to get a huge set of pictures from people involved in Debian.

Scott, I would have expected a little more from you than your previous post on why you chose bazaar! Update: my initial post was offensive towards Scott, so I edited it a little, following a good discussion with Scott via Email. Even though his post didn't make it explicit, his post was meant to be a reaction to someone else praising Git above everything else. Or, in his words:

You're responding with a defence of git because I posted a defence of bzr in response to championing of git.

I decided to leave most of the original post untouched, nevertheless, but please read it in this context. I guess the sensible conclusion is (as always): to each their own. Inline updates are enclosed in [brackets].

---

Git is less of a version control system than it is a filesystem and a means to communicate among developers, and when used in that sense, it's extremely powerful and intuitive to use. And it is also a version control system, like Bazaar. It's blazing speed isn't the only killer feature. By no means, however, is it "heavily optimised for the 'I only apply patches' development model, at the expense of ordinary development models" [anymore]. It also supports centralised workflows just as well as it supports distributed approaches, and you can switch between them [this is not really true when compared to how Bazaar mimiques CVS/SVN behaviour; Git cannot do that]. Here are the git commands needed to do the same things Scott showed off in your post:

$ cd myproject
$ git init
$ editor .gitignore
$ git add .    # git rm ...

Let's branch before we commit. checkout -b is a shortcut to create a branch (git branch myproject-foo) and immediately switch to it (git checkout myproject-foo):

$ git checkout -b myproject-foo
$ git commit

Git keeps all branches within the same repository and lets you switch between them. Now, that is a killer feature: whether I'm versioning code or stuff like webpages, I often have external pointers to my code. For instance, I may have libfoo as a sibling of foo-ng and the latter refers to libfoo in the Makefile. If I wanted to try a new approach in libfoo, I'd have to change foo-ng's Makefile to point to libfoo-newbranch instead, or juggle directories around. That sucks. With git, I just checkout a different branch in the same space:

$ git checkout master

And even better: if you don't like it, you could just as well copy the repository to create a separate (remote) branch from which you can later pull or cherry-pick changes to the main branch:

$ git remote add foo ../myproject-foo
$ git fetch foo
$ git merge foo/master

Now back to your steps, and I'll stick to the git way of branching. Note how git does not differentiate between pulling and merging in the sense that you do. If there are no local modifications, git just fast-forwards the branch with the commits on the master:

$ git merge myproject-foo

Even better, say you don't want the last two commits:

$ git merge myproject-foo~2

Unless git can fast-forward, it also treats a merge as a single commit and the ancestry information allows you to inspect its component commits just like you would. gitk is another killer feature, which I believe bazaar copied from git, just like the bazaar folks adopted the concept of rebasing, which basically lets you rewrite history quite freely, another killer feature (which can be quite badly abused if you don't know what you're doing). And then there is git bisect and git-svn and git filter-branch and git describe and git stash and gitweb and, and, and So if I compare the git commands I used to the way you used bazaar, I fail to see much of a difference. Do you? It is true that git comes with an astounding number of additional commands, most of which you never have to use, but which are available to the user [but its interface is a huge improvement over GNU arch, nevertheless, and if only because the commands are named more logically and revisions and branches do not have to adhere to one of the strangest syntaxes ever]. I don't deny that their sheer abundance is overwhelming and confusing at first (a general rule for Git for beginners seems to be just to ignore ever command with a hyphen in it). But once you get out of the newbie stage (it took me about two weeks, the duration of Debconf7 to become an acquainted git user; in fact, David Nusinow placed me among the ranks of real git wizards Pierre and Keith before the conference was over) arghs, I hate long remarks in parenthesis; once you leave the newbie stage, you'll appreciate all these commands, which make it really easy to script complex tools with git, making any plugin architecture pretty obsolete. Finally, I found myself trusting git way more than any other version control system I've tried simply because it's so transparent and you are allowed to edit stuff under .git, which is mostly plan text files (and objects, which you [could but] don't have to touch). It's transparent, and it stays true to the Unix way of letting small tools do their jobs instead of the monolithic approach. NP: Enchant: Tug of War Update: Carl Worth has a similar beef with people thinking that Git is too complicated and has ported a chapter from a book on Mercurial to Git to show how that's not the case. It's a good read. Update: Scott replied (quoted with permission), and I include my replies inline:

"I can tell you why you chose bazaar: because you had to, because you are being paid to use it."

Sorry, that just isn't true. I'm paid to lead the Ubuntu Desktop Team; this has nothing to do with version control, except that the various upstreams and packages use different systems.

I am sorry about this accusation. It was low.

You appear to miss my point about Git, or maybe I didn't make it strong enough. It's not that I don't understand it; it's that I had to take time and effort to understand it. And I've noticed that every reply to my post misses out the fact that with Git, you have to take action to ensure your changes are actually incorporated into the commit; either with git add or commit -a. This exactly the kind of anti-social behaviour that I have issues with.

Well, Git people call this a feature and it is very handy, but I see your point. There is no way to configure git-commit to always include -a, so you'll have to work around it:

git config alias.ci 'commit -a'

This creates git ci to do exactly what you want. You cannot overwrite commit that way though. But it could be trivial to add a configuration option to git-commit, if you think that the way that Git exposes the index is an adoption-stopper:

$ file -L =git-commit
/usr/local/bin/git-commit: POSIX shell script text executable

Your post also introduces yet more over-complication by demonstrating about making a branch (in an empty branch) before you commit.

Your post does the same ("A common operation is realising that the commit you re about to make should really go on a new branch for now"), which is why I did it. You don't have to do that at all.

(Side-bar: bzr's design also permits multiple branches within the same repository.)

So I read the manpage and found bzr init-repository, but no way to add a branch to an existing clone, and also no way to switch between branches within a clone. In your original post, you claimed: " Bazaar s command set works the way you do." Well, the way I work is by "switching" between or "checking out" a new branch in-place, but I could not trivially find the command to do this. This is probably because I have not invested enough time into understanding Bazaar, but isn't that what your claim is all about: that "[you] had to take time and effort to understand [Git]" and that Bazaar just works for you?

My post was why I choose bazaar, and why I have rejected other revision control systems that I have attempted to use.

So why did you post it? Surely because you wanted to express your preference over Git. In doing so, you made a couple of claims about Git which are simply untrue, which is why I replied. And the reason I replied is simply because other people who try to make a choice between Git and Bazaar may find your post and take away from it the information that Bazaar is superior to Git, which it is not.

I'm glad that you prefer a different system; but please don't insult me by suggesting that I'm being paid to use the one I prefer, or that I haven't bothered to learn one I'm "slagging off".

But you did slag Git in that you basically present its shortcomings side-by-side to Bazaar's greatness, which is a common PR/marketing thing to do. So just like I failed to create an in-place branch above because I did not bother to learn Bazaar, you did not bother to learn how to do with Git what you showed off with Bazaar, or else I'll have to assume you would not have written up the comparison as you did.

I have to use git as much as I use bzr, and I simply prefer bzr.

That was not the message I took from your original post.