Joey, I see a huge difference between voting on the current DM proposal and your virtual (sorry, I can’t remember a better word for it) voting on sponsoring uploads. Debian Developers were always allowed to upload any package they saw as fitting into Debian (though there were no guarantees for these packages to actually being included). Also, NMUs are OK if the maintainer agreed. So all they (seemingly) did was putting a different maintainer address into the control file. However, at least in theory, the sponsors were still responsible for their upload if it turned out fishy. The DM proposal (don’t get me wrong there, I generally support the idea, I just don’t like the way it is implemented in the proposal) is shifting this responsibility from the sponsor onto the shoulders of the DM, which is a good thing. However I think it doubles some of the work the NM queue already needs done, so my proposal would be not to have it as a completely seperate path for a contributor, but instead see it integrated into the NM process. Wether it would mean adding a new maintainer to the DM keyring after he had an advocate (which is pretty near to the current proposal) or after an AM was assigned and checked some basic things (which I would prefer) doesn’t make a lot of difference to me.

Share This

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

In Improving simple charts, Dirk Eddelbuettel wrote a nice little summary how to produce “nicer” charts using R. However, in my opinion, the charts he provided as alternate options to the original, purely linear graph are less readable for the average person. If anything, using a logarithmic scale on the original Y axis (number of packages not built after a specific date) would be of use, but the other graphs only hide the original point of the post Dirk replied to (How old are our (Debian’s) packages?). The point was that 94% of all packages had been rebuilt since the release of Sarge or, if you want to put it the other way around, 1264 (6%) were built before Sarge was released. This relationship is hidden from immediate recognition by the reader of the graphs. I admit though, that Dirk’s second graph (Number of packages against age in days with the age being on y logarithmic scale) is also insightful. The other two graphs he presents might make sense in a scientific publication if some point in the “more detailed” areas of the graph needs proving, but for this specific problem, they really don’t make sense to me. Actually, I would question their use even in scientific publications, since they distort the original data a lot. Scientists are pretty much used to logarithmic scales these days, but I couldn’t work out how the scales work on those two graphs. And another note on the second graph (logarithmic age): The way the X axis is labeled (10, 20, 50, 100,..) is also pretty non-intuitive to me. I’m much more used to something like 5, 10, 20, 40, 80, 160 and so on, which gives the same distance between each label and seems a lot more usable to me.. (edit: Fix spelling of Dirk’s surname)

Share This

Hi. Recently, on planet.debian.org, there were quite a few posts relating to blood donations. I must say that I really only live thanks to people donating blood. As many might know, I had a freaking motorcycle accident about 9 years ago. Well, apart from loosing my right leg in the weeks following the accident (irreparable damages to tissues led to amputation), I also lost a lot of blood after the accident. In the six hours following the accident, I got no less than 65 blood infusions (approximately 24-30 litres or 6-8 US gallons). As you can imagine, this is about 3-4 times as much blood as my body normally carries around. At least I can say that I didn’t receive blood without giving some before, though certainly I wasn’t able to give that much blood (I donated about 10 times, approx. 0.45 litres each time). However, due to the medication I now need, I can’t donate blood anymore. Anyhow, I strongly suggest to anyone who is capable of donating blood to do so. And regarding Thijs comment about the frequency of donation and payment: This is highly depending on the area you live in and the organisation who manages the donations. For example, while I donated blood in Dortmund, Germany, I had two options to donate blood: German Red Cross, who would accept a donation every 6 weeks, with free sandwiches, drinks and chocolate but without payment and the city-owned hospital’s blood bank, which allowed a donation every 3 month, with free drinks and a 50DEM (approx. 25EUR/30USD) payment. This sounds as if the city-owned blood bank could attract homeless and junkies who were in for the money, but from my experience, the blood bank did far stricter pre-donation tests (I can’t tell what they did after donation for either organisation) than the red cross. And knowing how much money can be earned with the blood donated, I certainly think that payment is fair, though not strictly necessary. And the blood bank people did a much better job when applying the needle than the red cross people did, which might be because they were used to taking blood from people with bad veins (mostly patients donating blood for themselves for use in a later, planned surgery). But to be fair: I know from other people who had very good experiences with the red cross staff in this respect. Once again: Please donate blood if you can. If you are uncomfortable with the choice you made on your first donation, check out other options for donations. For example, if you almost collapsed when donating blood, try out the plasma donation if it is offered. They usually take the plasma, but give back an equal volume of a substitution, so your circulation isn’t disturbed as much as by taking approx. 0.5 litres from it within an hour. If you feel that the person who applied the needle did a bad job, ask for someone else next time or try a different organisation altogether. cu,
Sven

