The key to productivity is avoiding other work. The weekend has just started, and I've successfully hooked up a JTAG probe to a Linux box and implemented half of debian/xcontrol stuff. xcontrol is a preprocessor for control files that accepts an extended syntax and compiles that into a policy compliant debian/control file, losing bits of information on the way (but whoever cares can just look into the xcontrol file). For now, I am planning to support the following extensions:

Build-Depends-Tool:

An additional build dependency line useful in cross compiling packages. The normal “Build-Depends” is reinterpreted as packages required for the target architecture, while this line specifies packages required on the host during the build.

Build-Depends[release]:

This overrides the build dependencies for a certain release, and comes in handy when backporting. Of course, this is orthogonal, so -Indep and -Tool fields exist too.

Optional: yes

This package is not normally built; if you need it, you have to invoke the “build-package” and “binary-package” targets.

per-package Build-Depends*:

This allows specifying the build dependencies for “Optional: yes” packages without adding them to the main list.

The syntax is still debateable at this point. The non-orthogonality of Build-Depends-Tool is intended, by the way. :-) The transformations done to make this policy compliant should be obvious: Build-Depends-Tool is folded into Build-Depends, the release-specific Build-Depends are omitted (or selected if xcontrol is told to target a specific release), Optional is stripped out and the per-package build dependencies for all non-Optional packages are accumulated. I don't know whether I'm going to do templates yet, this will probably wait until the second release. More on the JTAG adapter when I have the gdb stub working. Now I'm going to go back to what I should really be doing.

So, let’s join the postings about the currently running Debian maintainers GR. The short text of this post is I am against the proposal as it is right now and think it does more harm than good and so I did vote for Further Discussion. See below for a bit more about my reasoning, or just skip if you are already bored. :) The current proposal does look like a “yay, we have an idea thats not really thought through. And we do not want to get it into the currently existing procedures, that would involve more work and discussions. And anyway, everyone is ranting about the current procedures anyway, so lets take that bad mood against it to get this done”. (And yes, this is a bit exaggerated, so don’t take it personal, please). As you may have noticed I wrote that I am against the current proposal when it first was on vote. I was mostly on vacation back then and didnt want to read the whole thread, so I stayed mostly quiet. I am not against the DM concept itself. I am against it being seperate to the existing NM procedure. For me a proper solution has to be integrated with the existing procedures, not seperated. The main reasons why some support this proposal seem to be

1. Slow NM process.
2. Someone doesn’t want to go through NM
3. Someone doesn’t want to be in the Debian community

---

Slow NM process I am part of this, and not a small one. And yes, I feel (very) bad about it, but already think about ways this can be changed, after I got the current backlog done. Anyway, for this DM thing my backlog isn’t the main reason that people feel NM is slow. It seems to be the general “I have to wait for an application manager and then answer to a lot of questions and between that wait and wait and wait”.

---

True. People have to wait at some points, and those waiting periods can be frustrating. We should do our best to eliminate those waiting places. The other point is that of the lot of questions. Yes, we have a really big set of questions in the templates, that cover a whole lot of the possibly areas a future Developer can work in. And most of those questions got added after a large set of existing Developers showed that they completly do not know something. That way the templates are constantly growing and still intend to give the future Developers the possibility to learn about things in Debian they might never have heard about. And there is the thought that, if you read about a topic and had to answer to it in the past, you will at least remember that there is something if you encounter it in the future. But - there is also the fact that an AM is NOT forced to use the templates for their process. AMs are, and have always been, free to do the process on their own. There are some questions every AM has to ask, but thats a minority. If you look at the templates you will spot the needed ones easily. Other than those every AM can freely do whatever he wants to do with his applicant (as long as the applicant agrees to do that stuff and its legal :) ). The AM only has to keep the following in mind: Both, FrontDesk and DAM, usually do not work together with the applicant. They might have heard the applicants name at some point, in some bugreport or some packages Maintainer: field. But they usually did not interact with them. Which means that the AM has to make sure that FD and DAM are able to build up their opinion of the applicant just by reading the mailbox of the AM->NM communication. Which usually means: read between 20 - 70 mails of a communication someone else had before you decide if someone should or should not enter Debian. (Leaving alone checking packages.qa, lintian, bug lists and a bit of google).

---

Someone doesn’t want to go through NM Erm. Well. Then use sponsors for your packages. Or is it because you think NM is too hard? NM isn’t that hard, everyone that can read and write english texts (even if the english is bad) and use google is able to pass NM. (For the bad english - if you fear joining NM because of that: Well. If I go and reread my own report from back when I joined - ugh. I hate my english. And I know native people still hate my english texts, its named en_GANNEFF for a reason. :) It is not necessary for your English to be perfect; you only have to be able to make yourself understood. If an AM doesn’t understand what you wrote they can simply ask for clarification). DM also doesn’t help for people that don’t want to pass NM. They have to pass the advocate, the ID check and the same minimum set of of questions NMs have (as written a bit above). So you already have a large part of NM for the future DMs.

---

Someone doesn’t want to be in the Debian community Then they shouldn’t be able to upload on their own. They can use sponsors. After all the only thing you must do as a DD is to read debian-devel-announce. And thats something a DM also must do, or you can’t seriously consider to package anything. And then DD only adds rights for you, like taking part in votes and so expressing your opinion and getting things changed in Debian that you may not like.

