I'm busy re-working how I handle backups of my personal files. A very useful recent discussion on some available features and technologies is at Theodore T'so's blog: http://thunk.org/tytso/blog/2009/01/12/wanted-incremental-backup-solutions-that-use-a-database/. From that post I discovered a package 'archfs' which provides a FUSE-powered filesystem view of an rdiff-backup history. I found a stale ITP for this package and have adopted it, so keep your eyes out for that. Looking at how I am going to approach things, I think the Debian package of anacron might need some work. I'm planning on looking at the issues there a bit more closely and feeding back to the maintainer when I do.

Yeah, yeah, I may be living under a rock these days. Anyway, I just noticed that the GFDL v1.3 is out; it has been for four months or so. There aren't many changes; apart from some minor wording changes that have little to no effect on the meaning of the license, there are two new sections: the first adds details on what happens when you violate the license (basically, it gets temporarily terminated, which can become permanent if you do not fix it in a reasonable timeframe or under some other circumstances); the second allows one to change the license from GFDL to CC-BY-SA under certain circumstances (where "certain circumstances" in practice basically means "you're wikipedia", although it isn't written as such). And that's it. Nothing groundbreaking, nothing to follow up on the FDLv2 discussion drafts that were released about two-and-a-half years ago. Me, I find that disappointing. When the initial discussion drafts were put out on the web, I was thrilled; I spent some time reading them and providing comments. However, nothing happened on those drafts beyond initially getting them out there. It would appear that today, the FSF has even managed to lose the comments that were made. I guess they don't really care about the FDL as much as they do about the GPL.

After quite successful debut in Google Summer of Code last yaer (even not directly, but though MySQL project), where both projects ended quite successfully and brought great addition to our code base, it's time to try to get again on the track. Hopefully we will manage to be direct participants this year. If you have some great ideas which are missing in phpMyAdmin, feel free to fill them either in feature tracker or directly into our ideas page.

In case you ve been living under a rock these past years, I shouldn t have to tell you what this is about :). Well, just in case.
The Google Summer of Code (GSoC) is an international program that offers student developers stipends to write code for various open source software projects. Debian has participated since 2006, mentoring dozens of students on Debian projects. The important part of the 2009 edition of the Google Summer of Code is going to start next week with the Organizations application period (March 9th). By that time, we should have listed a reasonable number of ideas on the dedicated wiki page. We will try this year to improve on the performance of the previous years, starting first with more and more dedicated manpower. If you have some time to spare to help manage our Summer of Code bid this year, we can make it a much better experience for the students and for Debian. Help is immediately needed in many areas. Some examples:

• Map out which areas in Debian could benefit from a Summer of Code project and connect the right people with the right projects ideas
• Ideas, Ideas, Ideas for Summer of Code projects

By mid-March, we will need:

• Dedicated documentation to present Debian to the prospective student
• Publicity material to promote the Summer of Code at Debian
• Ideas, Ideas, Ideas for Summer of Code projects

Further in the spring:

• Mentors, people to review proposals, do interviews
• Ideas, Ideas, Ideas for Summer of Code projects

In the summer:

• Mentoring students
• Testing and feedback for projects
• Internal communication with the community

As you can see, there is much work ahead. It s time to pitch out your favorite pet project
Remember! The Summer of Code has become a prominent outreach forum for open source organizations. It puts a spotlight on each of them to provide a well-rounded and deep experience of open source development. Right now, you can help with the Wiki, join us on IRC on #debian-soc on OFTC or join the mailing-list at soc-coordination on alioth. The short flyers-friendly URL for the Summer of Code at Debian is : <http://wiki.debian.org/gsoc>. Publicize it! See you this summer!

I would like to applaud Colin Watson s excellent post on bad bug triage technique. Thank you, Colin. It needed to be said I have experienced most of those problems myself, in Debian.

