Ubuntu Wiki

Log

TZ UTC-5

(02:01:37 AM) cjwatson: ok, just missing asac - let's start anyway and hope he shows up
(02:01:42 AM) ***ogra slowly feels the healing power of caffeine in the morning
(02:02:05 AM) cjwatson: first off, activity reports: I have four out of nine this week
(02:02:19 AM) ogra: mine just hit the list ...
(02:02:21 AM) cjwatson: please send these *before* the meeting
(02:02:22 AM) ogra: (sorry)
(02:03:10 AM) cjwatson: next the real agenda
(02:03:10 AM) slangasek: would you prefer if I started sending mine end of day Monday?
(02:03:11 AM) cjwatson:  * Actions from last week
(02:03:11 AM) cjwatson:   * Result of multi-monitor discussion with desktop team? (Bryce)
(02:03:16 AM) cjwatson: bryce: how did this go?
(02:03:22 AM) ***asac hides
(02:03:33 AM) cjwatson: slangasek: no, yours was fine, I get up a little early before the meeting so I can catch up on them
(02:03:38 AM) slangasek: ok
(02:04:08 AM) bryce: cjwatson, it's come along fairly well
(02:04:26 AM) bryce: cjwatson: I have debs and screenshots up at:  http://people.ubuntu.com/~bryce/Testing/XrandrGui/
(02:04:47 AM) bryce: right now I'm mostly waiting on seb128 to review/upload things
(02:05:25 AM) bryce: I was hoping to get some feedback from him on the integration, but I gather he's been busy with the new gnome stuff
(02:06:02 AM) bryce: the gui installs and runs, and it seems to work (but I found a bug when using it on a KVM)
(02:06:38 AM) bryce: most of the work has been packaging - a lot of autoconf/automake hackery
(02:06:43 AM) cjwatson: aside from the text about F9 :-), that looks pretty good; no facility for choosing a different driver?
(02:07:05 AM) bryce: right, this only uses xrandr interfaces
(02:07:36 AM) bryce: screenshot 1 and 2 are before / after
(02:07:37 AM) cjwatson: I just want to make sure that if we drop displayconfig-gtk we're not reliant on anything it does
(02:07:44 AM) bryce: screenshot 2 corresponds to what's in the debs
(02:08:06 AM) cjwatson: ah
(02:08:31 AM) bryce: well, displayconfig-gtk is essentially a fancy xorg.conf editor
(02:09:01 AM) bryce: this new tool does everything through run-time interfaces, so anything that requires xorg.conf modification is going to be out of scope for it
(02:09:38 AM) cjwatson: perhaps we should prepare some release notes text about how to do anything that's dropped
(02:09:45 AM) bryce: ok
(02:10:38 AM) cjwatson: ok, thanks
(02:10:40 AM) cjwatson:  * 5-a-day
(02:11:09 AM) cjwatson: Jono has asked that I remind everyone of the existence of 5-a-day (https://wiki.ubuntu.com/5-A-Day) and encourage all of you to take part
(02:11:35 AM) cjwatson: err, where relevant anyway
(02:12:10 AM) cjwatson: even if you're already doing equivalent bug work (which most of you should be, at a minimum), please also help to spread the message
(02:12:51 AM) evand: will do
(02:13:12 AM) cjwatson: the wiki page has pointers to some tools to help with this
(02:14:10 AM) calc: ok
(02:14:22 AM) doko_: hmm, so I should just call 5-a-day before a package upload?
(02:14:36 AM) cjwatson: that's one reasonable approach, yes
(02:14:54 AM) cjwatson: if you're feeling particularly enthusiastic you could hook it into dupload ;-)
(02:15:36 AM) doko_: ok, will do.
(02:16:15 AM) cjwatson: but the important bit is publicising to the community that this is something that the Ubuntu community does as a matter of course
(02:16:54 AM) TheMuso: I've certainly been thinking that it *could* be a way to encourage people testing a11y to file bugs, as they just about always post to mailing lists...
(02:17:15 AM) TheMuso: But other than that, I'll likely jump in and participate as well.
(02:17:33 AM) cjwatson: hmm, I think filing bugs is just about the only bug activity that's not part of 5-a-day
(02:17:46 AM) cjwatson: the point is to get the bug count down :-)
(02:18:04 AM) TheMuso: right
(02:19:23 AM) calc: file more bugs so you can turn around and close them? ;-)
(02:19:36 AM) cjwatson: I think that's enough on that topic :-)
(02:19:38 AM) cjwatson:  * Final call on dmraid (Luke)
(02:19:46 AM) TheMuso: Right.
(02:19:59 AM) TheMuso: If people haven't been following my reports and other IRC activity, let me bring everybody up to speed.
(02:20:31 AM) TheMuso: For several years, many consumer, and some low-end server boards have been shipping with what is known as fake raid.
(02:21:00 AM) TheMuso: Basically, the BIOS of the disk controller writes special metadata to a pair or so of disks, to make them a fake software raid, be it raid 0, 1, or 5.
(02:21:23 AM) TheMuso: Windows drivers for these controllers know what to look for, and transparently read/write this metadata as necessary, with the user not even knowing most of the time that windows is sitting on top of a RAID setup.
(02:21:38 AM) TheMuso: Dmraid is such an interface to this metadata for Linux.
(02:22:04 AM) TheMuso: However, so far from my testing, it doesn't come close to either what the BIOSs can do, or what Windows drivers do in terms of keeping the array consistant.,
(02:23:17 AM) TheMuso: So, with dmraid still not being able to reliably provide event monitoring for failed/degraded arrays, and not being able to rebuild arrays, as well as at least one BIOS on a controller I have always finding array inconsistancies when Linux has touched the array, we need to really consider whether dmraid is something we want for hardy.
(02:23:42 AM) TheMuso: From my point of view, it comes down to whether I keep actively working on it, dispite these issues, or whether I move onto other things, and keep an eye on it for hardy+1.
(02:24:01 AM) calc: perhaps whitelist it on a known working chip/bios-rev basis?
(02:24:08 AM) TheMuso: I have also discovered that kernel patching is required to allow for the use of RAID 5 via dmraid.
(02:24:42 AM) TheMuso: calc: Since it uses metadata on the hard disk, this could be possible, but the fact is, that at least one BIOS I have complains of array inconsistancies after I even do an install onto a dmraid array.
(02:24:51 AM) slangasek: what's the alternative to having dmraid enabled - having no support for the controller, or having support for it as a plain IDE/SCSI controller?
(02:25:03 AM) TheMuso: Another controller I have did not appear to be as strict, but only complained when I degraded the array.
(02:25:19 AM) TheMuso: slangasek: Only supporting it as a standard IDE/SCSI controller.
(02:25:28 AM) TheMuso:  /SATA even
(02:25:29 AM) ***slangasek nods
(02:25:41 AM) TheMuso: slangasek: Which means that users who have windows on such an array could very easily destroy it.
(02:26:09 AM) slangasek: oh... :)
(02:26:25 AM) slangasek: but, you're saying that the current code isn't guaranteed to do much better for them?
(02:26:33 AM) TheMuso: slangasek: No it is not.
(02:26:39 AM) ArneGoetje: TheMuso: can we detect this situation and display a warning to the user?
(02:26:49 AM) TheMuso: Especially if the BIOS is as strict as my hpt37x controller supporting fakeraid.
(02:26:52 AM) calc: is the code not working for any of the many different brands, or just not good on certain ones?
(02:27:15 AM) cjwatson: it looks to me that the dmraid program isn't really hooked into device-mapper change events, and that it only erases the metadata if you explicitly tell it to
(02:27:15 AM) TheMuso: calc: I don't know, as I only have 2. The code works, but its a matter of makings ure the array is consistant once Linux shuts down.
(02:27:22 AM) calc: grr hpt is crap, i had trouble with one of those writing into cylinder 0 even when raid wasn't enabled :-\
(02:27:44 AM) calc: overwriting grub bootloader in the process
(02:28:01 AM) calc: TheMuso: ok
(02:28:12 AM) slangasek: hmm, hpt is the one that's now courting Linux
(02:28:14 AM) TheMuso: cjwatson: As I said in my report, there is work going on to get some stuff into the kernel to support dmraid better. There is also more userspace work going on for event monitoring.
(02:28:16 AM) calc: does intel's matrix raid stuff use dmraid?
(02:28:26 AM) cjwatson: TheMuso: was your testing just with the installer, or did you also try editing partitions in a regular system?
(02:28:32 AM) calc: getting intel's fake raid to work (if possible) would probably be a good thing
(02:28:47 AM) cjwatson: TheMuso: the reason I ask is that I notice that the installer integration does not do the same stuff that /etc/init.d/dmraid does on shutdown
(02:29:05 AM) TheMuso: cjwatson: I tried the following: 1) install windows, then Linux. 2) Install Windows, edit partitions, reboot. 3) install Linux only.
(02:29:21 AM) TheMuso: All were caught by the BIOS as possible inconsistancies on the array.
(02:29:44 AM) TheMuso: cjwatson: Well, I even tried hand-deactivating the arrays before rebooting.
(02:29:58 AM) cjwatson: though, I have to say I'm slightly surprised that the partition table is ATARAID metadata as such
(02:30:29 AM) cjwatson: I would have thought that dmraid should present a device to Linux on which parted blindly edits the sectors corresponding to the partition table, which then translate into writes to both disks
(02:30:32 AM) TheMuso: cjwatson: The partition table is totally separate to the metadata.
(02:30:44 AM) TheMuso: The metadata is at the end of the disks. The partition table is where you would normally find it.
(02:31:02 AM) cjwatson: right, so what's the metadata that needs to be updated? would that not normally only be if you added or removed disks, or if disks failed?
(02:31:12 AM) cjwatson: I'm trying to figure out why partitioning changes it
(02:31:55 AM) TheMuso: cjwatson: I don't know without digging into code. My guess something to do with state is stored in metadata, but I think this varies from controller to controller.
(02:32:18 AM) TheMuso: Well as referred to by calc, it could also be a flaky BIOS. There is no newer revisions for the board however.
(02:32:33 AM) TheMuso: And, running WIndows/DOS and doing all manner of parttion edits etc does not seem to bother the BIOS.
(02:33:36 AM) cjwatson: dmraid seems to have explicit BIOS-specific metadata handlers
(02:33:54 AM) TheMuso: Yes it does.
(02:34:14 AM) TheMuso: As all metadata is different from controller to controller.
(02:34:52 AM) calc: bug 8978 refers to the issue i had with hpt controllers doing stupid things
(02:34:53 AM) ubotu: Launchpad bug 8978 in grub "Grub - Error 21 returned" [Medium,Confirmed] https://launchpad.net/bugs/8978
(02:35:17 AM) TheMuso: Now. I will be getting a new system in the coming weeks, that will have 2 different dmraid compatible controllers on it. I'll be interested to see how well they are handled. One will be intel, and one will be Gigabyte.
(02:35:30 AM) ogra: i have some edubuntu users using hpt
(02:35:52 AM) asac: hmm, are there actually any bugs filed about these inconsistencies after shutdown?
(02:36:06 AM) ***asac looking at dmraid lp bugs page
(02:36:12 AM) TheMuso: However my silicon image controller was not even bothered when Linux was installed. Never tried Windows+linux, as I wanted to move the dmraid testing to another box.
(02:36:31 AM) TheMuso: asac: No, as it is only with cone controller that I get the behavior.
(02:36:37 AM) TheMuso: one
(02:36:39 AM) evand: TheMuso: I have two dmraid systems that were sent to me and can help, as I've also been tasked with similar goals.
(02:37:03 AM) cjwatson: ... so at least one controller *does* work?
(02:37:09 AM) TheMuso: evand: Right, if I were to give you some quick isntructions as to build a modified alternate disk, wuould you mind having a look?
(02:37:24 AM) TheMuso: cjwatson: Yes, for a linux only install.
(02:37:38 AM) TheMuso: I can certainly try it again, if required. Need to card swap, but thats no big deal.
(02:37:39 AM) evand: TheMuso: not at all, I'll make it a top priority.
(02:37:43 AM) cjwatson: that's a little more promising
(02:38:12 AM) TheMuso: cjwatson: However, there is still the issue of not being able to rebuild the array from Linux.
(02:38:24 AM) cjwatson: basically, I'm just aware that this is an increasing target and if we don't get something in I suspect it's going to come up in point releases as a hardware support target anyway
(02:38:29 AM) TheMuso: So at this point, we could certainly blacklist the hpt37xx controller I have.
(02:38:39 AM) TheMuso: cjwatson: Right.
(02:38:51 AM) cjwatson: if it were totally non-functional, I'd agree it doesn't make sense
(02:39:41 AM) cjwatson: but it sounds to me that we have some specific bugs on which we need help from upstream
(02:39:45 AM) TheMuso: cjwatson: I do need to do a dual boot windows test with that silicon controller however to be sure.
(02:40:17 AM) TheMuso: The upstream mailing list is rather quiet. The person at Red Hat who maintains this certainly is working on it, but I think he is also involved with other things.
(02:40:27 AM) TheMuso: I'm downloading fedora 8 as we speak to see if that yields any different results.
(02:40:34 AM) TheMuso: As they've had dmraid in fedora for a few releases now.
(02:40:36 AM) calc: TheMuso: blacklisting probably should be based per bios revision, but that might get complicated
(02:41:04 AM) cjwatson: I think a fairly sane approach would be to move it to main for wider testing for now (since we need it in main in order to have it in the installer), but put a prominent note in the release notes for alpha 6 and beta that we will rip it back out again if test results are unfavourable
(02:41:08 AM) TheMuso: calc: Yeah I'd say it would, but as I said, there is no newer revision for this board, and I can't download an older one to try.
(02:41:11 AM) calc: maybe best to upgrade chipset to most recent bios (where possible) if it doesn't work blacklist the whole chipset for the time being
(02:41:13 AM) cjwatson: how does that sound?
(02:41:36 AM) slangasek: sounds agreeable to me
(02:41:36 AM) ogra: pretty dangerous
(02:41:42 AM) evand: heh
(02:41:54 AM) TheMuso: Note if any testing is to be done, it should be on a clean system so that data loss is no issue.
(02:41:58 AM) cjwatson: ogra: elaborate?
(02:42:07 AM) ogra: since its probably the base of your install people really need to be aware they need to reinstall if it fails
(02:42:11 AM) ogra: i mean
(02:42:16 AM) ogra: its your filesystem
(02:42:25 AM) slangasek: TheMuso: I look forward to your recommended release notes entry ;-)
(02:42:26 AM) cjwatson: we could include a warning in partman-dmraid that this is explicitly experimental and you MUST have backups
(02:42:30 AM) ogra: that needs a very wordy warning
(02:42:40 AM) TheMuso: cjwatson: partman-dmraid already has a warning.
(02:42:42 AM) cjwatson: "NO, REALLY"
(02:43:09 AM) evand: "Type 'Yes, do as I say' to continue" :)
(02:43:22 AM) ogra: i mean, i'm getting mails atm if ltsp is already final for hardy ... from people wanting to use it in production next week (if i dont shout)
(02:43:24 AM) cjwatson:  The support for SATA RAID disks (using dmraid) in the installer is
(02:43:24 AM) cjwatson:  experimental. You should make sure that you have a backup of any
(02:43:24 AM) cjwatson:  data on your system that you do not want to lose!
(02:43:26 AM) cjwatson: [and more]
(02:43:26 AM) TheMuso: Well there is a question that gets asked by partman-dmraid.
(02:43:35 AM) ogra: since "its only about a month")
(02:44:24 AM) TheMuso: cjwatson: As for raid 5 support, I could easily see how well that patch could be adapted for lum perhaps?
(02:44:25 AM) cjwatson: ogra: this is balanced against the fact that you can try to install Ubuntu right now on these systems and it's *guaranteed* to do bad things to your array
(02:44:35 AM) ogra: right
(02:44:49 AM) cjwatson: TheMuso: it came up a little while ago, and I didn't think it was all that important?
(02:45:07 AM) cjwatson: TheMuso: do people need RAID 5 support?
(02:45:11 AM) TheMuso: cjwatson: I don't think that was dmraid related...
(02:45:26 AM) cjwatson: it was some module that had 'dmraid' in its name
(02:45:27 AM) TheMuso: cjwatson: I certainly know intel controllers support it, and some others do.
(02:45:28 AM) cjwatson: dmraid56 IIRC?
(02:45:43 AM) TheMuso: cjwatson: I didn't dig, but I'll ahve a look. It could be the one.
(02:46:15 AM) cjwatson: if it's needed, then I apologise for saying it wasn't - #ubuntu-kernel should be able to help
(02:46:55 AM) TheMuso: Yes there was a post to the kernel list about it, but I  don't think its been acted upon.
(02:47:23 AM) arualavi_ is now known as arualavi
(02:47:41 AM) cjwatson: any other questions? I agree that this is an uncomfortable situation
(02:48:11 AM) TheMuso: If you have dmraid compatible controllers that you could spare, testing would be very welcome.
(02:48:38 AM) TheMuso: spare as in, use that machine for testing, with data backed up to a safe place.
(02:48:53 AM) ogra: TheMuso, i'll send a call to the edubuntu list ... o know many of my users have such HW in their ltsp boxes, but dont know if they have spare stuff for testting
(02:49:08 AM) ogra: s/o know/i know/
(02:49:17 AM) TheMuso: ogra: I think its safer if the machine is non-critical at this point. Thanks though./
(02:49:38 AM) ogra: yeah, i'll ask if someone has a spare one to test on
(02:49:42 AM) cjwatson: I'm happy to help review a release notes entry
(02:50:00 AM) cjwatson: ok, one more item from activity reports
(02:50:03 AM) cjwatson:  * need folks with European keyboards to test if dead-keys work when
(02:50:03 AM) cjwatson: using scim-bridge with scim and feedback to me. If this works, we can
(02:50:03 AM) cjwatson: use scim-bridge as default module for scim, as it seems to solve all the
(02:50:03 AM) cjwatson: problems we currently have with scim.
(02:50:05 AM) cjwatson: (arne)
(02:50:11 AM) TheMuso: How complex is os-prober? I'll see if I can also get windows to be detected on a dmraid array.
(02:50:34 AM) cjwatson: os-prober is not too bad; I wrote chunks of it so I can help you with it
(02:50:48 AM) TheMuso: Ok thanks. Ok we can move on now I have my answer. :p
(02:51:15 AM) cjwatson: volunteers for keyboard testing?
(02:51:32 AM) cjwatson: this looks like a five-minute test for a few different people
(02:51:34 AM) ***ogra raises hand ....
(02:51:34 AM) TheMuso: If I knew a European keyboard layout, I'd be happy to help. :)
(02:51:45 AM) cjwatson: I don't think us/gb really count
(02:51:57 AM) asac: i have a dead-keys keyboard and could test
(02:52:02 AM) TheMuso: Thats why I said, if I knew a layout.
(02:52:04 AM) ArneGoetje: only those with dead-keys on their hardware keyboard
(02:52:13 AM) ogra: my prob is that all my keyboards are attached to thin clients and the classmate doesnt have a european one ... but i'll arrange something
(02:52:16 AM) cjwatson: ArneGoetje: dead keys are typically implemented in X ...
(02:52:20 AM) cjwatson: not in hardware
(02:52:37 AM) slangasek: ArneGoetje: how does one test the scim-bridge part of this?
(02:52:44 AM) ArneGoetje: well, I mean using a keyboard layout with dead-keys enabled by default
(02:52:50 AM) cjwatson: right
(02:53:04 AM) ArneGoetje: please see my activity report for testing steps
(02:53:09 AM) slangasek: if I toggle input method to SCIM, compose still works better than the GTK default IM, so I'm happy
(02:53:32 AM) cjwatson: ArneGoetje: (perhaps repost that one to ubuntu-devel)
(02:53:34 AM) ogra: all germans who dont use dvorak likely use "de nodeadkeys"
(02:53:34 AM) ArneGoetje: slangasek: you use en_US I suppose?
(02:53:48 AM) ArneGoetje: cjwatson: will do.
(02:54:11 AM) slangasek: ArneGoetje: en_US, with plenty of use of compose; no deadkeys
(02:54:41 AM) ArneGoetje: slangasek: does that one work well when scim is enabled?
(02:54:52 AM) slangasek: it appears to - but I don't have scim-bridge installed yet
(02:55:04 AM) cjwatson: does scim implement the dead-key composition itself, or just pass keycodes through to X?
(02:55:27 AM) ArneGoetje: cjwatson: it should pass it through X when in English mode.
(02:55:31 AM) cjwatson: i.e. is there a possibility that it works for some combinations of dead keys and ordinary keys but not for others?
(02:55:34 AM) cjwatson: ok
(02:55:46 AM) cjwatson: (English => "not CJK", IIRC :-) )
(02:56:08 AM) cjwatson: so in that case a couple of tests ought to be sufficient
(02:56:28 AM) cjwatson: (asac and ogra)
(02:56:31 AM) ArneGoetje: I know it works when scim is set to scim-immodule... but need to test with scim-bridge too
(02:56:49 AM) cjwatson: all right - any other business?
(02:57:13 AM) slangasek: reminder that this Thursday is the UI Freeze
(02:57:39 AM) cjwatson: bryce: that particularly applies to this xrandr gui work
(02:57:40 AM) TheMuso: Ouch.
(02:57:43 AM) TheMuso: re dmraid. :p
(02:57:44 AM) bryce: hrm
(02:57:47 AM) asac: ArneGoetje: ill test right after the meeting and let you know.
(02:58:00 AM) ArneGoetje: asac: thanks.
(02:58:18 AM) bryce: cjwatson: could you prompt the desktop folks to review/upload my patches?  I could really use their help to meet that cutoff
(02:58:19 AM) cjwatson: people will start taking screenshots for documentation, books, etc. at UI freeze and will need to be warned explicitly of changes
(02:58:21 AM) slangasek: I'll send out a more thorough reminder to u-d-a; in the meantime just bear in mind that any changes to UIs (artwork, text strings, etc.) after Thursday need to be coordinated
(02:58:27 AM) ArneGoetje: what is affected by the UI freeze?
(02:58:57 AM) slangasek: ArneGoetje: https://wiki.ubuntu.com/UserInterfaceFreeze
(02:58:58 AM) cjwatson: ArneGoetje: everything that documenters, translators, et al might need to know about if it changes afterwards
(02:59:07 AM) cjwatson: (to a crude first approximation)
(02:59:25 AM) ArneGoetje: I'm still reshuffeling some font settings and default font packages to be on the first install...
(02:59:27 AM) cjwatson: bryce: ok, noted
(02:59:49 AM) cjwatson: *extra* fonts aren't much of a problem, as nobody's going to take a screenshot of broken stuff for documentation
(03:00:18 AM) ArneGoetje: I mean default fonts
(03:00:32 AM) cjwatson: I mean extra default fonts over what we have now :-)
(03:00:47 AM) ArneGoetje: which fonts are chosen to render a particular script, etc.
(03:00:57 AM) ArneGoetje: cjwatson: ok.
(03:01:13 AM) evand: so then this doesn't cover color changes?  I'm still trying to work out grabbing the right ones from gtk for two different custom widgets.
(03:01:43 AM) cjwatson: ArneGoetje: but if it produces radical changes, please coordinate with the release team
(03:01:44 AM) slangasek: evand: if it's a change that could affect the accuracy of screenshots, it should be communicated
(03:01:48 AM) ArneGoetje: however, for CJK the default font should be changed
(03:01:52 AM) evand: slangasek: noted
(03:02:12 AM) cjwatson: there is a bug about the look-and-feel of the new ubiquity timezone widget
(03:02:32 AM) cjwatson: would be worth seeing what can be done about that before Thu
(03:03:11 AM) evand: indeed, I did catch that one
(03:03:16 AM) evand: I'm tempted to zoom in even further
(03:03:19 AM) evand: so there's more spacing
(03:03:37 AM) cjwatson: I have noticed that it's quite difficult to land on a particular point
(03:03:55 AM) cjwatson: particularly given that the map moves as you move the mouse pointer over it, so it effectively ends up moving at twice the speed you expect
(03:04:14 AM) cjwatson: but that might be tolerable with more space to work with
(03:04:40 AM) evand: if it's still noticable I'll work on smoothing it out and slowing it down.
(03:04:48 AM) cjwatson: ok, we're over time and should probably take this to other channels
(03:04:54 AM) cjwatson: thanks, everyone
(03:04:56 AM) asac: thanks
(03:05:00 AM) cjwatson: I think I'm going to go and have a nap :)
(03:05:00 AM) ArneGoetje: thanks
(03:05:02 AM) slangasek: thanks
(03:05:03 AM) TheMuso: Thanks, will get minutes done tomorrow my time.
(03:05:15 AM) cjwatson: TheMuso: cheers
(03:05:17 AM) calc: goodnight :)
(03:06:08 AM) cjwatson: late reminder, please look at http://people.ubuntu.com/~dholbach/sponsoring
(03:06:17 AM) ***asac looking
(03:06:45 AM) cjwatson: if you have anything with your name against it, particularly if it's old, please do something about it; we need to be responsive to people submitting patches