---

How to integrate a concept of DM then? First - by starting in the right area - getting it into the NM system by talking to all those involved. There is FrontDesk, DAM and also the NM-Committee, the latter should be the right point for a proposal and discussion. What I can imagine that would work and do something good is a system integrated into NM that gives future Developers upload privileges after they passed a few steps with their AM. That way they can upload early in the process, which can then be part of the T&S set, and the following steps in their NM process “just” slowly add more rights to the NM until its the set of rights every DD has. Seen from the current layout of the process it would be somewhere after the ID check and the first set of P&P, ie. at the time the AM sends the second P&P part. After that point the AM could recommend to those maintaining the DM list that the applicant should be added to it, together with a list of packages where the applicant is allowed to upload them. The maintainers of that DM list could be FrontDesk + DAM + maybe someone else, but thats something to discuss. And list of packages - while one could take the current limits the GR wants to set or simply a plain list, that can be amended during the time someone is a DM. Now, one can add a turnoff for people that do not want to pass through the rest of the process at this place. Im not sure its such a good idea, but thats something one can discuss. But if so it should be attached to some rules like - must read our debian-devel-announce list, is included in regular pings of activity similar to the wat ping.

I have recently been using virt-install on CentOS 5 to install some virtual machines (I previously posted a summary of the experience). One problem I had is the inability to do an install of Fedora to /dev/hda - it insisted on partitioning the disk and installing it on a partition. I have filed Red Hat Bugzilla #249837 about this problem. # n=1
# while true ; do dd if=/dev/vg0/orig of=/dev/vg0/dest bs=512 skip=$n count=1000 ; echo $n ; file -sL /dev/vg0/dest ; n=$(($n+1)) ; done After doing a CentOS or Fedora install I then have to fix things so that my desired option (of using a single unpartitioned virtual disk) is used. To do this I first needed to determine how many sectors at the start of the filesystem were used for the partition table. I used the above shell commands to test skipping different numbers of sectors and using file -sL to determine whether the result was recognised as an Ext2/3 filesystem. Below is part of the output: 62
/dev/vg0/dest: data
1000+0 records in
1000+0 records out
512000 bytes (512 kB) copied, 0.018812 seconds, 27.2 MB/s
63
/dev/vg0/dest: Linux rev 1.0 ext3 filesystem data (large files)
1000+0 records in
1000+0 records out
512000 bytes (512 kB) copied, 0.115528 seconds, 4.4 MB/s
64
/dev/vg0/dest: data
1000+0 records in
1000+0 records out
512000 bytes (512 kB) copied, 0.018623 seconds, 27.5 MB/s As you can see 63 sectors are used for the partition table and other boot blocks at the start of the disk. So I used the below command to fix it:
dd if=/dev/vg0/orig of=/dev/vg0/dest bs=512 skip=63 The next problem after this was booting. The pygrub program that is used by the CentOS Xen installation to boot DomU’s only works with partitioned block devices. This however is quite easy to solve, I merely had to copy the kernel and initrd from the Xen image to the Dom0 filesystem and use the files for booting. Of course every time I upgrade the kernel I will need to copy the files, but that’s not such a great inconvenience. I usually end up running multiple DomU’s with the same distribution so I can copy the kernel and initrd once and use it for all instances.

Share This

Since about two days I’m proud owner of a Lenovo X61s notebook. It will become my main and new developer box for grml, featuring all that nifty stuff like 64bit support, hardware virtualization and so on… I managed to use all the important features with a very current version of grml. I’m using kernel 2.6.22-grml on a setup with LVM, cryptsetup-luks,… everything works fine so far (including Suspend-To-RAM - even in grml live-mode when booting from USB pen - thanks for the excellent hibernate package, madduck!). As you won’t find useful and approriate information about Linux on the X61s yet (either pretty incomplete or wrong) I decided to put all relevant information on a webpage in the grml-wiki:

• Lenovo Thinkpad X61s @ grml-wiki

Short version: the X61s rocks. I’ll provide information to thinkwiki as soon I checked out all the details…

Fudge Update

Yesterday I blogged about the guy handing out fudge. He saw my post and explained why he was doing it. Today he was around handing out fudge, and I thanked him for his comment. He gave me two pieces of fudge for blogging about it.

Pineapple

At most of the breaks, they have this truly wonderful real (non-canned) pineapple. I think I have eaten more pineapple this week than any other week, ever. Very insidious, O'Reilly.

Conference materials

Slides of talks are available. Apparently keynotes are being posted on Youtube and Google Video, though they haven't provided a specific link AFAICT.

Philip Rosedale, Founder/CEO of Linden Lab

Second Life and the XPrize are two examples of escapism: you can escape to virtual earth, or escape the planet entirely.

In order for Second Life to grow, it has to become profoundly open. It has to be a standardized protocol. They are working on code to let people run their own servers. They are trying to make the server trusted and make it able to be open sourced as well. They see openness as the key way for it to grow.

If you are writing a web app that depends on the network effect -- such as Facebook -- you should open source everything right from the beginning. Not because it's best for humanity, but because you will win.

Jimmy Wales

He's trying to do open source search. Nice idea, could have been summarized in 45 seconds, I think.

Simon Wardli

Was going to talk about Zimki, which was going to open sourced, but they decided not to.