I did some work on my mobile phone shopping list ShopList today. Thanks to a bug report from Sven Mueller, I think I managed to correct an encoding issue. If you use ShopList and enter non-ascii text into the shoplist web application, let me know if things are working for you. I also did some work on the back end to enable statistics, but only for users who are logged in to their accounts. Not surprisingly, the most common things people buy at the store are:

• Milk
• Bread
• Butter
• Cheese
• Eggs

Which probably hasn't changed in hundreds of years. Sort of reassuring, I guess?

Gunnar is following up on the init script blog posts by Erich and me. First a note to Gunnar: The idea of the init scrip snippets isn’t exactly my own idea, but rather taken from a comment to one of Erich’s posts (IIRC), I don’t know the original author anymore. Anyway, I really think that some init script generator should work. It should even be possible to fetch variables from /etc/default/<daemon-name> if needed. I’m just doing a braindump of what I have in mind for the start and stop of a daemon. I would expect a configuration file (currently I think one for each operation might be best, but INI-lookalike files might also be OK). So for the start operation, I would expect these options:

1. simple daemon, uses a default config with a hardcoded path and needs no options or only static options passed:

   [SIMPLE]
   /path/to/daemon
   option 1
   option 2
   option 3
   

   Where I chose to name one option per line so whitespace and controll characters can be part of the options without the need to quote anything.
2. a bit more complicated, needs a few variables from /etc/default/daemon:

   [TEMPLATED]
   /path/to/daemon
   option 1
   %PARAMETER_FROM_ETC_DEFAULT%
   --parameter=%ANOTHER_ONE_FROM_ETC_DEFAULT%
   

   Where the script generator would have to make sure that the parameters from /etc/default are filled in at runtime. I would expect POSIX-Shell-Scripts in /etc/default for this.
3. Really complex: A custom script snippet is needed which has to do some specificc tasks, like cleaning possible stable locks which had been left behind.

   [SCRIPT]
   rm /var/lock/daemon.lck
   /path/to/daemon --background --and --other --options
   

   Where the script generator would simply take this script and use it where it would otherwise generate its own code.

As for stopping, I generally see only three options for the sysv-like background processes: Either a script is needed (see above for how that would look like) or a process needs to be killed according to a PID-file or the process name (with the later being rather bad). So this would result in:

1. [SCRIPT] like for starting the daemon
2. killing by PID-file:

   [PIDFILE]
   /path/to/pid-file
   

3. killing by process name/executable:

   [PROCESS]
   binary
   

   or

   [PROCESS]
   /path/to/binary
   

   where the generator would either only look at the name of the process (first version, no full pathname) or for a process with the given executable (from /proc/ /exec, I would expect).

Alright, this would leave the cases of running (instead of backgrounding) the server and stopping such a running server (the later should be fairly simple unless the stopping of the server requires additional actions other than simply killing it) as well as the reload/restart/status stuff. But these should also be relatively simple actually. What would be interesting for me:
Does any init system require information that is not part of the following list? I would plan with supplying information how to:

• start server in background
• start server in foreground (without the need for a terminal)
• determine wether a server runs (status)
• determine wether a server is ready to serve requests (also part of status)
• determine wether the server is installed (and able to be started)
• stop a background server
• stop a foreground server (unless specified, a simple SIGKILL to the process is assumed)
• restart foreground server (unless specified, a simple stop-start cycle is assumed)
• restart background server (unless specified, a simple stop-start cycle is assumed)
• reload config (unless specified, it is assumed that reloading doesn’t work and a restart is needed)
• reopen logs (unless specified, the “reload config” operation is assumed to do this)
• some meta information: short description, needs writeable filesystem(s) mounted, needs a certain daemon to be running already (or even: able to serve requests), enhances other daemon X and should be started before it (don’t care if X isn’t installed/configured), is enhanced by daemon Y and should be started after it (don’t care if Y isn’t installed/configured), replaces daemon Z, should only run once at startup, …

