I just added two new developers to the reportbug project on Alioth, Sandro Tosi and Y Giridhar Appaji Nag, who seem to be enthusiastic about working through the big backlog of bug reports and wishlist requests associated with the package. Since my Debian-related interests are largely elsewhere these days, mostly focused on R stuff that has a more tangible relationship with my research (and by extension my future job mobility and/or tenurability) and a few other infrastructural things in Debian (primarily LSB support and printing), I think this is a good development overall. But still, when you’ve been hacking away at something for almost nine years it’s hard not to develop a bit of a sentimental attachment to it. I still plan to be doing some hacking away at reportbug, but hopefully the new blood can take the lead in terms of day-to-day maintenance while I work on some of the desperately-needed code refactoring issues with the software.

I gave Brenda a Palm TX, so she can better organize her life. As a plus, it is wi-fi aware, so all sorts of interesting things can be done. Sadly, though, it doesn t ship with a microphone (I still wonder why it s large enough to hold an embedded mic, just as Palm smartphones have). Lately, Brenda was talking about recording some sessions or holding her thoughts in one of those tiny memo-recorders, and this promptly stroke me as another gadget to stuff her purse ... then I remembered having read that Palm TX have all that is required to hold a microphone, but the microphone I retrieved the Palm Multi-Connector pinout from Wikipedia and realized that all I had to do was attach an electret microphone to 16 and 17 pins and there we go. I ordered a charging cable just for the connector and here are the pictures I took of the building process: The tools and pieces I used: It s easy to disassemble the connector. Take a close look at the attaching plastic hooks there are four of them: two outside, near the pins, and two inside near the cable. Last two are harder to detach, but once you ve detached the first ones, just hold the two pieces of the connector and easily shear them: one side will detach first. The microphone have two terminals that already hold enough soldering tin. Beware to solder the blue cable (the one that goes with pin 16 AGND) to the marked terminal of the microphone, and the red one (the one that goes with pin 17 MIC_IN) to the unmarked one. (In the picture, my cables are all black, but the wires inside are red or blue . I could not get a good picture of the terminal markings). I have dissolded the charging cables from pins 1, 3, 5, and 8, but that is up to you (you can just cut the main cable and leave the pins untouched). Also, while soldering the microphone cables to the connector, beware of using as little tin as possible. It ll be even easier if you remove the pin from the connector it s easy to do if you have small pliers and careful fingers. Try first with one of the other pins that will not be used. Solder the red one to pin 17 and the blue one to pin 16. I cut a piece of an old earphone cushion to close the charging cable hole (and to protect the microphone). Here is the final result: Now, for the recording software, there s a nice free software that does that perfectly for PalmOS: Better Recorder. Now Brenda can record her mind!

Following my first ftpmaster blog post, which got some nice replies, lets have the next, as I didn’t stop working on stuff. Not as much as I hoped, but well, something. So, what was done since then?

• Merged a little patch from Christoph Berg fixing usage of a function - which doesn’t exist in global namespace, so it needs the full name.
• Merged another patch from Christoph - now we write the content of the Changed-By field from .changes files into projectb. To cite him for the reason: This will allow to identify NMUs and sponsored uploads more precisely in tools querying projectb. Broke dinstall with this and as a little side-effect also the merkel copy of the projectb database. Ups. Well, fixed it immediately again. :) There is some old data available, which I could import into projectb, so it would have data for all packages. But there is some weirdness with the dataset I got from Christoph and am waiting for him to provide a solution. Anyway, all new uploads already store this data, so it is only old data missing, currently.
• Merged a small patch from Thomas Viehmann into our archive software which enables it to send a copy of all mails to the person sponsoring the upload. This is in affect for all future uploads, not for any package which already hit the queues (like those in NEW right now). We do
  • only sent the extra copy if it is a sourceful upload, to not spam buildd admins,
  • only sent the mails to sponsors who did not disable their @debian.org address.
  For those interested, the process works similar to:
  • We look if the Debian login attached to the key signing the upload has an active @debian.org address.
  • If that is the case we look for all uids on that key that look like an email address and compare them with the Maintainer: and Changed-By: field in the .changes file.
  • If there is no match, ie. none of the “emails” of the key uids is in those fields, the @debian.org mail is added to the set of valid receivers.
• Changed split-done to only move files older than 30 days and let it run by our weekly cronjob. Also run it once, which moved 120079 files into their $YEAR/$MONTH subdirectories. (split-done seperates the subdir where we store every .changes of uploads accepted. That quickly grows fast, and we all know how bad filesystems perform with such a number of files. The above 120079 files are from November/Dezember 2007 til now, so imagine how many we have in total, as we have them back to 2002).
• Merged a patch I wrote 7 days ago that does a little sanity checking in the Provides field. Do not try to version your provide, that is forbidden and actually breaks software. (See this bug about it.)
• Merged a patch, submitted by Marc Brockschmidt some long time ago, that lets cruft-report also display NBS for experimental. Changed the cron script to use that extra feature.