Funny and interesting talk, I sorta forgot to take notes while listening...

Nat Torkington

OSCon program chair.

Funny talk about Linux, an adolescent at 16 years old. Thinking about different languages and how they're doing. How the Linux community is organized: are we fighting battles, and do we need to?

James Larsson

This guy takes old hardware and makes insane devices out of it. 15,000 volts running over a coat hanger used as a "game controller", for instance.

In all, awesome keynotes today.

Matthew Garrett

A lot of background on the state of laptop support in Linux. It worked reasonably well in the 90s, but with the migration to ACPI, has become much more complicated and less reliable in general, especially with suspend/resume and video.

Emporer Linux and System 76 produce Linux supported laptops.

I wanted some more in-depth technical information and found Matthew later on at the Intel booth. Here's what I learned:

s2ram is little more than a wrapper around standard ACPI sleep that has options to do video mode save/restore

I asked him about all the many, many different userland laptop management tools. He recommends simple acpi-utils with the ondemand governor. laptop-mode-tools tries to do way too much, and there is little point to using a userland governor anymore.

I've been having a problem with my MacBook Pro (Core Duo) hanging on suspend about 10% of the time. I explained the symptoms and asked him how to go about debugging it. He suggested disabling console suspend and enabling PM debug in the kernel. I will give that a try and see what I get.

This release of pommed adds a couple of new features:

• Support for the nVidia GeForce 8600M GT LCD backlight, which means the support for the MacBookPro3,1 is now complete
• Automatic backlight dimming when switching from AC to battery power; the backlight level will be restored to the last “on AC” value when switching from battery to AC power again

If you are running Linux 2.6.22 on an Intel machine, you need to upgrade to this release to get the ambient light sensors working again. Jan Larres contributed an icon for gpomme, included in this release. Thanks! I am not really pleased with the code for the nVidia backlight, as it pokes I/O ports directly. It works for now, but I’ll replace that code as soon as I’ll have something better, so if you run into something that could do it before I do, please let me know. Thanks go to Steffen Schulz for pointing me to this code (bl1.c from Nicolas Boichat, modified by Felipe Alfaro Solana). Have fun! Bug reports, ideas and patches at the usual place.

In a discussion with Bdale, he suggested that DM is seen as forking NM. And some people do not like forks. They are not opposed to DM in principle but do not want it outside of the current NM team. Obviously DM tries to respond to cases that NM is not prepared to handle. Furthermore, the DM discussion has been active for quite some time and the various members of the NM team (Frontdesk, DAM) have not participated much in the public discussion. Only when it comes to a vote do we hear some more (negative) opinions. I don’t see that as a sign of willingness to integrate DM or something similar in the current NM structure. So people who are requesting DM to be integrated in NM, please take it up with the frontdesk/DAM… and don’t oppose the principle just because of organizational matters. Internal organization always change and adapt themselves to the situation. Joey is right when he compares this to the introduction of the sponsorship process. I was one of the main actor in that process. I introduced the concept without the consent of the NM team (James Troup, Martin “Joey” Schulze) at that time. It was a fork, a new way to proceed and it became mainstream with the creation of the current NM process. It’s the natural way of doing things in a free software project. That said, I’m not opposed to improving our NM process. It really needs to be reworked in a “Membership Process” and be open to various kinds of contributors. That’s why I created a dedicated wiki page: http://wiki.debian.org/Projects/ReformedMembershipProcess Let’s see if we’re ready to really fix that! I hope to have comments from all the people who look to be so eager to fix the NM process.

Recently there has been some discussion and controversy about a 15yo boy being allowed to perform a Caesarian operation on a woman (without her consent). Don Marti seems to think it’s OK and gives some examples of what 15 year old people used to do in past times. However he misses a couple of significant points, one is that the knowledge of surgery was much lower a few hundred years ago and the expectations of the patient were a lot lower, the other is that the patient in this case did not consent to being operated on by a 15yo. If the boy’s mother thought that he was capable of doing the job correctly then she could have allowed him to deliver a younger sibling… Given a choice I would rather have someone like Doogie Howser operate on me than a random surgeon - but I would be extremely unhappy to discover after an operation that it had been performed by a different surgeon than planned who didn’t have a medical license and who’s motivation was to invade my privacy by making a movie of the event! Don cites the interesting essay Against School by John Taylor Gatto which makes some really good points about the state of the education system in most first-world countries. An interesting point that John Gatto doesn’t mention is that in Japan school-boys wear uniforms that are based on Prussian military uniforms. From all the evidence that I have seen the Japanese school system is more Prussian (IE worse by many objective measures) than most countries. The Sydney Morning Herald has an interesting article comparing education systems which claims that a major cause in lack of academic performance is unjustified praise. I first became aware of the extent of this problem when discussing education with a misguided university lecturer. He told me that he felt that his purpose was to make the students believe that they had achieved something and that this was much more important than actually teaching them. My response was to point out that heroin and cocaine are both good options for people who would rather feel successful than succeed and to enquire as to whether he thought that they should be advocated for children. The conversation ended soon after that and he requested that I not name him or his university when blogging about it. I take this as an admission of guilt, if you act decently in public then you should not be afraid of appearing on a blog - decent actions will either be too boring for a blog entry or things that you are proud of.

Share This

Note: This article is part of my Testing stuff with QEMU series.