After a long hiatus for various reasons, I finally had the chance to try my hand at loading a TeleMetrum board today! Sadly, I wasn't able to completely load any boards, because I somehow ended up with the wrong Digi-Key part numbers for 4 capacitors, one of which is a critical value. I placed an order for the missing parts and a few other bits we'll need eventually, hopefully they'll be here in a couple days and I can try to load a board with all the parts. Instead, what I did today was a a partial load of a board with the goal of testing the various power supplies. Seemed like a good idea, since I've had my share of odd problems with power supplies in the past. This also gave me a chance to try out my solder paste stencil, get some experience hand-placing the tiny 0402 passive parts, and an excuse to see if I could hit the solder reflow temperature profile adequately with my electric cooking skillet and IR non-contact thermometer. The good news is that it all worked right the first time! We're successfully charging a LiPo battery from USB power, and successfully making 3.3 volts for the electronics from that. The resistor divider designed to allow the LiPo battery voltage to be sampled by the CPU's analog to digital converter is also working fine. A few observations are in order, however. Getting the right amount of solder paste down on the board requires some finesse with the spreading blade and the stencil. I think the paste was a bit heavy around the CC1111 footprint, as I ended up with some bridged pads. Since I didn't load the actual CPU part, it could just be that not having something real there to wick up some solder meant there was enough to form the bridges. Don't know. The amount of solder on the ground pad in the middle of the chip looks good, though! The 0603 sized LED in the power supply circuit was the only part that didn't self-align correctly. I may have had it a bit too far to one side. The pads on the part have notches in the end, and it looks like one side of each is more or less centered, so I think surface tension did the best it could with what I gave it to work with. The LED soldered ok, isn't shorting to anything else, and clearly works fine... but I'd be happier if it were aligned better. Found and fixed a solder bridge between two pins on the surface-mount USB connector before first application of power. Could be further data that the paste layer was a bit too thick. On the other hand, I had to wiggle the connector around a bit to get it aligned correctly, so I may have smudged the paste into a bridge while doing that. I also note that there's some visible flux left on the surface of the solder, particularly on big paste areas like the feet of the USB connector. I suspect this means I didn't dwell long enough at either or both of the preheat or ultimate reflow temperatures. Since all the parts clearly soldered adequately to function, I'm still pretty happy... but since the rockets we fly experience violent accelerations during boost, this is something I'll play with on future reflows. All in all, a great way to spend an afternoon, and a big step forward for the TeleMetrum project!