---

And as in my last blog post, lets add some items to the todo list:

• Enable dak to read a Built-By field from the .changes file. Thats the sanest solution to sponsored uploads. And also better for buildds, they then should no longer overwrite the Maintainer field with the -m parameter when building packages. Exact semantics to be defined, but dak probably would go something similar to
  • Built-By same as Changed-By or Maintainer?” - do not send mail there.
  • Built-By differs from Changed-By or Maintainer and its sourceful? Send mail to it too.
  • Built-By differs from Changed-By or Maintainer and binary-only? Only send mail there.
• Track the Uploaders: field in projectb. That would help the BTS to offer another display.

Having written all this - today (AKA Saturday, when writing this) won’t see code merges by me. I think most of my ftpmaster related work today will be fun with the NEW queue. For some unknown reason people keep uploading packages. Tsss. Comments: 3

My communications connection I'm going travelling this summer. I don't know what internet connection I'll have (if any) but I'm pretty sure I'll have fairly cheap SMS access from my phone. Maybe even MMS. So, I want to use one of the mobile micropublishers to try to avoid sending international SMSes to lots of people. Facebook doesn't look good - it gives a shortcode (which would cost me extra to use and I don't know whether it works while roaming), has no number for SMS that I found and it looks like O2 is the only UK carrier it knows - bizarre. LiveJournal has mobile access but the FAQ makes it look like it's only for paying users. If I was sure it was going to work, I might pay and support the GPL'd codebase. Jaiku is cost-free and gives an SMS number, but is joining the Goolag and I don't see how to download their Java applet. Twitter is cost-free, gives an SMS number and looks like it plays nice with Jabber (which is already on my phone), so that looks good but I found some complaints about whether SMSes get through. 20six is a German-based cost-free service which takes SMS and email (which is also on my phone), so that also looks good, but there are some old doubts about whether it will stay cost-free. Is there a service you'd recommend?

When I code, one of the tools I use which I like the most is GNU screen. My current project involves the editing of a bunch of different source files, and often jumping frequently between them. I was spawning windows and trying to edit files that I had already opened in a previous screen, and often ending up with a bunch of windows with files I wasn’t using much at the time. So I did some research on how to optimize use of vim and screen together. The first thing I came up with was getting screen to display a nice bar at the bottom by adding this to my .screenrc: (Thanks, Red Hat Magazine!) hardstatus alwayslastline
hardstatus string '% = kG [ % G %H % g ][%= % = kw %?%-Lw%?% r (% W %n*%f %t%?(%u)%?% r )% w %?%+Lw%?%?%= % g ][% B %Y-%m-%d % W %c % g ]' This gives you a neat and coloured (mmmm… colours…) status bar at the bottom of your screen display, including some info on whether other terminals are attached to that window and such. One thing which would vastly improve the usefulness of this would be if I could get vim to set the screen window title. The escape sequence for doing this is the same as for other terminals, but vim’s terminal information database does not include the relevant entry for the “screen” termtype. So (with help from “frogonwheels” and “godlygeek” in #vim) I put an entry in my .vimrc specifying the escape codes for setting screen’s window title. In addition, I abbreviated the window title string to contain only the file. Here is the relevant snippet from my .vimrc: if $TERM=='screen'
exe "set title titlestring=vim:%f"
exe "set title t_ts=\<ESC>k t_fs=\<ESC>\\"
endif A casual glance at my school grades chart will immediately reveal that I am not a structured learner; I’m not the type of user who will, when adopting a tool, begin by reading the manuals. I’m more of a gradual, ad-hoc learner, and I tend to prefer to stick to the defaults whenever possible. Since vim and screen are probably my primary tools for doing work, I should probably do some more research on things like this. These suggestions may be somewhat trivial, but I’ve found them to be quite useful, so I thought it might be useful to someone. Please leave a comment if it was, or if you have any comments (duh!) or suggestions.

Tux likes this fish-like object. I finally got bluetooth file transfer working between my phone and laptop a little while ago. It wasn't particularly hard, although there were a couple of dead ends. The basic bluetooth layer is petty easy. Start dbus, start hcid, start passkey-agent if you've not paired the two. It seems to be a bit simpler to start the pairing from the phone. Then use sdptool browse to check the phone is seen clearly. After that, it got a bit complicated. obexftp worked well enough as far as it went, putting items onto the phone and getting files off the phone, but I couldn't work out how to get some items off the phone. They just didn't appear in the obexftp or obexfs listings. So I wondered if it night be easier to start the transfer from the phone. There's an obexftpd, but I didn't figure out how to send it files. I also tried to compile opd but I think it offer patching for modern gccs. (Anyone got these working?) What I did get to work was sobexsrv - just tell it a directory and it puts any files it's sent there. Works a treat. One other thing that has been really useful is anyremote. It's a command server for the GNU/Linux side and a Java client for the phone. The phone mostly picks from option menus or preprogrammed keys, but editable fields are also possible. You can run any commands that the server configuration allows, including starting file transfers. I think that's possible because remote control and object transfer are on different bluetooth channels, but I don't really understand it yet. I've improved the RSS reader to use xsltproc and added shell commands to it. Once I'm fairly sure it's reliable, I'll upload it near here. (Posted in part due to an ALUG thread which reminded me about this forgotten draft.)

...is just not enough time to see the place properly. I took Friday and Monday off, and Thursday night a week ago, Sarah and I flew down to San Diego for a bit of a "Yay, we've achieved normality" escape. We'd intended to go to SeaWorld on Friday, vege out for two days, go to San Diego Zoo on Monday, then fly home on Monday night. Well we did SeaWorld and the zoo as planned, but lazing around the pool never happened, we ended up running ourselves ragged exploring San Diego all day Saturday and Sunday instead. We stayed at The Dana on Mission Bay, which we picked because it was the closest to SeaWorld. The accommodation was more like a motel than a hotel. There were numerous two-storey buildings across a fairly sprawling area. It had frontage onto what I presume was Mission Bay, and also had a Marina attached to it, so the outlook was quite nice. It also had free WiFi, so we could upload photos throughout the stay. The food offerings were pretty good, and reasonably priced as well. SeaWorld was really good. It's been a long time since I've been to the Australian equivalent, but I don't remember it as being as interactive. San Diego's SeaWorld had a Bay Ray feeding area, where you could purchase food (small whole fish), and hand-feed the Bat Rays. That was pretty cool. It took a bit of a courage to leave your hand in the water, palm up, with something the size of sardine dangling between your fingers and let these huge rays literally swim right over your hand so they could suck the fish from between your fingers. There was also a dolphin feeding area, where you could purchase some small fish again, and give the dolphins a pat on the head and then throw them a fish. I really love dolphins, and one day I'd like to be able to swim with them. The main attraction of SeaWorld is the various shows that they do. I think we caught all of the different ones. The killer whales are just amazing. There were a few different programs where for an additional fee, you could swim with various animals. Dolphins and Beluga whales seemed to be the ones we noticed in particular. There were a few oddities, though: The park is owned by a beer company, so there was a part where you could go and get free samples. Two per person per day (I think on the honour system). At least at the food outlet where we bought lunch (they don't allow you to bring in any food or drink from the outside "for the safety of the animals", so they have a nice monopoly on catering) every kid's meal came in a commemorative Shamu blue plastic lunch pail - whether you wanted it or not. There were two empty ones left on the table that Sarah and I sat down at. The lady cleaning up the tables asked us if we wanted them, and we said no, and she promptly chucked them out with the trash. This just struck me as a terrible waste. They obviously cost money and energy to produce, and they're just going to end up in landfill. They could have been washed and reused instead. I felt this was very hypocritical for a park that was trying to send people away with a message about conservation. Other than this nitpick, I thought SeaWorld was really great. It was a good size, and it was doable in one day, in their normal opening hours. I guess it'd be a bit slower with kids. Photos from the day are here. The next two days we spent exploring San Diego. The hotel was conveniently located on an MTS loop, which ran surprising frequently for a weekend (at least compared to public transit in the Bay Area), so we bought day passes on Saturday and Sunday and used it to get to the Old Town transit centre. On Saturday we explored Old Town, which was a historic preservation of how San Diego looked "back in the day". In the afternoon, we also bought 48-hour tickets for the red double-decker "hop on, hop off" tour bus, and did one of the two loops that it offered. The next day, we caught the loop in the opposite direction, and checked out Mission Beach, which was probably the best beach I've seen in California so far (although the water was still far too cold), saw some pretty cool alternative accommodation (possibly for next time), and did part of the other loop on the tour bus, getting off at the USS Midway. This massive retired aircraft carrier is permanently moored at San Diego, and for a fee, you can crawl all over most of it. It was very interesting, and gave a good insight into the life of a sailor. We blew a good 4 hours or so here, and ran out of time to see the entire thing (we didn't make it onto the "island" part of the ship, which we were a bit bummed about). We then caught the trolley back to Old Town, and grabbed a beer at a pub that sold it by the yard glass and half yard glass. We opted for the half yard glass, since the full yard glass seemed a bit unwieldly, and we thought it looked like a hell of a lot of beer, but the half yard glass, whilst also looking like a lot of beer, was only about one and a half pints. We then grabbed some dinner at one of the very authentic looking Mexican restaurants (they had women out the front, almost on the sidewalk making fresh tortillas on the spot) and headed back home. Photos from our exploration are here. On the last day, we went to the San Diego Zoo (which every time I read the URL for, I read it as "Sandie go Zoo!"). This zoo is purportedly the best zoo in the country, but it really didn't blow my socks off. We seemed to have a really hard time navigating the place, and spent a lot of the day walking around in circles trying to find various exhibits. It's also in a bit of a valley, so the circles tended to be up and down hills, which was tiring. I really don't think we were very efficient at all in our coverage of the place. The other thing that I personally found annoying was the cages. The wire was very close together, which made it really hard to take photos, because the camera would keep focusing on the wire, instead of what was behind it. I guess this is why God invented manual focus, but that made it very hard to photograph big cats stalking their cages. The photos we did manage to get are here. Overall, we had a great time in San Diego, and it seems we didn't really scratch the surface. I'd like to go back again and see Balboa Park, the Gaslamp district, and I thought there were more naval vessels that you could look at, but I might be mistaken. Definitely a very nice city.

Is this traffic or congestion? This is one of those Friday Afternoon Projects - it's been put off all through a busy week because it's unpaid, I'm not completely sure how to approach it and now my arms hurt like hell from travel jabs which are making it hard to concentrate! So I'm going to float it on here... I've been asked to brief a meeting next week about that group's current web site and its problems. I'm not linking it yet to avoid insulting/embarrassing them. The site looks OK, but doesn't rank well on search engines and doesn't allow much member participation. I need to explain why that's a bad thing and how the site's technical choices have led to that. I'm not directly pitching for TTLLP to get any work (because I'm a member of that group, it might be a conflict of interest and we're pretty busy anyway - even our own site needs work on some of the points I'm going to mention), but I don't want to be unhappy if we're asked to implement my recommendations. I've got a usual outline that I follow, but my presentation's time is limited, so I'd like to ask you: what about this is important and what isn't? If you give me useful feedback, I'll put you in the Acknowledgements with a backlink and I hope the briefing will be shared pretty widely over the next few months. The current plan is to start with a basic explanation of how search engines rank pages, as far as we can tell, referring to PageRank Explained Correctly with Examples, by Ian Rogers as well as the shorter official summaries from the dominant search sites at Yahoo, Microsoft and Google. Then I go through a quick evaluation of the site against the basics of validation, accessibility and robot-friendliness, followed by a couple of SEO-style checks of its current rankings and inbound links. Next is a bit different because I have access to some of their web access stats: I summarise what we know and suggest some other stats they've probably not considered and why they're useful, along the lines of Dave Briggs's measures of blog success. Finally, I suggest ways to improve the site. The top tip will be to take control of the site hosting and stop using the cheap and cheerful donated server that makes all links except the front page point to another domain. I'll probably suggest a mix of free and open source software tools to power it. If they don't want to move it all yet, I'll suggest running a second site for member participation, using tools like Wordpress, NoseRub and so on. What do you think? Plan for success, am I missing some tricks, or am I setting myself up for a lynching? Let me know with a comment or email, please.

I'm still following The Lost Ring, but it got a little too intense today when someone who was not very familiar with what was going on was recruited to pick up an envolope hidden in an umbrella stand at a gallery in Hong Kong became disturbed by the contents and destroyed it. All we're left with is some fuzzy pictures. This fragment contains a code. If we can figure out enough of the code, it can be used to download a digital copy of the paper that got torn up. It's a kind of checksum, was written with a typewriter (that writes capital letters a bit higher than the rest of the line, and tends to fade bottoms of numbers), and will look something like "SS71/124P/84JH/HFGS/CEAS". After playing with the gimp, I'm fairly sure that the code starts out "C??L/T4GA/L". In the movies, this is easy, you just zoom in on the blurry picture until you can see fingerprints. In the "real" world, it's gonna be tricky.

Just now, a movie was on TV. This was a non-fiction film, but it was still a story, rather than just a simple documentary or something; it only wasn't scripted or anything similar. The film is about a group of shepherds in Mongolia, who not only own sheep, but also camels, for transport. One of these camels gave birth to a rare white camel; however, the mother does not accept the young for some reason, despite the shepherds' best efforts. Eventually, however, they did succeed in calming the mother, and persuading her to accept the young. What really blew me away, however, is how they did that: By using music. Incredible. So, next time you need to calm down a camel, here is the procedure:

1. Go by camel to the nearest town, and fetch a violinist.
2. By way of a blue piece of cloth, attach the violin to the camel's side, and allow the wind to blow against the snares, so that it makes sound. The camel will start to make sound too, the tone of which will sound suspiciously close to the tone produced by the violin.
3. Get a soprano to sing, while having her gently touch the camel's side. Preferably one who can sing incredibly beautiful. No, really.
4. After half a minute or so, have the violinist join in.
5. After yet a few more minutes, slowly and gently bring the young to the mother. Have the young drink some of the milk.
6. The mother will now accept the young, while she was aggressive if you even brought the young anywhere near her.

Words cannot express how incredible this is. I mean, sure, music can have an effect on one's emotions; and if this is true for human beings, I'm sure the same can be said for animals. But this? Whoa.

Currently my SE Linux Play Machine [1] is running as a Xen DomU. So if someone cracks it they would also have to crack Xen to get access to directly change things on the hardware (EG modifying the boot process). As documented in my last post [2] a user of my Play Machine recently managed to change my password. Of course this was just two days after the vmsplice() kernel security flaw had been discovered [3]. Of course any machine that offers shell access to remote users (or the ability to run CGI-BIN scripts or other programs that users can upload) is immediately vulnerable to such exploits and while SE Linux has blocked local kernel exploits in the past [4] there will always be the possibility of kernel exploits that SE Linux can’t block or which can be re-written to work in a way that is not stopped by the SE Linux policy. So it’s best to assume that SE Linux systems are vulnerable to kernel exploits. At the time that the vmsplice() exploit was announced there was a claim that it could be used to de-stabilise a Xen Dom0 when run within a DomU. It’s best to assume that any attack which can make some software perform in an unexpected manner can also be used to successfully attack it. So at the time I was working on the assumption that the Dom0 could have been exploited. Therefore I reinstalled the entire machine, I firstly installed a new Dom0 (on which I decided to run Debian/Unstable) and then I made a fresh install of Etch for the Play Machine. There is a possibility that an attacker could compromise the hardware (changing the BIOS or other similar attacks), but this seems unlikely - I doubt that someone would go to such effort to attach hardware that I use for demonstrating SE Linux and for SE Linux development (it has no data which is secret). If someone attacks my Play Machine they would have to first get root on the DomU in question and then crack Xen to get access to the hardware. Then the machine is on a separate Ethernet segment which has less access to my internal network than the general Internet does (so they would not gain any real benefit). One thing an attacker can do is launch a DOS attack on my machine. One summer a Play Machine overheated and died, I suspect that the extra heat produced by a DOS attack contributed to that problem. But losing a low-end machine I bought second-hand is not a big deal. When discussing the machine there are two common comments I get. One is a suggestion that I am putting myself at risk, I think that the risk of visiting random web sites is significantly greater. Another is a challenge to put the machine on my internal network if I really trust SE Linux, as noted I have made mistakes in the past and there have been Linux kernel bugs - but apart from that it’s always best to have multiple layers of protection.

• [1] http://www.coker.com.au/selinux/play.html


• [2] http://etbe.coker.com.au/2008/04/02/se-linux-play-machine-passwords/


• [3] http://www.avertlabs.com/research/blog/index.php/2008/02/13/analyzing-the-linux-kernel-vmsplice-exploit/


• [4] http://doc.coker.com.au/computers/se-linux-saves/

Share This

OpenStreetMap party at Kaohsiung, Taiwan Apparently, yesterday we had the first OpenStreetMap event in Taiwan! We met in a caf /restaurant equipped with power plug, wireless network and overhead projector and we had a bit of an introduction, chat and lunch. Then we split in groups and exploited the fact that the newly built underground (KMRT) system is still free of charge, to spread around and map around the stations. Finally, we reconvened at someone's house to see how to put the data together, draw roads, tag and upload. Highlights of the day:

• How to turn a serial GPS into a data logger with 6 hours battery life . Then attach it to your bike using magnets from broken hard drives. Totally rocks!
• Previous OpenStreetMap data was collected by only one person, who took the fancy new High Speed Rail from the opposite side of the country and joined the party. This also made discussion about standardising tags for Taiwan rather easy.
• A group of people appeared wielding a number of "totally insane in every regard" Garmin GPSMAP units: it turns out they are with a civil action group that goes around mapping historical trails, abandoned railroads, aboriginal routes and mountain crosses and so on. Apparently, they did not know about OpenStreetMap: hopefully they'll join in.

Technical bits:

• The eeePC was very popular, and very handy for going around storing tracks, as you can just chuck it in one bag. JOSM runs fine, although it could really use an interface redesign to fit in the small screen. In fact, it could really use an interface redesign to fit in the standard 1024x768 screen of my laptop.
• We could not use the tracks made with the Garmins because we did not know we had to do "Setup -> Map -> Lock On Road = Off" and it was on by default. Now we know it for next time.
• Something like a SirfStarIII really helps in a city made mainly of very tall buildings with lots of steel and glass. My Sony-based cheap gps receiver that worked ok in the Bolognese countryside was next to useless here, continously losing the fix and producing a crazy zigzagging track of doom, only useful to figure out big long straight roads.
• Geocorrelation of digital camera pictures rocks! Who needs to store waypoints when you can just take pictures with the digital camera and have them show up as waypoints in JOSM? The trick of taking a picture of the GPS time and use that to compute time offset is great. Also, we found it easier to just fire up gpscorrelate to do the geocorrelation rather than figuring out how the tools in JOSM work.

Issues to address:

• There is a strong need for a zh_TW translation plugin of JOSM; I'll try to find out how to do it and pass on the information to who can do it.
• Road names could be written either in English or in Chinese characters. Currently English has been used for the name tag because osmarender cannot render Chinese characters. There is some planining to create an OSM mirror in Taiwan which renders twice, and allows to choose the rendering language for the map. I will try to get a planet.osm extract for Taiwan that people can use to experiment with this; thanks to people in #osm for giving me names of people to contact. I will try later after Europe wakes up from this even-earlier-than-usual sunday morning.

For those who weren't aware of it yet, fingerprints are rather easy to fake as the CCC proves again here.

I've just uploaded a small "preview" of dammit. It doesn't do too much yet, and falls over more often than not, but it shows the general direction the tool is going to take. Available from the dump or attached to this blog entry.

I'm the happy owner of a Sony DRU-800A DVD burner, and I wanted to upgrade the firmware, as I had some little burning problems I hoped the upgrade would fix. Of course, Sony's website provides only Win32 flashers. They run under wine, but they don't actually do anything. Apparently, the way these win32 ioctls are implemented rely on the old hdc=scsi deprecated kernel interface. The trick is that we need a 2.4 kernel to get it working properly. So here are the steps I took:

1. Get a bootable sarge with a 2.4 kernel, and boot it with hdc=scsi(hdc is the device name of your burner). You might need to compile the kernel yourself for it to work properly. In any case, you should see something like that in the output of dmesg

   scsi0 : SCSI host adapter emulation for IDE ATAPI devices
     Vendor: PLEXTOR   Model: DVD-ROM PX-130A   Rev: 1.02
     Type:   CD-ROM                             ANSI SCSI revision: 02
   Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
   sr0: scsi3-mmc drive: 0x/50x cd/rw xa/form2 cdda tray
   

2. Make sure wine is installed, the sarge version worked fine for me (more recent versions compiled by hand did not).
3. Make sure there is an appropriate /etc/fstab entry for the SCSI CDROM device. I have something like:

   /dev/sr0        /media/dvd              auto    defaults        
   

4. Make sure there is an appropriate device symlink in /root/.wine/dosdevices. With the above fstab entry, the following would work:

   ln -s /media/dvd d:
   

5. Run the flasher as root (giving write permissions for all SCSI devices to a normal user does not work)
6. Reboot (to your normal system), and check you firmware version number with

   wodim -scanbus
   

This did work fine for the aforementioned DVD burner. It did not get my DVD reader to get flashed, though. But it's worth a try, and once the sarge boot is setup, you won't lose too much time. As a conclusion, rush to get a sarge boot before lenny goes out and sarge is removed from the debian mirrors !

Since the last post, I have significantly improved debian-mr-copyright-mode, that now provides an interactive function, debian-mr-copyright-scan-files that shows which files are covered by which clause of the debian/copyright file. I've also significantly improved my understanding of font lock and emacs lisp in general... As a demonstration, the attached picture represents the results of debian-mr-copyright-scan-files on the monsterz source package (Sam's original example). The output clearly shows that some files are not covered yet... You can get the emacs mode there. Its is starting to be good, but of course, many more improvements are still planned - in particular, quotes for files probably don't work yet. By the way, imenu now works. A debian package should probably come soon.

Planet Debian now has Javascript to facilitate the persistent hiding of particular feeds. The code is still in flux, but appears to work. Comments welcome, especially from people better at Javascript than myself! The way it works was chosen to minimise the changes requred:

• Each entry is wrapped within a new <div>
• The DIV has an ID & a CLASS attribute added.

At load-time the function hideHosts() is called. If a comma-separated cookie called "excludes" is present this is split and iterated over. For each domain-name in the list the current document is searched for elements having a class prefixed with that hostname - if any match and they have an ID defined (regardless of what that might be) they are hidden. And thats it. The changes to the template were minimal; each index entry already has a "link" attribute, so I just had to add this:

 <div class="<!-- tmpl_var name='link' escape='html' -->"
         id="<!-- tmpl_var name='link' escape='html' -->" >
 ....
 </div>

Because the ID and LINK attributes are URLs there is a little mangling, and inefficiency. But I didn't want to change the core of the PlanetPlanet to define a "hostname" attribute for each feed member... In an ideal world I'd add "class='feed, $link'" and then iterate over that at load-time to attach handlers, and an ID appropriately. But that is a little scary.. If it works in IE great. I've tested Firefox & Ephinay ObQuote: Terminator II Update: Moved javascript into external file, and removed the image toggling, it seemed to fail and I'm not sure why. I will investigate.

Continuing from where we left off… The lower bound for me becoming a DD was 8th Feb ‘98 when I applied; for comparison, the upper bound as best I can make out was 23rd Feb, when I would have received this mail through the debian-private list:

Resent-Date: 23 Feb 1998 18:18:57 -0000
From: Martin Schulze 
To: Debian Private 
Subject: New accepted maintainers
Hi folks,
I wish you a pleasant beginning of the week.  Here are the first good
news of the week (probably).
This is the weekly progress report about new-maintainers.  These people
have been accepted as new maintainer for Debian GNU/Linux within the
last week.
[...]
Anthony Towns <ajt@debian.org>
    Anthony is going to package the personal proxy from
    distributed.net - we don't have the source... He may adopt the
    transproxy package, too.
Regards,
        Joey

I never did adopt transproxy – apparently Adam Heath started fixing bugs in it a few days later anyway, and it was later taken over by Bernd Eckenfels (ifconfig upstream!) who’s maintained it ever since. Obviously I did do other things instead, which brings us back to where we left off…

---

• Crypto in main: It’s getting hard to remember the days when strong crypto software was classed as munitions and even getting a web browser to do SSL properly was a legal challenge; but for a long while that’s how it was, and as a result we had to keep all our security tools hosted separately to our main, US-based archive. The laws for that changed in early 2000, introducing a new exemption to the prohibition for software whose source code was available royalty-free (I think they called it “public source”). Unfortunately there were still drawbacks: it wouldn’t apply to some stuff in non-free, it wasn’t clear how far you had to go with the source code (is libssl’s source enough, or do you need the source for the apps that use ssl too?), and the biggest problem was you had to notify the export bureau and the NSA for everything you wanted to distribute. And all of that’s couched in the sort of confusing language you’d expect to find in, well, export regulations. So we ended up getting nowhere on merging crypto into the main archive for a long while because we couldn’t be confident of what we actually needed to do. We’d more or less already missed the opportunity to do the merge for the potato (2.2) release because it was frozen more or less exactly when the new regulations came out, and according to my mail archives Ben Collins (DPL at the time) got a team organised to review the legal issues by mid-May 2001. By July 2001, though, we still weren’t really getting anywhere; the lawyer we were talking to was looking at the ENC exception (which was for closed source stuff, and requires an active review by the BXA), instead of the TSU exception (which just requires notification). While it wasn’t terrible legal advice – following the ENC exception had a lower risk of misunderstandings on our part leading to problems later – it wasn’t useful in achieving our aims, ie, getting crypto stuff into main with a minimal level of ongoing effort, as well as a minimal level of risk. So moving onto August, we’d moved on from the lawyer we’d been using for this and other issues, to talking to a lawyer who specialised in export issues (and whose time was being covered by HP). That actually got us somewhere, with the end results being a matter of public record – we got the advice we wanted by November, we got a new incoming system so we could make sure we didn’t publish anything we hadn’t advised the NSA and BXA about, and most of all, we got cryptographic software in main for woody’s release. ssh at standard priority, apt by default checking archive signatures before downloading code to run as root, iceweasel coping with https:// urls out of the box all suddenly became possible, rather than artificially blocked due to pointless legal constraints. Yay! The way we notified BXA/NSA was somewhat interesting – we ended up notifying once for each package, when it passed through NEW: which is easy to automate, and limits the amount of software we block from review by other developers as best we can. OTOH, it also means a lot of notifications: the initial notification was a huge box of paper that got faxed off (there should be pictures somewhere on the net, but I don’t know where), and the vague hope that the ongoing reporting would not only comply with the regs, but manage to be something of a denial-of-service by compliance. As it turns out it apparently got noticed, with the following mail arriving in September 2005:

  From: Encryption 
  Date: Fri, 23 Sep 2005 12:51:02 -0400
  Subject: Addition to Debian Source Code updates
  Dear Mr. Collins,
  Your diligent reporting of updates to the Debian source code to the Bureau
  of Industry and Security has been an excellent example of perspicacity.
  However, you no longer need to do so per the following update to the EAR:
  [...]
  

  (The mails have always been sent with Ben's name attached) That mail was followed by another suggesting a phone conversation; unfortunately nobody seemed to notice the mail, at least until a year later (to the day!) when Joerg pointed out he was getting bounces form the BXA email address we'd been using... (Since then, based on the above mail, we've been recording notifications, but not passing them on; I sent a reply to the mails above indicating that, but didn't receive a response. There's been about 5000 notifications since then)
• Security and the architecture explosion: with crypto-in-main out of the way, along with lots of RC bug squashing, woody was looking good to come out in April or May, but unfortunately that all fell apart because of a lack of automation for handling security updates. Taking a step back, woody managed to introduce five new architectures compared to the previous release -- HP's pets, hppa and ia64; the IBM mainfram arch, s390, and the SGI/embedded mips and mipsel chips. That came just short of doubling our supported architectures (which had been i386, m68k, alpha, arm, sparc and powerpc), and was working really impressively well: testing was watching that they kept in sync, and the buildd network was keeping them all up to date with the latest source uploads, and the toolchain maintainers were making sure new kernels and compilers didn't cause massive breakages. It was great fun to be a part of, and I'm not sure how much is just blurry memories, but from here, it sure feels like it was a golden age on that score... Anyway, all the extra architectures freaked the security team out, given they were already having to worry about ssh'ing to half a dozen machines and manually do builds, and fix them when they broke, and to deal with that there'd been plans afoot for "rbuilder" to get rolled out, which never actually happened. All of which means it escalated from being the security team's problem, to a problem for everyone, particularly the release manager... The result of which meant knuckling down and coming up with a new security build infrastructure, which involved doing a dak install for the security archive, then building on the changes just rolled out for crypto-in-main to allow for packages to be autobuilt before actually being included in the archive, then updating official buildds for all the various architectures to target stable-security and testing-security and prioritise them and upload to the right place. But as stressful and last minute as that was, at least it worked, and woody made it out the door on July 20th 2002 -- and it's a good thing it worked, given woody ended up getting security support until June 30th 2006 -- the usual year after it's successor is released -- for four years support. (The same rule applied to sarge has resulted in two years and ten months' security support; eighteen month release cycles in general should result in two years and six months of support) Since then, with security managed by dak, there's been a few more bits I've been involved in. The most interesting of which (to my mind) was splitting the security upload queue from being completely secret and restricted to folks who are allowed to access updates prior to public announcement, into separate secret and non-secret queues. That was December 2005, and since then we've gone from having Joey Schulze basically being the sole person doing security updates to two separate teams, with ten new members. It's not without it's problems -- particularly for packages that get (mis)classified as NEW, or that get lost on their way for inclusion in the next stable point update, but it's nevertheless lightyears from where we were in April 2002, or even November 2005.
• Playing other people for suckers: with woody released, the whole "redo to release process" thing was essentially done -- it had been implemented, it had worked all the way to getting a release out, and in a fair few respects had improved things. Instead of the eight months of hand-approved uploads for the potato freeze, things had gone it automatically, albeit with gradually stricter constraints, right up until April; and even when the security problems delayed things, the manual updates only lasted a bit under three months. So at that point I was pretty happy, and looking forward to making things work a bit better and basically passing the buck to someone else. The first bit of buck passing that worked exceptionally well was jumping on Colin Watson, who'd been offering some debbugs patches on IRC, and after a delightfully brief discussion with some of the other debbugs folks, got getting him added to the group and able to make changes directly on the site. His advogato post the next day was:

  Yesterday I was invited onto the group that administers the Debian bug tracking system. I can't decide whether to be intimidated or excited. There's a great deal to do: my first couple of major projects look set to be integrating some of the existing QA interfaces to release-critical bug tracking, and developing a tool to help us edit spam out of bug histories.

  There's a lot to be said for grabbing people at the point where they're still intimidated by what they're joining; sure there's a definite risk that they'll break something you'll have to clean up, but that's pretty easy to deal with, and well worth all the extra excitement and energy that comes with a little bit of nerves. I did a talk on debbugs a few years later, at the 2005 DebConf, at which point we managed to entice Pascal Hakim and Don Armstrong into signing up, if I'm remembering right. At the same time Colin rolled out his implementation of version tracking support for debbugs (which I'd specced up a while ago, and helped design, but cannily avoided actually coding). Shortly after, Pasc put together bug subscriptions, and these days Don's pretty much the primary maintainer of debbugs. How cool is that? Passing on release managership was a bit less fortuitous though; it's a big job, and it's not something that you can offer "patches" for, generally. So after a bit of cogitating on just how to do it, I went with an open recruitment call in March 2003, and then a bunch of practical assignments to get the volunteers used to what RM work actually entailed and to see whether they actually like it. The recruitment call was mostly focussed on all the negatives, half to avoid people volunteering to be RM for the power (to decide which release policy wins, to tell maintainers what to do, to drop packages, or to just decide what name/number the next release gets) instead of wanting to actually do the work to get the next release out and keep developers happy; and the other half was the theory that if you make a job look hard, technical, but not terribly risky, it starts looking interesting to the right kind of people. The assignments generally were two parters -- first to introduce some stuff about release management that they mightn't be familiar with, and the second a bunch of problems that needed resolving that'd use those skills. The first set was RC bug fixing, followed by working out why packages aren't getting into testing, followed by dealing with packages with mutual dependencies and removing packages. At some point that evolved into the testing scripts accepting "hints" from the release team as to what packages to try in combination, or which packages to force out of testing. That turned out pretty successful, with Steve Langasek, Colin Watson and Joey Hess becoming official release assistants in August, and Colin and Steve replacing me as RM in mid-2004. It was also pretty satisfying to see Andi Barth do some more release assistant recruiting in 2005 following much the same model, and indeed using much of my mail verbatim. You can't really ask for better than that, I figure.

Geez, this was meant to be briefer...