From the Debian GNU/kFreeBSD port page:

Debian GNU/kFreeBSD is a port that consists of GNU userland using the GNU C library on top of FreeBSD's kernel, coupled with the regular Debian package set.

Q: Why would anybody want to do that?
A: Why not? [1] So, after we have talked about that, let's start:

1. Install QEMU:
   apt-get install qemu
2. Download the latest Debian GNU/kFreeBSD installer ISO image (either for i386 or amd64):
   wget http://glibc-bsd.alioth.debian.org/install-cd/kfreebsd-i386/20070313/debian-20070313-kfreebsd-i386-install.iso
3. Create a QEMU image which will hold the Debian GNU/kFreeBSD (i386) installation:
   qemu-img create -f qcow2 qemu_kfreebsd_i386.img 5G
4. Boot directly from the ISO image and install Debian into the QEMU image:
   qemu -boot d -cdrom debian-20070313-kfreebsd-i386-install.iso -hda qemu_kfreebsd_i386.img
5. The FreeBSD installer will now start. For more detailed instructions see the Installing Debian GNU/kFreeBSD manual.
   First you can choose between an "Express" or "Custom" install (I used "Express").
6. Next you end up in the partitioning tool. Type "a" to use the entire (QEMU) disk for the installation (the disk is called "ad0", not "hda" as on Linux). Type "q" to quit the partitioning tool.
7. You are now asked which boot manager to use. For QEMU you should use "BootMgr", the default FreeBSD boot manager. If you install on real hardware you can also use GRUB; in that case choose "None" here (see the manual for more information), but note that the installer does not install or configure GRUB for you! You should do that beforehand!
8. Next up: The disklabel editor. Here you'll create a partition ("slice" in FreeBSD-speak) for the root filesystem and a swap partition.
   Press "c" to create a new slice (will be called "ad0s1"), enter "4GB", choose "FS" (filesystem), and enter "/" for the root filesystem. Per default the UFS2 file system will be used. To create the swap partition, press "c" again, enter "1023MB", and select "swap". The new slice is called "ad0s1b". Press "q" to quit.
9. Choose "minimal" when asked which distribution to install.
10. Installation media dialog: select "CD/DVD" and "acd0" (for QEMU's ATAPI/IDE CD-ROM drive).
11. The installation will now begin, and after a while you're asked to switch to console 3 using ALT-F3. Do it.
12. You'll have to answer a bunch of questions: geographic area + city you're in (for timezone), whether you want to participate in the Debian popularity contest, whether module-init-tools should load additional drivers (no, so press ENTER three times). The installation will soon be finished.

At the end you must select "No" as you're told to do, then reboot via "Exit Install". You can then shutdown QEMU.

1. Restart QEMU with the newly installed Debian GNU/kFreeBSD:
   qemu -hda qemu_kfreebsd_i386.img
   
2. Press enter at the FreeBSD boot manager prompt, then login as root (there's no password).
3. First things first: Set up a root password:
   passwd
4. Now let's fix networking, update the system and install a bunch of packages:
   nano /etc/network/interfaces
   Yes, there's no vi, not even a symlink to nano! Uncomment the two "ed0" lines ("ed0" is the equivalent to "eth0" on Linux, I guess).
   /etc/init.d/networking restart
apt-get update && apt-get dist-upgrade
apt-get install vim xorg icewm xterm
5. You can fix your console keymap using the kbdcontrol package (just select your keymap from the menu):
   apt-get install kbdcontrol
6. Finally, let's fix X11 and start it. But first we create a new user, as we don't want to run X11 as root:
   adduser uwe
vi /etc/X11/xorg.conf
   The mouse device is "/dev/psm0", the protocol "PS/2", and the graphics driver should be "vesa":

  Section "InputDevice"
      Option "Device" "/dev/psm0"
      Option "Protocol" "PS/2"
  [...]
  Section "Device"
      Driver "vesa"
    

That's about it. Login as "uwe" (or whatever your username is) and start X11:
startx

Wasn't all that hard, eh? Now, if you've got some spare time, head over to the Debian GNU/kFreeBSD wiki page and help improving this port ;-) You should probably start with reading the PORTING guide. Both kfrebsd-i386 and kfreebsd-amd64 seem to be reasonably stable already (and more than 70% of the whole Debian archive builds fine on these architectures, see kfreebsd-i386_stats and kfreebsd-amd64_stats). I'll quite likely install kfreebsd-amd64 on one of my boxes soonish and start using it, maybe I'll even find some time to fix/patch/port some packages... [1] More elaborate answer(s) and reasons are available in the Debian wiki.

This makes me smile.

And even the DM GR makes me smile, as I hope it will pass :-) Stefano summarized nicely why I think DMs are a good thing.

And "as usual" Joey came up with a new interesting thought: The interesting thing to consider is, if this vote fails, how can the bug be fixed without another vote?