I have been thinking some more about how to improve ucf. One of the things that struck me was that based on my earlier analysis there are only five actions that ucf can take, and the decision about the actions depends on the state it finds the configuration file in on the target machine, and there are only eight of those. Now, thinking back to my days as a VLSI designer back in the halcyon days of electrical engineering, This is a pretty simple state machine. It is not as neat as it could be (where just three variables would be needed to keep track of things, but still, it bears investigation. This would be a way for converting the current procedural ucf into a functional programming model. Hop over here for a look at how that went it was fun, and afforded me an opportunity to demonstrate how well org handles snippets.

I'm supporting a medium-sized (~70 regular clients and a half-dozen servers) LAN. It's a single logical ethernet segment, but it's built as a tree of cascaded switches. DHCP service is provided by a single host running ISC's DHCPD (via dhcp3-server). DHCP itself is one of the single points of failure in the network layout. i'd really like to make this DHCP server redundant (so that i can take that host down for service if needed and leave the rest of the network intact). However, reading dhcpd.conf(5) makes me pretty worried that the failover stuff is not well-tested or widely deployed. I've read Paul Heinlein's Failover with ISC DHCP, which makes it look not unreasonable, but i was wondering if people have other preferred mechanisms for providing DHCP redundancy. Do you have failover DHCP set up for any LAN that you manage? If so, what do you use? Are there any gotchas to watch out for? I'm also concerned about the security implications. On a network that's not using IPSEC, i don't see any mechanism for the two DHCP servers to properly mutually authenticate. Is it really just by IP address? Could someone spoofing the IP address of one host corrupt the state of the other DHCP server? (i'm less concerned about them keeping network traffic private, since most of what they communicate is likely to go out in the clear on the wire anyway). Am i missing some clever authentication technique? From a security point of view, i understand that there are more severe security problems with DHCP itself, of course (the protocol requires that the client trust the (unauthenticated) server), but that doesn't seem likes a good reason to introduce an opportunity to compromise any given server directly. Your thoughts on DHCP redundancy?Tags: dhcp, failover, redundancy

I've not had that many problems with network-manager, until now. The new version in unstable is just completely broken on my machine. Sadly, I can't report why it failed as I inadvertently closed the terminal with the relevant output.

Suffice to say, nm repeatedly got the wrong IP address, an invalid route and failed to set a usable nameserver. I've had those problems before with wireless but when this started happening with a wired connection (which had always previously worked), it was time to move on.

I've noticed people using wicd instead and decided I didn't have time to debug nm, I have a worksession starting in Cambridge on Sunday and a shed load of work to do before that, all of which requires a stable network connection.

Installing wicd replaced network-manager which was nice, (nm has always had problems working with any other network config so this allowed me to skip the removal of nm myself). wicd initially had a few issues - which I managed to pin down to the remnants of the broken nm config and steps that I'd taken to try to fix it.

Turns out that I may have some unresolved issues with my router - even with wicd I had problems getting a route over wireless. However, wicd allows suitable configuration that both works and is easy to keep discrete from other configs. Nice work. I have to set a static IP over wireless in order to set a valid route (and netmask). Looks like the DHCP implementation on the router is borked.

I'm sticking with wicd though - the interface is better for what I need, the icon has a useful traffic indication as well as signal strength and it's worth pursuing to see if the previous intermittent nm errors affect wicd.

Last night I managed to finish up a rather satisfying improvement to ext4 s inode and block allocators. The ext4 s original allocator was actually a bit more simple-minded than ext3 s, in that it didn t implement the Orlov algorithm to spread out top-level directories for better filesystem aging. It also was buggy in certain ways, where it would return ENOSPC even when there were still plenty of inodes in the file system. So I had been working on extending ext3 s original Orlov allocator so it would work well with ext4. While I was at it, it occurred to me that one of the tricks I could play with ext4 s flex groups (which are higher-order collection of block groups), was to bias the block allocation algorithms such that the first block group in a flexgroup would be preferred for use by directories, and biased against data blocks for regular files. This meant that directory blocks would get clustered together, which cut a third off the time needed for e2fsck pass2:

Comparison of e2fsck times on an 32GB partition

Pass	ext4 old allocator						ext4 new allocator
	time (s)			I/O			time (s)			I/O
	real	user	system	MB read	MB/s		real	user	system	MB read	MB/s
1	6.69	4.06	0.90	82	12.25		6.70	3.63	1.58	82	12.23
2	13.34	2.30	3.78	133	9.97		4.24	1.27	2.46	133	31.36
3	0.02	0.01	0	1	63.85		0.01	0.01	0.01	1	82.69
4	0.28	0.27	0	0	0		0.23	0.22	0	0	0
5	2.60	2.31	0.03	1	0.38		2.42	2.15	0.07	1	0.41
Total	23.06	9.03	4.74	216	9.37		13.78	7.33	4.19	216	15.68

As you may recall from my previous observations on this blog, although we hadn t been explicitly engineering for this, a file system consistency check on an ext4 file system tends to be a factor of 6-8 faster than the e2fsck times on an equivalent ext3 file system, mainly due to the elimination of indirect blocks and the uninit_bg feature reducing the amount of disk reads necessary in e2fsck s pass 1. However, the ext4 layout optimizations didn t do much for e2fsck s pass 2. Well, the optimization of the block and inode allocators is complementary to the original ext4 fsck improvements, since it focuses on what we hadn t optimized the first time around: e2fsck pass 2 times have been cut by a third, and the overall fsck time has been cut by 40%. Not too shabby! Of course, we need to do more testing to make sure we haven t caused other file system benchmarks to degrade, although I m cautiously optimistic that this will end up being a net win. I suspect that some benchmarks will go up by a little, and others will go down a little, depending on how heavily the benchmark exercises directory operations versus sequential I/O patterns. If people want to test this new allocator, it is in the ext4 patch queue. If all goes well, I will hopefully be pushing it to Linus after 2.6.29 is released, at the next merge window.

For comparison s sake, here is a comparison of the fsck time of the same collection of files and directories, comparing ext3 and the original ext4 block and inode allocator. The file system in question is a 32GB install of Ubuntu Jaunty, with a personal home directory, a rather large Maildir directory, some linux kernel trees, and an e2fsprogs tree. It s basically the emergency environment I set up on my Netbook at FOSDEM. In all cases the file systems were freshly copied from the original root directory using the command rsync -axH / /mnt. It s actually a bit surprising to me that ext3 s pass 2 e2fsck times was that much better than e2fsck time under the old ext4 allocator. My previous experience has shown that the two are normally about the same, with a write throughput of around 9-10 MB/s on for e2fsck s pass 2 for both ext3 file systems and ext4 file systems with the original inode/block allocators. Hence, I would have expected ext3 s pass2 time to have been 12-13 seconds, and not 6. I m not sure how that happened, unless it was the luck of draw in terms of how things ended up getting allocated on disk. So I m not too sure what happened there, but overall things look quite good for ext4 and fsck times!

Comparison of e2fsck times on an 32GB partition

Pass	ext3						ext4 old allocator
	time (s)			I/O			time (s)			I/O
	real	user	system	MB read	MB/s		real	user	system	MB read	MB/s
1	108.40	13.74	11.53	583	5.38		6.69	4.06	0.90	82	12.25
2	5.91	1.74	2.56	133	22.51		13.34	2.30	3.78	133	9.97
3	0.03	0.01	0	1	31.21		0.02	0.01	0	1	63.85
4	0.28	0.27	0	0	0		0.28	0.27	0	0	0
5	3.17	0.92	0.13	2	0.63		2.60	2.31	0.03	1	0.38
Total	118.15	16.75	14.25	718	6.08		23.06	9.03	4.74	216	9.37

Vital Statistics of the 32GB partition

312214	inodes used (14.89%)
263	non-contiguous files (0.1%)
198	non-contiguous directories (0.1%)
	# of inodes with ind/dind/tind blocks: 0/0/0
	Extent depth histogram: 292698/40
4388697	blocks used (52.32%)
0	bad blocks
1	large file
263549	regular files
28022	directories
5	character device files
1	block device file
5	fifos
615	links
20618	symbolic links (19450 fast symbolic links)
5	sockets
312820	files

Related posts (automatically generated):

1. Fast ext4 fsck times This wasn t one of the things we were explicitly engineering...
2. Wanted: Incremental Backup Solutions that Use a Database Dear Lazyweb, I m looking for recommendations for Open Source backup...
3. Ext4 is now the primary filesystem on my laptop Over the weekend, I converted my laptop to use the...

Last night I managed to finish up a rather satisfying improvement to ext4 s inode and block allocators. The ext4 s original allocator was actually a bit more simple-minded than ext3 s, in that it didn t implement the Orlov algorithm to spread out top-level directories for better filesystem aging. It also was buggy in certain ways, where it would return ENOSPC even when there were still plenty of inodes in the file system. So I had been working on extending ext3 s original Orlov allocator so it would work well with ext4. While I was at it, it occurred to me that one of the tricks I could play with ext4 s flex groups (which are higher-order collection of block groups), was to bias the block allocation algorithms such that the first block group in a flexgroup would be preferred for use by directories, and biased against data blocks for regular files. This meant that directory blocks would get clustered together, which cut a third off the time needed for e2fsck pass2:

Comparison of e2fsck times on an 32GB partition

Pass	ext4 old allocator						ext4 new allocator
	time (s)			I/O			time (s)			I/O
	real	user	system	MB read	MB/s		real	user	system	MB read	MB/s
1	6.69	4.06	0.90	82	12.25		6.70	3.63	1.58	82	12.23
2	13.34	2.30	3.78	133	9.97		4.24	1.27	2.46	133	31.36
3	0.02	0.01	0	1	63.85		0.01	0.01	0.01	1	82.69
4	0.28	0.27	0	0	0		0.23	0.22	0	0	0
5	2.60	2.31	0.03	1	0.38		2.42	2.15	0.07	1	0.41
Total	23.06	9.03	4.74	216	9.37		13.78	7.33	4.19	216	15.68

As you may recall from my previous observations on this blog, although we hadn t been explicitly engineering for this, a file system consistency check on an ext4 file system tends to be a factor of 6-8 faster than the e2fsck times on an equivalent ext3 file system, mainly due to the elimination of indirect blocks and the uninit_bg feature reducing the amount of disk reads necessary in e2fsck s pass 1. However, the ext4 layout optimizations didn t do much for e2fsck s pass 2. Well, the optimization of the block and inode allocators is complementary to the original ext4 fsck improvements, since it focuses on what we hadn t optimized the first time around: e2fsck pass 2 times have been cut by a third, and the overall fsck time has been cut by 40%. Not too shabby! Of course, we need to do more testing to make sure we haven t caused other file system benchmarks to degrade, although I m cautiously optimistic that this will end up being a net win. I suspect that some benchmarks will go up by a little, and others will go down a little, depending on how heavily the benchmark exercises directory operations versus sequential I/O patterns. If people want to test this new allocator, it is in the ext4 patch queue. If all goes well, I will hopefully be pushing it to Linus after 2.6.29 is released, at the next merge window.

For comparison s sake, here is a comparison of the fsck time of the same collection of files and directories, comparing ext3 and the original ext4 block and inode allocator. The file system in question is a 32GB install of Ubuntu Jaunty, with a personal home directory, a rather large Maildir directory, some linux kernel trees, and an e2fsprogs tree. It s basically the emergency environment I set up on my Netbook at FOSDEM. In all cases the file systems were freshly copied from the original root directory using the command rsync -axH / /mnt. It s actually a bit surprising to me that ext3 s pass 2 e2fsck times was that much better than e2fsck time under the old ext4 allocator. My previous experience has shown that the two are normally about the same, with a write throughput of around 9-10 MB/s on for e2fsck s pass 2 for both ext3 file systems and ext4 file systems with the original inode/block allocators. Hence, I would have expected ext3 s pass2 time to have been 12-13 seconds, and not 6. I m not sure how that happened, unless it was the luck of draw in terms of how things ended up getting allocated on disk. So I m not too sure what happened there, but overall things look quite good for ext4 and fsck times!

Comparison of e2fsck times on an 32GB partition

Pass	ext3						ext4 old allocator
	time (s)			I/O			time (s)			I/O
	real	user	system	MB read	MB/s		real	user	system	MB read	MB/s
1	108.40	13.74	11.53	583	5.38		6.69	4.06	0.90	82	12.25
2	5.91	1.74	2.56	133	22.51		13.34	2.30	3.78	133	9.97
3	0.03	0.01	0	1	31.21		0.02	0.01	0	1	63.85
4	0.28	0.27	0	0	0		0.28	0.27	0	0	0
5	3.17	0.92	0.13	2	0.63		2.60	2.31	0.03	1	0.38
Total	118.15	16.75	14.25	718	6.08		23.06	9.03	4.74	216	9.37

Vital Statistics of the 32GB partition

312214	inodes used (14.89%)
263	non-contiguous files (0.1%)
198	non-contiguous directories (0.1%)
	# of inodes with ind/dind/tind blocks: 0/0/0
	Extent depth histogram: 292698/40
4388697	blocks used (52.32%)
0	bad blocks
1	large file
263549	regular files
28022	directories
5	character device files
1	block device file
5	fifos
615	links
20618	symbolic links (19450 fast symbolic links)
5	sockets
312820	files

Related posts (automatically generated):

1. Fast ext4 fsck times This wasn t one of the things we were explicitly engineering...
2. Wanted: Incremental Backup Solutions that Use a Database Dear Lazyweb, I m looking for recommendations for Open Source backup...
3. Ext4 is now the primary filesystem on my laptop Over the weekend, I converted my laptop to use the...

This week and next week are Fairtrade Fortnight. As I ve mentioned in discussions at the Co-operative Group, there are some drawbacks to Fairtrade (most of which can be overcome by trading with co-operatives locally), but it is worth supporting fairtrade overall. The featured event this year is Go Bananas for Fairtrade, an attempt at world-record banana-eating on 6-7 March. I don t like bananas much, but I ll eat them cooked, so I ll be joining in. If you want to get involved and do something else, there is an events calendar on the FtFn site.

So, DebConf 10 will be held in New York City! Congratulations to the NYC bid team, now DC10 local team, which managed to provide a sound proposal for 2010. As time allows it, I ll be happy to help out and be there! I d also like to congratulate Boston s bid, who provided an outstanding proposal, and also the rest of Quito s team, whose bid I led: I think we provided an extraordinary bid to host an important event as DebConf in an amazing city as Quito, and as long as we can keep guaranteeing extraordinary quality, we ll be glad to present the bid for future DebConfs. Finally, the decision was taken after a long meeting, where we as a Project learnt useful things for future decision meetings. So, DC11 bidders, keep up the good work and enjoy the ride!

I was going to reply to this in the mailing list, but after I spent half an hour furiously typing this, I thought it might be better to put it into a blog, for a slightly wider audience, perhaps a more permanent life and partly in an effort to end this thread on a more or less constructive note. The backchat for this is that the LCA 2009 video has started to go up on the web, and some talks have some gaps in the audio stream... Russell Coker wants to make a constructive suggestion, as follows: On Wed, 2009-02-25 at 18:02 +1100, Russell Coker wrote:
>
> I've pasted in the below paragraph (the third time I've included it in this
> thread) to reiterate my point. Note that I am not asking you to re-do any
> videos, I am making a suggestion for future people.
>
> # I suggest that in future when preparing such videos the sections with no
> # sound be omitted and replaced by a short note explaining the omission,
> # something like "sorry, due to technical difficulties four minutes of sound
> # were not available". Having a second ogg file for the lip-readers would be
> # an option although I expect that the demand would be minute.
> As someone who has not been at all involved with the production of the LCA videos, but who has been intimately involved with the process of streaming DebConf 6, 7 & 8, I think this sort of additional effort will only happen if people voluntarily do it themselves. Just the task of *watching* all of the produced videos is a huge job for one individual, but as a community of individuals it is quite likely that at least one individual in the community watches each video. If each person who was offended by the quality of post-production work took it upon themselves to fix up only one video then it is probable that we would see some changed. Otherwise I'm afraid it is unlikely. Further in his e-mail, Russell Coker wrote:
>
> My observation was that the microphones were put down AFTER they ceased
> operating. A non-functional lapel microphone is no better than a non-
> functional hand-held microphone.
>
> Having a large supply of new batteries would be one way of alleviating the
> problem (I believe that some of the instances were due to flat batteries).
> Another possibility is having two microphones on hand so that if one died the
> other could be turned on.
>
> A wired microphone that doesn't rely on battery power would probably be the
> most reliable option. That of course might not fit with OH&S issues. Most speakers are uncomfortable / unfamiliar with wired microphones. Spares are essential, of course, but the problem can usually be avoided by having a checklist for the audio person to confirm several things: Before the start of the talk:

• check that batteries are good enough to last for the full length of the coming talk.
• check sound levels are correct for this speaker
• confirm sound is going through to recording
• check the speaker knows how to turn the mic off/on

At the start of the talk:

• confirm sound is going through to recording

At the end of the talk:

• Turn the mic off to save battery.

There are probably a couple of things that I've missed, but if you start with a checklist you pretty soon modify it into a *good* checklist, and it *really* helps when people are under fire. In fact lapel mics are not the best microphones for these kinds of presentations. The best mics are the ultra lightweight 'headset' models which place a the mic near to the speakers mouth. These do not suffer when the speaker turns their head hard to the left or right, at which points a lapel mic stops getting their speech. They also work well with that more hirsute minority so over-represented in our particular community (alas, that this set no longer includes Bdale :-) Of course DebConf has a large team of volunteers for streaming the conference, and has developed these kinds of procedures over a number of years. At DebConf there are usually only two main streams, each of which involves:

• The director, operating the video mixer
• Speaker camera operator
• Audience camera operator
• Slides to video convertor
• Sound mixer operator
• Talk timer, to warn speakers at t-10, t-5 & time is up.
• Two roving people responsible for getting audience mics to people talking in the room.

Ideally that really is 7 people (times two streams), and you can get by if you can't find all of the last three, but the other four are increasingly desirable. We mostly manage to do that with volunteers for two streams at DebConf, but for five or more streams at LCA it is inevitably a lot harder, and the quality necessarily has to be cut back to match the resources available. While it is true that sound is critical to this communication, it is unfortunately also true that most people's (even most geek's) eyes glaze over when presented with a mysterious box with a mere 6 sliding potentiometers, let alone when there are 36 of them, each associated with another 8 rotary knobs, and a rats nest of cables worthy of the worst network nightmare they've seen, and where everything appears to be literally held in place with duct tape. So it is not so surprising then that while it is relatively easy to find a gadget mad geek capable of operating a camera, or even experienced with operating a camera, finding people with experience operating a sound mixer is an order of magnitude harder. At LCA the operation appears superficially to often involve a (single) speaker camera operator with a very basic sound mixer which has been configured once by an overworked person who is unobtainable during the actual talk to solve any audio problems. These people are volunteers, and are doing their best, but it simply isn't possible to get a consistently high quality of video and audio in those circumstances. So as one of the organising committee for LCA 2010 in Wellington I will be watching what we do, and although I don't intend to get personally involved in the video production (I've got plenty of other stuff on *my* plate :-) I do intend to provide what advice and assistance I can. I know that we hope to have some professionals involved (as volunteers), but how many volunteers, and with what levels of skill & experience, we are unlikely to know until much closer than the date. I'll also personally try and get a run-down on all of the audio equipment so that in an emergency, if I happen to be available, I can sub as a sound mixer operator. So we will try and do better in Wellington in 2010. Come to the conference, though, because we can make no guarantees, and if you do come to Wellington, and you see a single cameraman, and you know something about running a sound mixer, then perhaps you can come and volunteer to help out in that capacity, for the talks you are attending anyway. We'd really appreciate the help. And finally I must say thanks, in particular, to Holger Levsen for all the learning I have gained since joining the videoteam at DebConf5 in Helsinki in 2005. And too, to all of those past conference teams (LCA, DebConf and otherwise) who have put their best efforts into providing videos of the talks I couldn't see in person. I know it's a bloody hard job, and often a less high profile one, so:

Thank You.

I have been meaning to write this up for a long time now, since I vaguely made a promise to do so last Debconf. I have also been wondering about the inefficiencies in my work-flow, but I kept postponing my analysis since there were still large gaps in my packaging automation since I moved off Arch as my SCM of choice. However, recently I have taken a sabbatical from Debian, so I ve had time to complete bits and pieces of my package building framework, enough so that I could no longer justify putting off the analysis. I tried writing it up, but the result confused even me; so I instead recorded every shell command during a recent series of packaging tasks, and converted that into a nice, detailed, activity diagram that you see over here. This is as efficient a work-flow as I have been able to come up with. details here Along with a git commit hook script, that parses the commit log and adds pending tags to bugs closed in the commit, the figure above represents my complete work-flow down to the details of every cd command I executed. I think there are too many steps still. Feedback and commentary would be appreciated, as well as any suggestions to improve efficiency.

• cyrus-imapd-2.2
• heimdal
• kolab-cyrus-imapd
• netatalk
• nvi
• jabberd2
• ldiskfsprogs

There has been some discussion on the Debian development mailing list about adding hooks into ucf, to allow people to do things like committing files into different SCM branches. So, I thought I would help people out by letting them tell me where hooks would be useful, and so decided to do an activity diagram for ucf. Gawd, what a mess. I mean, I wrote this thing, and it boggles even my mind. See the figure for how horrendous code can get when it grows organically. So, I decided to re-factor/redesign ucf, see if I could create a less complex activity diagram. On analysis, it turns out that ucf has just five actions it may perform, and which action it takes depends on which of eight possible states the configuration file is in. Gory details follow

Last week, I couldn't resist and bought myself an Acer Aspire One (AOA 150Ab) netbook. It has 1G RAM, 120G HDD, unfortunately needs a fan, and is the model without 3G modem. It comes with Linpus Linux pre-installed. Looks quite nice, but is obviously ultimately the wrong OS ... Besides, it's locked down quite a bit, there's not even an easy way to start a terminal :-) I still have kept it, in a dual-boot configuration, to play around or show to people. Installing Lenny went very well, and to make things more fun I'm running quite a few things from experimental: KDE 4.2, xorg 7.4 (1:7.4~5 right now) and Oo.org 3. And, to get DRI2, also the 2.6.28 kernel from the newer-than-sid repository of the kernel team (2.6.28-2~snapshot.12850, but I hear 2.6.28 has now been uploaded.) While the whole thing is fun to use and didn't make any real problems, there are a few remaining issues (yes, this is a Dear Lazyweb posting, feel free to comment. I'll try to add updates to this article as this progresses):

• Power events (power button, battery level critical) are handled by two sets of scripts. Not sure if the blame lies with acpid, acpi-support or KDE for this one. Symptom: when setting up, in KDE, that the power button should bring up the logout dialog, this results in: the power button does indeed show the logout dialog, but then immediately the system is shut down. Adding an exit 0 in /etc/acpi/powerbtn-acpi-support.sh before the final shutdown command in that file fixes this, though. Similarly, the battery critical event brings up a warning that the system will soon be forcibly suspended and then immediately suspends to RAM. (I'll have to investigate if there's already a bug about this in the bts.)
• The X server has quite a few issues. It sometimes blanks the display without any reason. Causing any of the fancy full screen effects (like present windows ) to happen sometimes fixes this, sometimes a quick suspend to RAM and wakeup cycle fixes it. Sometimes it does not and I need to reboot (and I have yet to set up a hotkey for log out without questions.) Also, the screen stays black after a switch back from a text console, and after logout. Oh, well, I guess I'll just wait a few Intel driver and perhaps kernel releases (not sure: do I already have kernel modesetting, btw?)
• KDE sometimes complains that X compositing is too slow and disables it. I immediately re-enable it, because while some of the effects do indeed demonstrate the limits of the graphics hardware, I've become used to things like present windows and, especially on the small screen, the screen magnifier.
• Also a feature of the new X server is HAL powered handling of input devices, which left me without my desired keyboard layout in X. After some hunting around at places like #447666 I found a very simple x11-input.fdi file somewhere I can't remember and installed that:

  <?xml version="1.0" encoding="UTF-8"?>
  <deviceinfo version="0.2">
    <device>
      <match key="info.capabilities" contains="input.keys">
        <merge key="input.xkb.layout" type="string">ch</merge>
        <merge key="input.xkb.variant" type="string">de</merge>
      </match>
    </device>
  </deviceinfo>
  

  I now realize that just installing hal-info from squeeze or sid might also fix the issue.
• Also related to the new input hotplugging: how do I pass options to the synaptic driver? Probably another XML file for HAL, haven't hunted for this yet. As it is, the touchpad works but tapping won't click, and there's no scrolling on the edges of the pad. Update: Mark points me to the correct HAL invocation, thanks.. Now I only need to find the right values for all the options...(at least tapping doesn't work yet when I use the same values as the Linpus installation uses.)
• The various Fn key keyboard functions situation is very inconsistent. Some of the keys just work (Num-lock, the completely useless Scroll-lock, Home, End, volume up, down; Even brings up a graphical notification, blank screen). Mute/unmute is caught by userspace but doesn't work correctly: it just displays the current volume instead of muting/unmuting audio (it also shows HalPower::slotButtonPressed: Unknown button type in .xsession-errors. Same message but no effect whatsoever for the Zz sleep button.) The deactivate touchpad key works but gets unknown key pressed/released kernel messages, as does the (off-keyboard) WiFi power switch. Switch video output only shows the unknown key pressed/released messages but doesn't do anything. Finally, some work but are also mapped to keycodes where they shouldn't be (dim screen is also mapped to ^@ , it appears, while increase screen brightness is mapped to .)
• WLAN only works with the options acer_wmi wireless=1 option, and without the LED, as described on the Debian Acer Aspire One wiki page. This is with the ath5k driver, haven't tried the MadWifi one yet.
• Powertop claims that the camera is always on, unloading all related modules () seems to solve this (at least, powertop doesn't complain anymore, and power is down by 0.5W.) Powertop also claims that USB autosuspend is off, but it's just set to 2 instead of 1 which if I read this correctly is the timeout to use for USB devices.
• KDE4 doesn't have a network manager applet frontend in Debian. I guess this is an upstream problem. (Although I note that the OpenSUSE people already have an applet ;-) Update: Sune tells me it's in NEW already, thanks.
• While network-manager (lenny version) does work properly and switches between wired and wireless as needed, it strangely keeps sending out DHCP requests on eth0 even though no cable is attached (and mii-tool correctly reports no link.)

Ok, this has become rather a long list. But at least, as you can see, it's mostly minor issues, and hopefully a few where it's just missing configuration. One other issue is battery life: I see that there should be a large battery available for this thing. If it doesn't cost me as much as the whole netbook again, I'll seriously have to think about this... The 3-cell battery does last about 2.5h (and has, right now, uncovered a little bug where the battery monitoring applet tells me No AC adaptor plugged in, battery capacity: 50%, charging . Whee! I have a perpetuum mobile! I'm gonna be RICH!)

Just discovered 'wicd' - a wireless connection manager similar to network manager. I've never liked NM much (there's a couple of bugs open which explain why). So far wicd seems to work well, although it does not support VPNs. Time will tell if it suffers many of the problems that soured NM for me!

This release is mostly bug fixes that have accumulated over the past couple of weeks. The most notable is a rewrite of the unpack script for source packages that should do a much better job of analyzing the upstream tar file and determining the common prefix. This is currently important so that the upstream index file is generated properly and other collect scripts that depend on it are happy, but in the future it will also be used to implement some checks that care about how the upstream tarball was packed (when it was repacked for DFSG reasons, for instance). There are a bunch of other bug fixes and some more work that lays the ground for future tags. This was a "keeping our heads above water" release more than anything else, taking care of new bugs that had come in since the previous release and not making much continued progress on the bug backlog. But I think we have some underlying infrastructure in place to make more progress in the next few releases. I haven't updated lintian.debian.org for a while. I may do that with this release, or wait for one more.