I was wondering if is right to our users that we are following only the RC bugs before a release. I think not. Don't get me wrong, I don't want important bugs count to be 0, or something similar; that would be insane to have as a goal.

I am thinking that we should (during the freeze) poke more of those important bugs that our and/or others' packages have. If you are like me, you will feel that you can't do anything/too much to improve the quality of the release during the freeze since some of the RC bugs are corner cases, not reproducible on your arch, already taken or you don't have the knowledge to fix them.

Many of the important bugs are broken functionalities that affect the users on a daily basis, and living 2 years with the same set of bugs is a pain. I don't know how that would feel, but I can imagine. I used Woody for only a half an year and after 2 months I started using backports. After 3, I started pulling things from Sarge (at the time it was testing). At the end of that half of year I was using mostly Sarge stuff and decided to go entirely into testing.


So, what do I propose? Maybe we should make some pages in the style of the RC bugs count pages which follow the important bugs.

As a bonus we might see some interesting things like bugs which were downgraded from RC - the RC graph would go down, while the important graph would rise. Of course, that wouldn't mean too much since that would be the product of badly assigned severities or downgraded and judged as non-RC bugs, but it would interesting to follow such tendencies.

Via DRM Watch, Netflix to Offer Streaming Movies Online. My initial reaction: eh.

Netflix’s streaming service will differ from existing online movie services like those from Amazon, Movielink, and Apple iTunes. Those services offer rentals of movies for a fixed time period (e.g., 24 hours) or downloads-to-own, known in Hollywood jargon as ESL for Electronic Sell-Through. In contrast, Netflix will let users pick from a catalog of available films and let users watch any of them for up to a fixed number of hours per month, according to their subscriber level, such as six hours per month for entry-level subscribers. The service will launch with a catalog of about 1,000 titles, the same number as are available on Movielink’s rental service. The video delivery scheme that Netflix is using is a streaming-only technology that senses the user’s Internet bandwidth and adjusts the video quality accordingly; thus it is analogous to RealNetworks’s Rhapsody music service.

Limiting the catalog to 1,000 titles undermines Netflix’s key selling point: enormous selection and a long-tail business model. I could probably find those same 1,000 titles at any Blockbuster Video. So all I’m saving is a trip down the street? In return, I get something I can only watch on my computer (with Windows) for a limited number of hours? Apparently, if I want to watch the same scene a few times, or with the director’s commentary (is that even available?), I’m using up my six hours per month.Even cable movies-on-demand is a better service. Don’t get me wrong — I love Netflix as a DVDs-by-mail service. I also think the Netflix web interface and collaborative filter is pretty great, although the third-party Netflix Queue Manager Bookmarklet is a definite improvement. Based on this initial announcement, I can’t think of a single reason why I would prefer the online streaming version of Netflix. Usually I have the foresight to figure out what I want to say 24 hours in advance (the delivery time for Netflix-by-mail) and having three DVDs at once gives me sufficient options in case I’m unsure. Ultimately, I suspect Netflix just wants to send the message that it’s in the Internet-delivery market, which ultimately of course will decimate its existing business model. I just wish it had a more impressive first offering.