/me on the Debian Maintainers GR After reading on Planet some opinions against the DM GR I made up my mind: I want to post in favour of the GR (and I've already voted accordingly). I swear I'll (try to) be brief. My main point is: this is not an ugly hack to address the long unsolved problem of our sloppy NM queue, this another way of letting people contribute to Debian and acknowledge their work. Rationale follows. Maybe it's just me, but in several year of DD-ness I've met on the net a bunch of people which are "just" interested in maintaining some packages in Debian. I've been training some of those people and of course sponsored their uploads. But if they aren't willing to enroll the NM queue, if they aren't interested in the other social/political aspects of the Debian project I can't blame them, it's their call. I'm in Debian as a DD because I do care about other stuff than plain package maintenance, but I can't ask every hacker around there to share my motivations. Nonetheless I don't see any valid reason to reject and/or put extra artificial burden (i.e. life-time sponsoring) on the good technical work that such people can contribute to Debian. It's just a matter of identifying a new status for contributors that states "I'm contributing my package maintenance skills to Debian, and I'm proud of it", ... without implying full Debian zealot-ness The GR precisely addresses this need: establish this new status, the Debian Maintainer status. (We would need a whole bunch of similar new status for other kind of contributions, like translations and artworks, but this is an entirely different story, unfortunately not addressed by the DM GR) And regarding the fear of decreasing package quality, the sponsoring process has already proven to be bugged in this respect: when they really want, sucking packages can enter the archive, they will find some sponsor. There's no silver bullet, our best hope is to establish social practices which encourage people producing (directly or not) good packages and discourage the others. In this respect the ability to stop accepting advocacies proposed in the GR sounds good to me.

So this is it, I've actually finished at Canonical! For most of the past week, I've been in Portland, OR at Ubuntu Live. I gave two talks (Ubuntu Technical Demonstration and Bringing your software to Ubuntu users) and one tutorial (packaging for Ubuntu and Debian derived distributions). I had a great time, and was glad to get a chance to see my former coworkers one last time. I'm happy to be leaving on great terms with my former employers, and hope to be at UbuntuLive again next year.

This conference was a whirlwind of meeting people. JP, Teri, Jim, Andy and MaryBeth are people I'm really looking forward to seeing in the bay area when I get there; I got to see Steve and Patty in the Debian booth; I managed to go for dinner with Chris and Leslie; A going away party that included many of the above plus Matt, Steve, Etienne and Torsten; I had lunch with Katie, whom I haven't seen since my wedding; I had another lunch with Mermaid, whom I thought had fallen off the face of the earth; my final lunch at Veganopolous included MaryBeth again and Rob. I did miss seeing Kamaya, which is sad, though. I got *almost* everyone I wanted to see.

It's a crazy list. Some of these people will be random business contacts. Some of these are folks that I feel like remeeting them after several years was like only missing a day. Some of these are people I miss already.

Sabrina and I are making the trek up north to Kit and Hannah's wedding. We're staying at Miriam's and had lovely Ethiopian food.

Time to sleep. 7am is going to come too early.

We've had a lot of great blog traffic about Vinismo. I thought I'd try to pull together a few of the better ones.

• vinismo! wiki wine compendium from Hugh McGuire.
• Vinismo Opens Its Doors to Wine Lovers Everywhere from the Creative Commons Weblog. Thanks, guys!
• Vinismo: Wiki + Wine from Zach Copley
• Vinismo from Wendy Copley.
• DemoCampMontreal3 report from Montreal Tech Watch
• DemoCampMontreal3 Report from Josh Nursing
• Vinismo Presentation at DemoCampMontreal3 on the SearchAnyway Blog. Probably one of my favourite pieces, although it makes Niko real mad since it cuts off just before he starts talking. Make mental note: don't say "Uh" so much.
• Bienvenue sur Vinismo, le guide des vins libre by Niko. Niko also bemoaned the difficulty of keeping our project under wraps in Mon lourd secret bient t d voil . What a drama queen.
• Vinismo : un wiki sur le vin by Olivier Niquet. He's suspicious that we are sponsored by J. Lohr, because there are so many J. Lohr wines on our front page.

All in all it's been pretty good. I hope we'll get some more, though! tags: blogs vinismo

DemoCampMontreal3 report So, it's been a couple of days and I should probably get around to posting my own DemoCampMontreal3 report.

• Niko and I started off with our own demo for Vinismo. It was a lot of fun: we talked about the reasons for starting the site, the technical, information architecture and graphics/UI design challenges, and what our future extensions are going to be. At the end of it, we took some questions, which was fun. The most interesting for me was from Roberto Rocha, whose TechnoCit is one of my favourite tech columns in Montreal. He asked, "Your typical contributor will be much older. What will you do to make your wiki more accessible to them?" It was a good question I don't have an answer to yet, but I want to think about it more.
• The second demo was by Heri Rakotomalala, who showed off his social-networking GTD tool, WorkCruncher. It's a TODO list with a twist: items that you don't get done age off the list. You have to re-commit to doing a task on an almost daily basis. I think it's a great and refreshing design; my TODO list gets depressing long and filled with unfinishable tasks, and I get too intimidated to work on ones that really matter. I think Heri might have to make some concessions to people's expectations for TODO lists -- maybe a way to automatically archive tasks, rather than deleting them entirely...?
• The third demo was by the gang from Defensio, who are providing an great anti-spam Web service similar to Akismet. They had a few examples of where they're different, but I'm not well-versed enough in comment spam issues to understand them. My guess is that since they're getting into the market after Akismet, though, they have the opportunity to make a smarter technology. Their one downside? They used slides -- which the rules of DemoCamp. They did demo the service, though.
• Fourth up was the indefatigable Simon Law. Simon's project? To turn back time. Talk about ambitious! His effort consisted of making a typical kitchen clock turn backwards. He disassembled the clock and explained how it worked to the audience. It was great, except for two things: the clock didn't work at the end of the demo (although he got it working by the end of DemoCamp), and he took a few minutes to draw a diagram of the clock; in my mind, that's just a low-tech PowerPoint slide.
• Fifth, and quite fascinating, was a tool that Jerome Paradis showed off. It was a Google-Maps mashup that filtered special emails for an informal private jet sharing network. Apparently, companies who charter private jets often have space in the jets, so they'll make that space available. People who need a last-minute charter jet can send email from their Blackberries and such, and if there's availability they get contacted by the charter companies. The interesting part? These people use a highly structured lingo ("O/W" = "one way"), and Jerome's tool scrapes these emails to make the data into a mapping app for his customers. Very interesting!

All in all, it was a good night -- probably made better by the Argentina Cabernet Sauvignon I had. There's a DemoCampMontreal4 scheduled for August 17th, but I won't be in town for it. Too bad for me! tags: democampmontreal3 defensio workcruncher simonlaw jeromeparadis vinismo

Here’s a guide to supporting Xen servers for people who are not Linux experts. If your job means that you have root access to a Xen server that someone else installed for the purpose of fixing problems when they are not available then this will help you solve some common problems. Xen is a virtualization system that is primarily used for running Linux virtual machines under a Linux host. It is mostly used as a Paravirtualization system in that the virtual machine knows that it is running in a virtual environment - this allows some performance benefits. The host environment is known as Dom0 and root in that domain has the ability to control the other domains (which are known as DomU domains). If you perform an orderly shutdown of the Dom0 (via the shutdown or reboot commands or notification from the UPS of an impending power failure) then when the machine is booted again the DomU’s will be automatically restarted (if the on_reboot setting has the value restart - a common configuration). If you run the command shutdown in a DomU then the domain will be destroyed, and the command reboot will restart the DomU with the same settings - if you want to change the settings for a DomU you need to shut it down and create a new instance. The main sys-admin command related to Xen is xm. Here are the main xm options that are useful in support:

1. xm list provides a list of running domains. For each domain it gives the name of the domain, the ID number, the memory allocated to it, the number of virtual CPUs allocated to it, the state, and the amount of CPU time used in execution. The ID numbers are allocated sequentially, if you reboot a DomU by running the command “reboot” inside it then it will get a new ID number when it re-starts. Many xm operations that may take the name of a domain will also take a Domain ID number. Generally you never use an ID number and ignore it - the only relevant thing about an ID is whether it is 0.

Here is a sample of the output of xm list:
# xm list
Name        ID Mem(MiB) VCPUs State  Time(s)
Domain-0    0    1236    4 r---–  14116.3
wind        13    2999    3 -b----  60114.1
wind-f7    52      519    1 -b----  3329.9 You can see from this output that the domain named wind has 2999M of RAM, 3 virtual CPUs (out of 4 physical CPUs in the machine) and has 60,114 seconds of CPU time used (that is 114 minutes of CPU use - the equivalent of almost two hours for a single CPU). Here are the values you might see in the state field (from the man page xm(1)):

• r - running
  The domain is currently running on a CPU - note that Dom0 will always appear to be running because you are running the xm utility!
  
• b - blocked
  The domain is blocked, and not running or runnable. This can be caused because the domain is waiting on IO (a traditional wait state) or has gone to sleep because there was nothing else for it to do.


• p - paused
  The domain has been paused, usually occurring through the administrator running xm pause. When in a paused state the domain will still consume allocated resources like memory, but will not be eligible for scheduling by the Xen hypervisor.


• c - crashed
  The domain has crashed, which is always a violent ending. Usu ally this state can only occur if the domain has been config ured not to restart on crash. See xmdomain.cfg for more info.


• d - dying
  The domain is in process of dying, but hasn t completely shut down or crashed.

If you see domains that are running which normally aren’t busy then make a note of this. If you see domains that are paused, crashed, or dying then contact the sys-admin. Also know which domains are expected to be running so that if a domain is missing then you will recognise it as a problem!

xm top is similar to the top command in Unix but displays Xen data, by default it displays the same information as xm list but also includes the amount of data read and written from network devices and disks. If your terminal is less than about 145 columns wide the lines will wrap and it will be confusing - stretch the width of your xterm before running it.

If you have multiple network interfaces then you can see the transfer counts for each of them separately by pressing the N key. If you have multiple network interfaces in DomU’s then this can help diagnose some network problems (although you may find that tcpdump is more useful). If you have multiple disk devices in a DomU then you can see their transfer counts separately by pressing the B key. One problem that can be partially diagnosed through this is excessively poor performance. If a DomU is running extremely slowly then it may be impossible to login to diagnose and/or fix the problem (it could take tens of minutes to login), in that case seeing where the disk access is going from outside the DomU can shed some light on the problem. VBD  768 [ 3: 0]
VBD  832 [ 3:40]
VBD 5632 [16: 0]
VBD 5696 [16:40] Above is the identification of the virtual devices /dev/hda and /dev/hdb in a DomU. The numbers inside the brackets are the device node numbers in hexadecimal, so 16:40 means the device 22,64 as a pair of decimal numbers (22*256+64=5696). # ls -l /dev/hd?
brw-r---– 1 root disk  3,  0 Jul 23 17:24 /dev/hda
brw-r---– 1 root disk  3, 64 Jul 23 17:24 /dev/hdb
brw-r---– 1 root disk 22,  0 Jul 23 17:24 /dev/hdc
brw-r---– 1 root disk 22, 64 Jul 23 17:24 /dev/hdd Above is the result of a ls -l on the devices in question from inside the DomU. When I set up a Xen DomU I generally use /dev/hda for the root filesystem and /dev/hdb for swap. So if the machine is performing poorly and /dev/hdb ([3:40]) is being accessed excessively then it indicates that the machine has some memory hungry programs running and is paging heavily.

xm list –long [domain] gives detailed information on all domains, or it can be run with the name of a domain such as xm list –long wind to give the detailed information on only one domain. Generally this is something that you will log to a disk file before restarting domains, in the short-term there is little use for this.

xm console <domain> gives you the console of a domain. If a domain is not working correctly and it is impossible to login via ssh (either due to a network problem or a problem with ssh) then you can access the console (equivalent to a serial-port login on physical hardware) to diagnose the problem. Often the kernel will log messages to the console, such messages will be stored by the Xen system until they are read. If you suspect that there may be many such messages then use script(1) to log the output to disk, if you are unsure then use script to make sure that you don’t miss any data. Even if you don’t understand it the sys-admin probably will!

If the system is half-working then you can login as root to investigate problems. You can escape from the console by pressing CTRL-].