Finally, even with all that information available inside a Debian package, this would still leave one question unanswered: Who triggers init script generation? If a daemon package does so in postinst: How do I switch to a different init system? If the init system does it in postinst: What happens to additional daemons installed later on? If they get regenerated during system start: How much penalty does that cause? Currently I think the route to go is to provide a command to daemon packages’ postinst that (re)generates only the needed scripts for that package and have a command used in an init system’s postinst which regenerates all of them. That should do. Regenerating during boot would most likely take too much time and has other problems, too, like the availability of a writeable filesystem to store the generated scripts.
Alright, if someone would like to see this post (or rather parts of it) on the Wiki page about an Init HackFest, please transfer it there yourself. I’m currently not able to log in, for whatever reason.

In his “Init followup” post, Erich posted a reference to his Debian-Wiki post about a proposed Debian HackFest after Etch was released (which would be about 5 days ago<smile />). Anyway, since that page at the wiki is protected, which means I can’t edit it, I’m posting my thoughts here. I agree with Erich and some other commentors at Gunnar Wolf’s blog post that it doesn’t make sense to add X init-script-only-packages for any daemon to support X init systems. Instead, each package containing one or more daemons should contain the meta information needed to create all init scripts. Basically, this would probably include script snippets which do the following operations:

• Pre-check: Check wether the package actually is installed rather than in removed/configured status.
• start: Start the daemon in background mode.
• run: Start a daemon in foreground mode (so that an exiting daemon can immediately be recognized by the init system).
• stop: Stop a daemon running in background mode.
• stop-running: Stop a daemon running in foreground mode. This should only be needed if the daemon doesn’t shut down nicely on a SIGTERM but instead needs some sort of message/semaphore to do so.
• status: Return current running status.
• reload: Reload configs, reopen logs (if supported by daemon).

Additionally, some control information would be needed including, but probably not limited to:

• Dependencies: Should allow for alternatives, lists daemons which need to be running before this daemon is started.
• Provides: Similar to package-provides, this should be used to allow things like replacing inetd with xinetd or something else providing similar functionality.
• Short Description: For init systems that are capable of showing a short description next to the name of configured daemons
• Run-Sets: Not strictly like sysvinit-runlevels, but similar, should allow the admin/user to configure different sets of daemons to start, selecting at boot by a kernel cmdline-parameter or at runtime through some command (”init 1″) which set should be running.

The script snippets listed above should allow basically any operation on a daemon, including the force-reload and try-restart commands not yet implemented by all current sysv-initscripts.

Hmm, following up to a post by MJ Ray, I found out that I’m 40% nerdy:

Eddy, while I agree that ebuilds look a lot cleaner, shorter or easier than typical debian/rules + debian/control, you should consider a few things:

• There is cdbs in Debian, which provides a lot of help in packaging “easy” packages. Note though that I don’t really like the hidden magic it does.
• ebuilds don’t have to handle architecture independent data, since Gentoo doesn’t have such packages. If Debian wouldn’t have architecture independent data, debian/rules would look easier immediately.
• Updating an easy package (i.e. one without Debian specific patches) to a new upstream usually is a no-brainer in Debian as much as in Gentoo.
• With ebuild classes, you still have to know/learn which class matches your package best, so you still need to know what each class actually does. That isn’t too different to understanding dh_* stuff, if you ask me.

So all in all, I’m quite certain that the amount of learning needed to create a correct ebuild is lower than that needed to create a Debian source package, but I don’t think that packaging for Debian is hard either. And finally, Erich is quite right that a central repository for all Debian packaging scripts would be a nice thing. However it would be quite hard to determine the right VCS to use for that. Most de-central VCSes I glanced over need manual intervention on the “server” side to include patches from local developer branches. And of course there is the problem of several packages having a non-clean upstream tarball they need to repack for each release as well as several packages having a tarball which includes more than one single upstream tarball. You would need to find a way to handle those as well.

David, though I feel your pain with this, I think the PHP5 code is much closer to what other languages do and is therefor the following the “least surprise” rule. However, breaking existing code with a compiler/interpreter upgrade is of course a bad thing. But in this very special case, I think that the plus side puts in more weight than the negative side. When reading PHP code others wrote (which is what I do with PHP most of the time, with just a few hundred lines of PHP code ever written by myself), I always wondered why

$f=new Foobar();
$a=$f;
$a->do_something();
if ( $a->fetch() != $f->fetch() )
echo “they differ\n”;


would ever print anything. At least until I hit myself with the php-cluebat again, remembering that $a=$object assigns a copy of $object to $a, not a reference like most other languages tend to do.