Happy global warming...:-(... Please spread the word around: we are all responsible for this with our daily attitude with regards to the respect of our environment. Environment respect is no more (and has never been) a joke.

Says the guy blogging about booking flights from Paris to Edinburgh...

niq commented:

"FWIW, in the real westcountry (West Devon, near the cornish border) we've missed the storms. A bit of wind in the morning, and some drizzle, but nothing substantial."

Yes, seeing what happened further north - roofs ripped up in Manchester - and east - house collapse in King's Lynn (pic 9) - then it seems we got off lightly this time. I hear that Germany declared it a hurricane, but I haven't confirmed that online. Euronews coverage. As far as I can see, there's snapped aerials and all the windows look like someone has sneezed over them, but damage mostly stopped after the fences were ripped to bits. I heard that the sea overtopped the wall in Weston, but I can't find pictures. I'll see myself what town is like later today. Update: niq, you didn't get an email notice because your mailserver is cocked-up:

"550 Error: 23Your subject line looks like spam"

Damnit, it's your phrase in the subject line!

After my post from yesterday, I’ve been able to find out what my problem with usplash is about, although I’m stiill working in a proper solution to it. It seems that when the root filesystem is changed, programs must react accordingly. The proposed sequence for the usage of pivot_root is something like the following:

• Create the new directory in which the new to-be-root filesystem will be created: mkdir /new-root
• Mount the proper partition, that will end being the root filesystem, in that directory: mount /dev/hdxx /new-root
• Create the directory in which the current root filesystem will be mounted after the change. That directory shall be inside the new root directory: mkdir /new-root/old-root
• Change directory to where the new root partition will be mounted: cd /new-root
• Move the root filesystem of the current process to the directory /new-root/old-root and make /new-root the new root filesystem: pivot_root . old_root
• Change the reference to the root node of the current process to be able to get a shell that runs inside the new system. Care must be taken in cleaning the shell’s input and output channels to be able to read and write: exec chroot . sh dev/console 2>&1
• Unmount the device that was previously mounted as root: umount /old-root

To be able to analyze the exact starting sequence of the system stored in the initrd.img, we must expand its contents to a directory using cpio. Some time ago, initrd.img used to be a filesystem that used cramfs, minix or ext2 filesystems, but not anymore for the newer Debian systems.

• We create a temporary directory to store the contents of the initrd.img file: mkdir tmp_initrd
• We change to that directory: cd tmp_initrd
• We copy the desired initrd.img file to the current directory, and rename it to reflect the fact that it is compressed with gzip: cp /boot/initrd.img-xxx initrd.img.gz
• Uncompress it: gunzip initrd.img.gz
• Expand its contents: cpio -i initrd.img
• Delete the image file: rm initrd.img

The script that is responsible for setting up the system at start is called init and is currently a shell program. Having a look at it, I found out that a temporarily environment variable is set, designing the place in which the real root filesystem will be temporarily mounted before switching it to the root filesystem: rootmnt=/root At some point later, /sys and /proc filesystems, that were mounted in their respective directories at the beginning, are moved to $ rootmnt /sys and $ rootmnt /proc to be set in their final destination directories: mount -n -o move /sys $ rootmnt /sys, and later mount -n -o move /proc $ rootmnt /proc At the end of the script, the system switches to the real root filesystem: exec run-init $ rootmnt $ init “$@” $ rootmnt /dev/console >$ rootmnt /dev/console I’ve changed my code so that /proc/… files I used are open from the very beginning, and kept open until the end of the execution of usplash, and it seems to work. I’ve also been able to write a debug log for it, storing it in /dev/.initramfs/, which is a directory that is kept in that place all the time, so that whatever is stored there is available after the soot switch. That is the directory that usplash uses to store its FIFO nodes: usplash_fifo and usplash_outfifo. Maybe I can find a way to store core files there after a SEGFAULT error, setting the proper parameters with ulimit and /proc/sys/kernel/core_pattern. All I need to find out now is how to be able to reach the contents of /etc/… after the final rootsystem is mounted. I’ll tell you when I’ve solved that.

Nothing really worth noticing here, the Paris area being southward enough and not hit by this major storm over northern Europe. Many people still remember Dec 26th 1999 and have been very careful, indeed. I'm just listening to the morning news and am Seeing that UK, Belgium, Netherlands, Germany, Denmark and a part of northern France have not been as lucky as us here (this doesn't seem to be finished and more Eastern parts are still to be hit). The damages seem to be pretty high and so is the number of casualties. I hope that all you people are safe and well with no damage to your lives or belongings. Happy global warming...:-(... Please spread the word around: we are all responsible for this with our daily attitude with regards to the respect of our environment. Environment respect is no more (and has never been) a joke. This is a matter of survival for us and our children. Do us a favor: break one SUV a day...:-)