xm dmesg gives Xen logging data comparable to the dmesg command in Linux. If you ever have to reboot the machine (run reboot from Dom0) due to a problem with Xen then you MUST save the output of xm dmesg to a file for later review by the sys-admin.

xm destroy <domain> will kill a specified domain. It’s a last resort for stopping a domain that is not working correctly - it is greatly preferrable to login to the domain via ssh or xm console and give an orderly shutdown.

xm create [-c] <domain> creates a new domain. The configuration for the domain will be taken from a file of the same name in the current directory or in the /etc/xen directory - if /etc/xen is not the current directory when you run xm create then make sure that there is no file-name conflict. You can use this command after destroying a domain or to start a domain that was not previously run.

If you want to change a configuration option of a domain (such as the amount of RAM used) then the usual procedure is to edit the configuration file, run halt or shutdown from within the domain, and then create the domain again with xm create. Note that the -c option is used to attach to the console after starting the domain (you usually want to do this).
I will probably update this post when I get some feedback. I may write more posts of a similar nature if there are requests.

Share This

I voted in favour. People arguing that we should "just fix the NM process instead" are missing the whole point: even if its problems could be fixed soon (but they will not be, since many smart people have been working on it in the last few years and have not found a magic solution yet) I do not believe that becoming a Debian Developer should be easy. OTOH I like the idea of allowing full Developers to delegate co-maintenance of one of their packages like they currently do with sponsorships but without requiring them to rebuild the packages, which can become very time-consuming.