In my previous post about “Dual boot and full encryption“, I talked about the difficulties of combining full disk encryption for Windows with the option to dual-boot into Linux. Thanks to Jari Eskelinen (who probably is the anonymous user who posted the link to his page in a comment to my original entry), there now is a solution for this problem, at least for DriveCrypt Plus Pack from SecurStar GmbH. I will try this solution soon and it’s likely that I will blog about the results.

Well, today I worked on a new little hardware project. It’s supposed to become open source (both schematics/PCB layout and software), but I want to work on it together with a close friend more or less exclusively for now. Anyway what it is going to become is a small controller board with a 2×16 character LCD module (DOG-M162 from lcd-module.de, an Atmel ATmega16, a small serial EEPROM, an IR transceiver, a USB port (featured by an FTDI USB2serial chip) and two relais outputs. The software will use the board as an external controller for Canon EOS* cameras (one output controlling the autofocus trigger, one the shutter trigger) with several “programs” which take a photo every X seconds or opens the shutter for a given amount of time (up to several minutes for night time photos). Anyway, today we worked on the first prototype board and tried to get the LCD to work. First we tried a 3.3V setup for the board - our initial goal - and several software versions later, we used an oscilator and found rather disgusting signal edges, so we switched to 5V (all components used were 5V and 3.3V capable, except that the display needed a slightly different circuit with a capacitor replaced by bare wire and another removed). Now the signal edges looked fine and we tripple checked that all connections were as expected. But even after trying two different initialization routines from the web and writing an own one from the controller specs, we were not successfull. This is quite frustrating, so if anyone would be able to help here, please leave a comment or contact me by email.

In his post “Ok, now we are getting somewhere! (Re: XML-based configurations)”, Gunnar Wolf writes that he doesn’t regard XML as a suitable standard for configuration files which need some sort of nesting (like, e.g. the apache configuration needs nesting while a config for a simple /usr/bin/sendmail replacement like nullmailer or msmtp won’t need nesting). He seems to like YAML, as you can see in his first post on the subject: Configuration files for humans and for computers. I looked into YAML a bit and to me, it doesn’t seem like a good replacement for XML in config files. Sure, the files look simpler, but I would have a heck of a problem to memorize the syntax. Sure, a colon (:) is intuitive for a direct mapping, but remembering that a pipe (” ”) marks a literal which preserves newline while the default is a scalar which maps newlines to spaces is harder. Folded style (”>”) is even harder to remember. It folds multiple lines with the same indentation into a single line unless there is a differently indented or empty line in between. More important is that I honestly hate syntaxes which rely on indentation. Indentation is dead useful when a nested config or source is read by a human, but it often causes problems when edited by a human, especially when tabs are used. A program could (and most often would) see a difference between “test” and “<8*space>test”, while a human would most probably not see a difference with default tabs. To sum it up: I see the problems with XML, most notably bad program outputs which don’t use indentation (some even put everything on a single line) and the sometimes overwhelming amount of whatever constructs, but YAML doesn’t seem to be the right solution to me neither, especially due to the indentation-used-as-syntax-element problem. What I really would like to see is a syntax that doesn’t use indentation as a syntax element and doesn’t need the name of the opening tag when closing it, but still allows to use it. In other words both of the following constructs (or an equivalent which looks less like XML) should be legal:

<x>
        whatever
</>

<x>
        whatever
</x>

While the following should raise an error:

<x>
        whatever
</y>

Russel Coker wrote in etbe: some random Linux tips: Prefixing a bash command with ‘ ‘ will prevent a ! operator from running it. For example if you had just entered the command ” ls -al /” then “!l” would not repeat it but would instead match the preceeding command that started with a ‘l’. On SLES-10 a preceeding space also makes the command not appear in the history while on Debian/etch it does (both run Bash 3.1). It’s pretty easy to get the Bash shell to ignore lines starting with a space in its history: Just add

export HISTCONTROL=ignorespace

to your ~/.bashrc. Alternatively, ignoredups ignores duplicates and ignoreboth ignores both. It’s also possible to tell Bash to ignore lines which match a specific pattern. For example,

export HISTIGNORE=" *:~/*"

will ignore any command starting with a space (emulation the ignorespace option to HISTCONTROL) or starting with ~/ (any program/script in or below your directory). Personally, I just use “HISTCONTROL=ignoreboth“.

Hi. I’m currently working on a system image which is (among other things) supposed to automatically mount CDs as they are inserted. The big problem with this is that I finally had to recognize the fact that with all those hotplug events issued, a media change in an existing device is recognized by the kernel (at least it seems so when looking at drivers/ide/ide-cd), but this is not passed to userland, i.e. the hotplug handler (/sbin/hotplug or whatever you wrote to /proc/sys/kernel/hotplug) doesn’t get an event for this. The only way to recognize a media change that I found is to poll the CD-drive(s) for their media status and handle any changes there appropriately. Given that the kernel already seems to have a mechanism to recognize media changes, it would really be cool if it could issue hotplug events for them.

Note: This post grew larger than originally intended. It drifted away from Vista to general rants about Microsoft and the content industry towards the end of the post, so just skip the rest if this is not of interest to you.
The latest thing I heard about Vista is that Microsoft bribes bloggers with Vista notebooks. As the article points out, this is plain wrong. Apart from crossing the line by not only giving away their own product to reviewers for free, but by actually providing an additional benefit (in the form of the notebook), they also did it wrong because - as the article on tech.blorge.com linked above points out - they don’t understand the way blogging “works”. Too many will be more or less angry because they didn’t get a free notebook (if anything at all).

In my opinion though, this is by far the least important mistake they made with Vista. All their content protection stuff is far worse. It basically does what current copy protection mechanisms already do, but to a much larger extend: Bother the legitimate users while users of pirated copies are uneffected. I don’t think they can avoid pirated copies for a minute. A friend already has a nice HD video player (HDDVD IIRC) and a nice HDCP capable TFT-display, both bought in december. Problem is that the HDCP protected connection resets every few minutes, causing a dropout in both video and sound for a few seconds each time. Seems HDCP compatible player and HDCP compatible display doesn’t necessarily mean that the two work together. Fortunately, in this case, there is some “secret” code you can enter on the players remote to disable HDCP completely. Of course, technically, this is not legal use, but if he didn’t use that hack, he wouldn’t be able to watch his legitimately bought video with his legitimate player and display. Given this problem, I can only shudder when thinking what will happen on Windows Vista with all those encrypted and signed communication channels (drive->memory->videocard->display, just to name the most obvious ones). And there is also the degradation of totally unrelated audio and video stuff while some “premium content” is played. Assume that I play some premium audio stuff. According to the hardware and driver specs for Vista, the availability of any premium content means that any non-encrypted channels need to be turned off or artificially degraded (like downsampling video from 1080p to VGA and upsampling it again since the display might be limited to only display 1080p). This is oh-so-stupid.
And there is also their EULA, as reviewed by Ed Foster. I won’t go into details here, but let’s just say that the EULA is the final nail in Vista’s coffin for me. I’ve been a Windows user since Windows for Workgroups came out (though I’ve used Linux on my machines since 1993 - and almost exclusively since 1998), but I won’t buy Vista, not even when it would be included with a new PC. By the way: This also most likely means that I won’t buy any HD video stuff at all, since the Vista content protection stuff was mostly dictated by the big Hollywood studios. Seems like I will be saving quite some money over the next years. (Which I actually need to do anyway.) Other interesting links regarding Vista:

• The Inquirer - Charlie Demerjian: Microsoft Vista is not an option
• The Register - Scott Granneman: Surprises inside Microsoft Vista’s EULA
• Juha Saarinen: DRM behind lack of Windows Vista drivers… and fear the new content protection
• Techworld.com - Chris Mellor: Vista crippled by content protection
• The Register - Andrew Orlowski: Vista’s Suicide Bomb: Who gets hurt?

I said they did it all wrong because they forgot that they are selling Windows not to the content industry but to the consumers. Sure, the consumers want to see what Microsoft calls premium content, but I’m also sure that they don’t want all that content protection nonsense Microsoft built into Vista for the sake of the content providers. They lost the balance between avoiding pirated copies (which I think the content protection stuff will have no big effect on) and bothering users of legitimate copies. Heck, I already use “pirate” copies of most of the (Windows-based) games I play because I don’t want to be bothered by their original-CD-checks, even though I own at least one legal copy of all the games I play. Would I need to download pirate copies of the HD movies I want to watch because I don’t want to be bothered by whatever side-effects VCP will have, even if I own legal copies of the same movies? Dear Microsoft, dear Content-Industry (TimeWarner, Disney, whoever), please re-think who you want to sell your content to. I already avoid DVDs which carry additional copy protection (apart from CSS), and if they were available at all, I would prefer to buy DVDs without even CSS. The same is true for CDs (except that they obviously don’t have CSS). Consequently, I’m likely to avoid buying HD videos which impose unpleasant restrictions on me, including those that disable the S/PDIF output of my player (no matter wether PC or standalone) since I paid a lot of money for decent HIFI equipment two years ago and I sure as hell won’t want to by new equipment within the next few years. Luckily, I didn’t yet buy any HD video gear, though my notebook, when equipped with a HDDVD or Blueray drive should be capable of playing HD video - if MS and the content industry wouldn’t impose stupid restrictions.

Sven Mueller commented:

"There is a better solution for building packages if you don't have a local unstable machine up. Use pbuilder (w/ or w/o the pdebuild "frontend"). I had refrained from setting up pbuilder for quite a while, and was amazed how easy it was when I eventually did. The only "problem" is that you probably want to make sure that at least "debian/rules clean" works even under Debian/stable. But I personally like to keep my packages buildable under stable anyway (since I usually use backports of them on production systems)."

I tried pbuilder at first and it failed because of the aforementioned debootstrap stable/unstable difference. After I read up on debootstrap, I didn't really see what pbuilder added to the system besides more tarball processing, so I didn't bother trying it again after debootstrap worked. Am I missing out on anything important? Mark Brown commented:

"pbuilder provides management of the chroot environments (you can have several set up and it'll let you choose between and update them) and a convenient front end for building packages in a chroot (you can just point it at a package and say "go build this in a chroot")."

I'm probably being dense, but I still don't see a benefit. A chroot is more-or-less just a tree on the disk so I can have several set up anyway, updating them is just running update inside the chroot and I just mv the package into the chroot and say "go in that chroot and build this". Maybe pbuilder just isn't beneficial for me.

Wouter and Russel: Wouter is right that 0.0.0.0 (or 0 in short) is not an alias to 127.0.0.1 (aka localhost). There are interesting things about specifying IP addresses though. As Matt said in a comment to Russel’s entry, 0.0.0.0 can be shortened to just 0. That’s right and also, 127.0.0.1 can be shortened to 127.1 with any software which implements parsing of IP addresses correctly. Actually, 2130706433 (127*256 +0*256 +0*256+1) would be an alternate alias to 127.0.0.1. A different example would be http://1426782553/ or http://85.719193/, which should take you to my blog at http://blog.incase.de/ (at IP:85.10.249.89) - Except that my Apache doesn’t seem to be able to handle the request with that hostname.
Update: a working example is http://1208933736/ or http://72.974184/ which takes you to google.

Live CD on a removable disk, the Debian way In [live-cd-on-removable-disk] at some point I wrote:

Enrico's note: do we have anything in Debian that we can install and just does that?

Here are the answers: Sven Mueller writes:

Well, Enrico, a tool I really grew fond of, which auto-configures X on Debian systems is xdebconfigurator, it lacks being auto-run on each system start, which I consider a feature on normal systems, but for your proposed usage (i.e. a portable USB-storage based Debian system), it would certainly be the right thing. Essentially, it never failed on me. Except for VMware virtual machines, where all it did wrong was that it proposed too high resolutions which resulted from my dual-screen Windows setup I ran VMware on. You might want to give it a try.

Tollef Fog Heen writes:

I added the support in casper for doing this almost a year ago and it has saved me lots of debugging time. Booting the live CD that way is almost as fast as booting an installed system. If you couple this with using the persistent storage support in casper, you can get the configure-on-boot support together with persistency. In a later update, slh is quited saying that xresprobe doesn't work on AMD64. This is wrong, I wrote that support based on code by Matthew Garret a little more than nine months ago. I wouldn't recommend incorporating it in new-written code, but rather use libx86

And finally, Marco Amadori writes:

Without needing to look for tools external to Debian, there is already the Debian Live software in sid: live-package, that creates a live system, and casper, that generates an initramfs that can configure a Debian system on the fly. So far there is no hard disk target for live-package, but the "Iso" target can already do the job quite well. At boot time, Casper's initramfs scans all the block devices, so it works also for USB keys and hard drives. To obtain a hard drive image, you just need to invoke "make-live" with the options to have the required software, then copy the content of the iso (or of the directory ./debian-live/binary) on a partition and install the boot loader. This is what the future "HD" target of live-package will do; so far it can only build ISO and Netboot images.

BluWiki has put up a new Vendors page, which lists various (a lot of IMHO) vendors and their attitude to open source as a pos/neg sort of list. Quite interesting though still incomplete.