Erich mentioned a storm warning for Germany and the recommendation at his university to not do any lectures. Well... Here in the north we have quite some wind blowing, believe me... the first time I actually saw roof tiles been blown off the roof. Makes you feel very comfortable when walking home ;) Interesting: All universities in the neighbourhood have been closed and schools closed at 11:00am. Only we needed to stay till 7:00pm for our math course :( Wish us luck: We live in a attic floor flat and already lost some roof tiles. And according to the forecast it might still become stronger...

One of the bad things about moving to live in the west country is that we are now on the front line of any storms that leave the Atlantic for England. To make matters worse, we are on a hillside and some idiot put the boiler vent facing into the prevailing wind, so I have to relight it at least once each bad storm. Today's storm is the worst yet. Average wind speed is reported by TV as 35mph, gusting over 70. Anything that wasn't bolted down or very very heavy and hadn't already been blown away has now gone. I keep going out quickly to do things like add weights to the bin or wedge one of the garden tables against the fence, but I don't feel like fixing my bicycle and riding to town along the coast today. On the first trip out, as I was checking the roof for damage, one of the neighbours' six-foot fence panels flew off. On the second trip... well, this used to be a fence on the other side of the path by our back wall: Now it's just a concrete post surrounded by debris. If this is part of the storm heading for Erich Schubert then I think Munich has done the right thing.

This is the first time I can remember, that the university is recommending to not hold lectures and go home early. They are expecting the ministerials to formally close the university, like they did with schools at noon. This will be the strongest storm we've had in years, apparently (well, others have been similarly strong I think, but not as big). It's now 15:18, and when I look out of the window it's still surprisingly quiet. The trees are moving, but only slightly. But it's the wind protected side of the building. The university warning email said that they expect public transport - and Munich has a huge public transport system - to stop service at 18:00 "the latest". Guess I won't be able to go dancing tonight then. It would start at 19:00, and I need about 30-40 Minutes by subway to go there. I guess they will shut down subway to make sure noone gets stuck in the tunnels if there is a power loss. Such huge storms are a threat to power supply. [Update: 21:08 you can tell now it's a storm, but it's not bad here. But all train traffic is stopped in bavaria, grounding a few hundred people who didn't make it home in time. They've been taken care of. In Munich, busses and the subway are supposedly still in service. I went to go dancing, but there was a note on the door it's closed tonight; same for the karate training of a friend. From what I heard in the radio there were only few fatalities so far and limited damage, but we havn't reached the peak of the hurricane yet. Few reports of blackouts in some small towns. Schools remain closed tomorrow.] [Update: 19. Jan, noon - trains apparently still aren't back to schedule everywhere, but the system is recovering. Not many major damages reported in the media and not many fatalities. It's still windy. IMHO it was "typically german" how we handled the hurricane, urging people to stay at home and not risk much...]

The date: Friday, 19th of Jan.
The time: starting at around 21.00
The place: Olivers 21 (in Annankatu 21)
The who: DJ Mooch Vs. resident DJ
The what: Electronic music, starting with chillhouse and grooving towards progressive and electro house.
The why: because i/you can. And because i/you want it. ;)