Remember when sponsoring packages was implemented in Debian? Imagine if we had felt the need to vote on whether we were allowed to do that. Instead of just doing it. I'll bet that some people would have argued against, citing reasons such as:

It appears to me that the sponsorship as sketched in the GR is mainly meant to let NMs upload earlier, i.e. it tries to fix the fact that front-desk or DAM approval take too long. I think the fix for that is just to find someone besides Joerg to also read the AM reports. Sponsees as in the GR are a workaround, not a solution.

or:

But the GR micro-manages too much and on the other hand doesn t make the current NM process any easier for Sponsees than for any non-Sponsee applicant to the NM process. Also, like some others said before, I seriously doubt that a big part of the current DD-applicants (i.e. those in the NM queue at some level) would prefer Sponsee status over DD status. What is the difference between a Sponsee and a Debian Developer? Who is interested in becoming a Sponsee and not a Debian Developer and why? Will this Sponsee class really improve the situation for New Maintainers?

or:

I suppose most of our New Maintainers will aim to become a Sponsee just to bridge the time until they re full Debian Developers. And I predict that this is also the major target audience for this new Sponsee class. Some people said on -vote that there are people actually interested in becoming a Sponsee and not a Debian Developer. Personally I find their reasons questionable, but after all I suppose there won t be many people going this route. On the other side, I don t see how this new class enhances the situation for the New Maintainers. Now they not only wait for the Application Manager, Front Desk and Debian Account Managers No, now they will also search for someone who sponsors them. So my question is: If this General Resolution mainly helps New Maintainers, why must it be so complicated? Why another class of contributers, all those complicated rules to set it up and this additional layer of bureaucracy?

or:

If you think the NM process is taking too long, then it's probably better to help out there rather than to try to create a system to bypass it in this way.

But instead, we somehow made the enormous change that sponsorship entailed in how Debian works, without voting on it. Make no mistake, it was a big change on both a technical as well as a social level. Now IMHO, the DM proposal is just fixing a bug in the current sponsorship process. The interesting thing to consider is, if this vote fails, how can the bug be fixed without another vote? I personally believe that any DD has the power to fix this without dragging the project through a vote. They may put their status as developer at stake in fixing it, if they take what seems like the obvious approach, but if one feels that this bug in sponsorship is a bad enough bug and is hurting Debian enough, that might be worth it.