One of the student groups I’m involved in at MIT is the SIPB, the Student Information Processing Board. It’s a volunteer computer group so old that they called it “information processing” back then. They run a bunch of different servers and provide lots of cool services for the MIT community. One of the things that they do is teach classes about various things related to computing during IAP, MIT’s Independent Activities Period. So back when I had just gotten started with the group, one of the members was like, “Hey! You want to teach an IAP class!” and, being a frosh, I was like, “Er, I didn’t know that… but, um, okay.” So I taught one about Debian, of course. This year’s topic was Giving Back: Contributing to Debian and the New Maintainer Process. It was a three-day series, as described here. The lengths of the talks varied, with the first day being ~45 minutes, the second being ~1.5 hours, and the last being ~30 minutes. All of the lecture materials can be found here. The audience was on the high side of technical, and a lot of the slides were more to nudge me into what I was talking about rather than to be really awesome slides. Which probably should have involved less text. The packaging crash course definitely drew a much larger audience than the first or third parts, which mostly consisted of people I know who work on Debian-Athena, the unexpected appearance of my friend Aaron Swartz who’s in town for a couple weeks, and a few faces that I didn’t know. Maybe next year I’ll try to plan something that just involves a more intensive packaging course. Because, although I procrastinated, pushed the original lecture dates back a week from original plan, and made my lecture slides on the day they were presented, I actually did have fun. And it’s good practice.

The snow we got a couple of days ago hasn't abated here in Montreal. We had a cold snap right after the snowfall, so temperatures have been around -20C for the last couple of days. Last night Maj had her French classes at the Montreal YMCA, and Micaela had spent the day seeing art museums and visiting bookstores downtown. (She's a poetry nut -- loves finding books by Canadian poets, francophone and anglophone, that she can't get at home in Melbourne.) So Amita and I went to meet her about halfway from our local Metro station, at the Pizzad lic on Ave Mont Royal. I covered Amita in about 10 layers of clothing, then put her on her little purple sled and dragged her up towards Mont Royal. She kept wanting to get up and walk herself ("Up!" is her newest and most insistent word), but when she was standing she wouldn't walk at all. So it was a long time getting to the restaurant. When we got there, Micaela was leaning against the front door shivering. Apparently Pizzad lic is out of business (bummer!). A graver cause for concern, however, was Amita's face: the parts showing around her scarf were tomato red from the cold. Gah! We rushed her home (crying all the way), and when I got her undressed she had a red stripe across the middle of her face like the people in those frozen pizza ads. I bathed her cheeks in cold water, and then gave her a hot bath, and by the time she was out she was calm and regular-colored. We got pizza delivered at home, which she enjoyed a lot. No permanent damage, as far as I can tell, except to my self-confidence as a competent parent. When Maj got home later that night, she reminded me that for extremely cold weather you have to put Vaseline on babies' cheeks to protect their delicate skin from the cold. Amita and I went to Loblaw's this morning to do some grocery shopping (in the car), which was a much more reasonable experience. Tonight for dinner I made pat chinois, a plate with baked mashed potatoes and ground beef known to English-speakers as shepherd's pie. (I make it with mushrooms and veggie beef.) Here in Quebec it's called "Chinese casserole", for unknown reasons. The best guess is that French Canadian lumberjacks worked at sites in the USA where it was common to have Chinese immigrant cooks. Confronted with a potato dish they didn't recognize, they assumed it was a meal from the cooks' home country. I don't know if this origin is true or not, but it sure is a good story. Anyways, it's good stick-to-your-ribs food, which you need on a night like this. When it gets down to -28C (as it will tonight), you need a lot of carbs running your internal furnace for you. tags: montreal snow cold shepherds pie pat chinois quebec babies amitajune

Piknic lectronik The good snow we're having means that one of my favourite events of the year is going to be white and cold and fluffy and fun. For the last few years, Piknic lectronik, the group that produces weekend outdoor parties on le Ste H l ne on the site of Expo 67, has done a single, crazy outdoor party in the dead of winter. This year, the party, called "Igloofest", is happening in the Vieux Port on the Quai Jacques Cartier. It's going to be two nights, January 19-20 (that's 29-30 Niv se for you aficionados of the French Revolutionary Calendar), from 5 to 11PM. We're going out on Friday night -- our pals from Ninjatune are part of the party, and our friend DJ Ghost Beard is on that evening. It should be a great time; I'm really looking forward to dancing in the snow and having vin chaud afterwards. tags: montreal piknic lectronik party dancing ninjatune winter snow

BarCampMontreal II: Camp Harder Just got the news from my blogroll: Sylvain Carle notes that the second BarCampMontreal will take place April 28th. That's going to be close for us; we'll be at the Wikitravel Get-together in Puerto Rico up until the 22nd. And we plan to fly there from Miami. But, hey: stranger things have happened. Our BarCamp last year was an absolute blast (see my follow-up on Journal/1 Brumaire CCXV); lots of fun people doing interesting things in fun ways, and then talking about it. I'd really like to be there for this next one. tags: barcamp montreal barcampmontreal wikitravel puerto rico

Louisianne I'm happy to see that in an alternative history universe called Ill Bethisad, the French Revolutionary Calendar is used in the North American francophone nation of Louisianne. On the downside, my city of Ville-Marie is in the royalist enclave of New Francy, which uses the boring old calendar. Ill Bethisad is an impressive alternative-history project, and the wiki format seems to really be conducive to its further development. Great idea, and nice to see the ol' FRC included. tags: alternative history french revolutionary calendar ill bethisad north america

Baby Lessig Congrats to Lawrence Lessig and family on the birth of a new son. tags: baby lessig

It appears that some people don't understand what right-wing means in terms of politics, apart from using it as a general term of abuse.

I recommend visiting the site http://www.politicalcompass.org/ to see your own political beliefs (as determined by a short questionnaire) graphed against some famous people. The unique aspect of the Political Compass is that they separate economic and authoritarian values. Stalinism is listed as extreme authoritarian-left and Thatcherism as medium authoritarian-right. Nelson Mandela and the Dalai Lama are listed as liberal-left.

I score -6.5 on the economic left/right index and -6.46 on the social libertarian/authoritarian index, this means that I am fairly strongly liberal-left. Previously the Political Compass site would graph resulta against famous people but they have since removed the combined graph feature and the scale from the separate graphs. Thus I can't determine whether their analysis of the politics of Nelson Mandela and the Dalai Lama indicate that one of those men has beliefs that more closely match mine than the other. I guess that this is because the famous politicians did not take part in the survey and an analysis of their published material was used to assess their beliefs, this would lead to less accuracy.

The Wikipedia page on Right-Wing Politics provides some useful background information. Apparently before the French revolution in the Estates General the nobility sat on the right of the president's chair. The tradition of politically conservative representatives sitting on the right of the chamber started there, I believe that such seating order is still used in France while in the rest of the world the terms left and right are used independently of seating order.

Right-wing political views need not be associated with intolerance. If other Debian developers decide to publish their political score as determined by the Political Compass quiz then I'm sure that we'll find that most political beliefs are represented, and I'm sure that most people will discover that someone who they like has political ideas that differ significantly from their own.

The most unique Christmas present I got this year was the cuckoo clock from my father's parents. There's something very cool about mechanical clocks that work by means of weights and gears instead of electronics: when the cuckoo goes off, you can actually watch energy being transferred from the weight to the cuckoo device, as the weight that powers it drops precipitously!

Unfortunately, the clock seems to lose about half an hour every twelve hours. Does the Lazyweb know any techniques for getting mechanical cuckoo clocks to keep better time? I don't mind resetting it once a week or so, but twice a day is a little excessive.

Several months ago, I set up a low-powered box to act as a fileserver and media center. I don't get cable TV and I have no interest in doing so, so I don't need a PVR. However, I do have a rather large music collection (and new speakers to play it on); I want to be able to put Internet radio on in the background (since we can't get NPR over the air), and a quick-and-dirty slideshow program for my digital camera photos could be nice too. So, I decided to try out the free media center, mythtv. I've summarized the notes I took here for the benefit of other people who don't watch TV.

Setup was fairly straightforward -- I installed the packages from debian-multimedia.org and configured them. I had a bit of trouble getting myth to actually start, but looking over the documentation apparently resolved it (my notes contain no details).

Mythtv has some very well-thought-out aspects. By all accounts, it makes an excellent PVR; since I don't watch TV, this is the last time I'll mention PVRs in this post. :) The interface looks exactly the way you want a TV-based system to look, with bright colors, big fonts and big interface elements. There's even a cute OpenGL mode with fancy screen transitions (I left them disabled because my video driver is unstable even without 3d effects running -- thank Via).

However, it became painfully obvious after a bit of use that MythTV is really meant as a TV program, with everything else being an afterthought. Here are just a few of the problems I noted:

• MythTV can't play internet radio; the functionality simply doesn't exist.
  
• You can do only one thing at once. Perhaps this is fine for TV, but given that it is not uncommon that I want to, say, play music while reading the news, or while ripping another CD, this is a gaping hole in functionality for me.
  
• MythTV can display news (RSS) feeds. However, the news feeds aren't in alphabetical order in either the viewer or the setup screen (where you pick what to see). This makes it rather painful to pick the feeds you want out of the dozens of presets.
  
• The built-in browser crashes with SIGABRT on startup, making the news feeds useless anyway.
  
• The built-in support for ripping flac files is confusing to activate (you have to pretend you're making an Ogg and choose "Perfect" quality!) and doesn't give you control over the process (for instance, replaygain can't be added to the ripped files).
  

That's just a small sampling of the problems I ran into. I ended up just setting up a normal desktop system with a wireless keyboard/mouse, and I'd recommend the same thing for anyone else who doesn't need a PVR. The non-TV features in Myth have a strong smell of being extras for people who occasionally switch away from the TV, rather than a well-integrated media system in their own right.

This morning at LCA Andrew Tanenbaum gave a talk about Minix 3 and his work on creating reliable software.

He cited examples of consumer electronics devices such as TVs that supposedly don't crash. However in the past I have power-cycled TVs after they didn't behave as desired (not sure if it was a software crash - but that seems like a reasonable possibility) and I have had a DVD player crash when dealing with damaged disks.

It seems to me that there are two reasons that TV and DVD failures aren't regarded as a serious problem. One is that there is hardly any state in such devices, and most of that is not often changed (long-term state such as frequencies used for station tuning is almost never written and therefore unlikely to be lost on a crash). The other is that the reboot time is reasonably short (generally less than two seconds). So when (not if) a TV or DVD player crashes the result is a service interruption of two seconds plus the time taken to get to the power point and no loss of important data. If this sort of thing happens less than once a month then it's likely that it won't register as a failure with someone who is used to rebooting their PC once a day!

Another example that was cited was cars. I have been wondering whether there are any crash situations for a car electronic system that could result in the engine stalling. Maybe sometimes when I try to start my car and it stalls it's really doing a warm-boot of the engine control system.

Later in his talk Andrew produced the results of killing some Minix system processes which show minimal interruption to service (killing an Ethernet device driver every two seconds decreased network performance by about 10%). He also described how some service state is stored so that it can be used if the service is restarted after a crash. Although he didn't explicitely mention it in his talk it seems that he has followed the minimal data loss plus fast recovery features that we are used to seeing in TVs and DVD players.

The design of Minix also has some good features for security. When a process issues a read request it will grant the filesystem driver access to the memory region that contains the read buffer - and nothing else. It seems likely that many types of kernel security bug that would compromise systems such as Linux would not be a serious problem on the HURD. Compromising a driver for a filesystem that is mounted nosuid and nodev would not allow any direct attacks on applications.

Every delegate of LCA was given a CD with Minix 3, I'll have to install it on one of my machines and play with it. I may put a public access Minux machine online at some time if there is interest.

Cycle shop owner and long-time club rider Mel Vasey was knocked down and killed by a car while on a club ride. Report from icLiverpool The comment about the road being dangerous because of a lack of cycle track sounds like a misquote or misunderstanding. The road is dangerous because car drivers aren't driving within their ability. Adding a cycle track won't change the road: if the driver really was blinded by low sun and driving beyond their ability, they could easily have strayed into a cycle track. Also, roadside cycle tracks are often kept to a damned sight worse standard than the roads (often 18mph top unladen speed on wide tyres - less if you're carrying or on road tyres) so end up being no safer in total.

Erich commented:

"Pbuilder is great (and cowbuilder even more so). First of all, it makes setting up and upgrading chroots easier (even easier than dchroot etc.), but it will also handle dependencies and do install/removals (well, technically it won't remove stuff, the chroot is just thrown away afterwards). That way, pbuilder helps getting build dependencies right, and ensures the package is currently buildable (not with some library package you still happen to have on your system, but that has been removed from Debian; not uninstallable for some reason etc.). This makes the job easier for porters, since a FTBFS is less likely to be an error in packaging by the maintainer... At some point I had like 6 pbuilder chroots... woody, sarge, unstable, woody with some backports, sarge with SELinux backports, unstable with experimental. Sure, we don't need debhelper either? After all, it just does some cp and mvs, doesn't it? There IS some benefit in having stuff automatized in a standard way; even though we could all do our chroots ourselves, I want to express my thanks to the pbuilder (and cowbuilder) authors and maintainers for making life EASIER for me. A lot easier. I could live without, but I would probably not keep that many chroots."

Ken Bloom added:

"One important feature of a pbuilder chroot is that pbuilder installs build-dependencies as you ask it to build debian packages, and removes them as soon as it finishes building the packages. In this sense, pbuilder is specifically intended to replicate the buildd environment, so you can find out whether your packages will break on a buildd (e.g. whether you've remembered to include all of the build-deps in debian/control, because things will break on the buildds if you forgot to add a build-dep because the build-dep was just lying around on your system (or in your unstable chroot)."

Sven M ller wrote:

"Well, pbuilder has several benefits, but the most important one to me is that it restarts from a clean system (only base packages + build-essentials installed) on each build. Sure this adds to the time needed for the build, but it also makes sure that I get all build-deps right and that the whole build process is as reproducible as possible."

Ben Hutchings commented:

"The major difference between pbuilder's approach and simply building in a chroot'ed installation is that pbuilder tries to build on a minimal system plus the specified build-dependencies. If you always build with pbuilder or similar it's much less likely that you will miss a build-dependency or otherwise produce a package that can't be auto-built elsewhere."

I take the clean chroot point as a clear benefit, but it still strikes me that there are easier ways to do the same thing (rsync --delete) without all the waiting around for pbuilder on my slow mipsel. I guess that's the difference with debhelper: debhelper use doesn't seem to slow me down.

I blogged 5 days ago about the annoying beeper and different methods that were supposed to turn it off.

I asked for a clean solution, but I received suggestions for some hacks. Now I decided to make a new post since there was a comment added today and I remembered about a possible hack (dpkg-divert) I was thinking about.

Now here are some of those hacks and the reason behind rejecting them.

• I thought at some point of using dpkg-divert, as opposed to deleting the module, but this is suboptimal. And I am not sure dpkg-divert would work for such a whacked "use case"
  
• Using a hardware method is also suboptimal, for several reasons:
• I will hear the beep if I don't plug in the dummy jack
• the same goes when I am using a headset - the volume is loud and seems to not be affected by the general sound volume, so it would be disruptive and annoying while listening music and typing the wrong command;
• the Intel HDA sound driver lacks headset jack detection in the current Debian kernel. This means there is no effect if I plug such a jack
  
• The default beeping should be disabled by default, still, that would partly solve my problem. I could set that in my .inputrc file or system wide, still, that would mean a beep on some occasions (like gdm log in) - not sure if this would mean it would be more scarier, since it happens rarely or not :-)

Still, the question remains, why don't the originally proposed methods work, especially blacklisting?

Update: the headphones jack works with some small changes, bug submitted (#407252)