After having spent the last few weeks of my life travelling randomly around Europe; my interrail ticket has alas run out. Although this doesn't mean I stop travelling, it means I will be travelling certainly less frequently.
Despite a few hiccups, I think the experience of travelling around Europe again was fantastic, I would like to thank pixie for bearing with me for so long; and of course also all the people who offered us places to stay. It was very generous of you, and (once I've settled into an apartment here in Oslo) feel free to give me a shout if you need a place to stay whilst over here!
I am here until the 6th; after which I will be in Duesseldorf for a month working, and then hopefully moving back over to Oslo, after having sorted out at least a temporary job and a place to stay.
I shall finish with a few pictures of the trip!


Pub in Helsinki; with a few Debian people!


pixie in the process of killing 6 hours at an airport


At Rob's flat in Amsterdam


Me looking insane on the train to spain


Pixie looking insane on the train to spain

That's all folks!

Following up to Myon’s post, I also wanted to blog my honest opinion about the GR. Given my current understanding of the GR, I hope to see it fail (and will send my vote shortly after this blog entry I think). The reason is not that I think it shouldn’t be made easier to contribute to Debian (on the contrary). But the GR micro-manages too much and on the other hand doesn’t make the current NM process any easier for DM’s than for any non-DM applicant to the NM process. Also, like some others said before, I seriously doubt that a big part of the current DD-applicants (i.e. those in the NM queue at some level) would prefer DM status over DD status. And the same is true (IMHO) for other people wanting to contribute to Debian. This is a simple thing: If I contribute to something regularly in my spare time (like most contributors in the FL/OSS world do), I also would like to have some influence over its directions. And a DM is missing this influence even more than a DD is. So what should be done instead in my opinion?
I think that a DM like status is fine as part of a (possibly re-designed) NM process. Given the current NM process, I would like people been given a DM like status after they finished the T&S (tasks^IIRC and skills) part if their AM found their skills and knowledge of the policy rules sufficient to give them that status. If that is all they wanted, they can drop from the NM process at that point and stay DMs. If they want to become DDs later on, they can resume the NM process at that very step (or continue right ahead). This would do several things:

• introduce the DM status as an alternative to full DD status
• integrate the DM status closer with the existing NM process
• take some load of the friendly sponsors who upload non-DD packages now, giving them more time to help more new contributors
• give people waiting for DD status some intermediate level at which they already can do more than before their joining of the NM queue

So I really think “more discussion” is the only valid option for me in this GR. If you want to change my mind: Please leave some feedback in my blog. Or give a precise (but brief) description why the current proposal is better than integration with the current NM process in one way or the other. Abbreviations:

• DD = Debian Developer (a full Debian project member, includes voting rights)
• DM = Debian Maintainer (planned to be a somewhat restricted DD, among others without voting rights)
• NM = New Maintainer (should actually be: New Developer)
• GR = General Resolution (a way in Debian to create new rules or to ask the project leader or others in the project to do or refrain from doing something)

Update:
The GR even seems to contradict itself a bit. If the upload rules are applied in an AND fashion, one of these rules is superfluous (the first one), at least if I’m not mistaken:

• the Maintainer: field of the uploaded .changes file corresponds with the owner of the key used (ie, non-developer maintainers may not sponsor uploads)
• the most recent version of the package uploaded to unstable or experimental includes the field “DM-Upload-Allowed: yes” in the source section of its control file
• the most recent version of the package uploaded to unstable or experimental lists the uploader in the Maintainer: or Uploaders: fields (ie, non-developer maintainers cannot NMU or hijack packages)

The first rules also means that no DM could ever do an upload for packages team-maintained in the fashion cyrus-imapd-2.2 is maintained (Maintainer address is the teams mailinglist address, all uploading team members are in the Uploaders field). This is IMHO a serious flaw in the proposal. If the first rule was dumped, all would be well for team maintainers.

Share This

First off, this guy is walking around handing out free fudge. Neat idea, but I can't quite figure out why!

Bill Hilf from Microsoft spoke today. He started by saying "I guarantee you won't agree with a lot of things I say today."

Nat introduced him as "our man on the inside."

Microsoft is submitting their Shared Source license for OSI approval. I don't know if this means that MS will have to actually make any modifications.

New website today: http://www.microsoft.com/opensource.

Bill invited feedback from anyone at billhilf at microsoft dot com.

He got some fairly pointed questions from Nat about software patents. Bill said two things about that: 1) Microsoft flubbed the communication with the press and that their intent isn't to sue, and 2) Microsoft is learning and he's working to help them learn.

Rick Falkvinge from the Pirate Party

Funny and informative talk about why they've started a Pirate Party in Sweden.

Originally copyright only impacted public places, but now it impacts people's private lives as well.

Copyright is protecting the entertainment industry -- funded by luxury purchases -- at the expense of privacy and individual freedoms.

"The Norwegian Liberal Party forked our platform into Norwegian"

www.piratpartiet.se/donate

"Political donations in Sweden are not regulated", so you all can contributed

Steve Yegge (Google)

"Google will probably fire me for this talk"

Neither Steve's mic nor his laptop appear to work... after his line about being fired, someone shouted "Google is very powerful!"

"A brand, in geek terms, is a pointer."

GTE was, for a time, the most reviled brand in the US. Then they invested in improvements and ran commercials basically saying "we don't suck anymore", but nobody believed it.

"The single biggest branding problem in Open Source is the name 'Open Source'."