[07:08] <Kano> TheMuso: you know that dmraid only needs the hd meta data? you can use hds with it even on systems which do NOT have got a raid bios at all. At least when you are not requried to boot from it.
[07:08] <Kano> TheMuso: so basically you could use a ppc to access hds from a pc raid too.
[07:09] <Kano> but that all would only work with a working dm
[07:09] <Kano> and that is broken
[07:12] <Kano> http://patchwork.kernel.org/patch/33534/
[07:13] <Kano> without all with dm is useless
[07:42] <TheMuso> Kano: I know that. The module is only used for RAID 5 arrays, and teh likelyhood of users using powerpc to access such arrays is very low. Most macs for example would require at least 2 E-Sata cards to allow people to connect the minimum of 3 drives needed for a RAID5 array.
[07:43] <Kano> and the space requirement for that module is so big ;)
[07:43] <Kano> why did nobody test dm functionality at all?
[07:44] <TheMuso> Well, the code builds on other architectures, and the code looks ok, so no idea why gcc on powerpc complained about it.
[07:44] <TheMuso> Kano: I don't know, you will have to ask the kernel team. I am only helping out with powerpc, because its a ports architecture I care about.
[07:58] <lifeless> TheMuso: can't you daisy chain sata?
[08:00] <TheMuso> lifeless: not afaik.
[08:00] <TheMuso> lifeless: You're probably thinking of firewire.
[08:01] <TheMuso> In which case, a user could set drives up with firewire, once they were in docks/caddies that supported firewire.
[08:01] <TheMuso> in any case, I think for most users to use ppc for dmraid stuff, it would be too much effort. There is also endianness issues that may yet need resolving.
[08:01] <lifeless> actually, fibrechannel I think is what I was thinking of
[08:01] <smb> That would be my believe as well. sata being 1-1 only
[08:02] <smb> fibrechannel? isn't that a san topology?
[08:02]  * TheMuso learns something new.
[08:02] <TheMuso> I knew of fibre channel, but didn't know it could be chained.
[08:03] <smb> I neither, but my knowledge could be patchy too
[08:06] <smb> TheMuso, Ok, seems with arbitrated loop layout you seem to be able to daisy chain the devices 
[08:07] <Kano> well you can use port mulitpliers for sata
[08:09] <TheMuso> I'm not sure how well those would work.
[09:17] <cking> apw, the fan overheating bug -  I will double check this on my other laptops now.
[09:17] <cking> to see if is generic rather than related to specific models.
[09:17] <apw> cking, thats great.  if you confirm its hibernate which triggers the behaviour then we can ask whether that is a common thread on the bug
[09:18] <apw> also have you tested suspend too?
[09:18] <cking> not yet. I woke up at 3am this morning and it hit me that hibernate was the only thing I've done in both cases where I have done this over the past few months.
[09:19] <cking> ..so I've only just tested hibernate
[10:05] <apw> cking, you should be sleeping when the clock has those kind of times on it
[10:05] <cking> eh?
[10:06] <cking> oh, yeh.
[10:06] <cking> You know how it is, you sleep on a problem then bingo at 3.00am you wake up with a solution
[10:08] <jjohansen> or you could just be an insomniac
[10:08] <amitk> like jjohansen 
[10:08] <amitk> jjohansen: do you ever sleep?
[10:08] <jjohansen> weekends
[10:08] <amitk> heh
[10:10] <cking> not sleeping wrecks the memory 
[10:11] <jjohansen> cking: yep
[10:14] <jjohansen> actually I do usually sleep, I just have a tendency to work until 2 or 3 in the morning
[11:00] <apw> jjohansen, stop confusing me
[11:00] <jjohansen> apw: ?
[11:00] <apw> by being awake allt he time
[11:02] <jjohansen> apw: is that a not so subtle hint?
[11:03] <apw> heh ... you are a little time challenged ... 
[11:08] <apw> cjwatson, we seem to have a further bug relating to the bnx2 firmware loading stuff; we are missing firmware.sh to do the actual load (see bug #394783).  i've pushed up a bzr branch up a bzr branch on that bug which should fix it.  perhaps you could have a look when you are not busy [sic]
[11:08] <ubot3> Malone bug 394783 in udev "Broadcom BCM5708 "SIOCSIFADDR: No such device"" [Medium,In progress] https://launchpad.net/bugs/394783
[11:24] <cjwatson> apw: you need to copy 50-firmware.rules as well
[11:24] <cjwatson> apw: I'd also remove the mention of udebs in the initramfs - that isn't really relevant here and it's confusin
[11:25] <cjwatson> g
[11:25] <cjwatson> apw: Keybuk should sign off on this really
[11:28] <Keybuk> we've generally tried to avoid having firmware in the initramfs *sigh*
[11:29] <apw> cjwatson, ahh ok ... of course.  doh
[11:29] <apw> Keybuk, heh yeah, but we have firmware and no way to load it.
[11:29] <apw> will update the branch and hastle Keybuk instead :)
[11:30] <Q-FUNK> howdy!
[11:30] <Keybuk> apw: err, hang on
[11:30] <Keybuk> back up a *LOT*
[11:30] <Q-FUNK> is there anything else I need to provide for bug #396286 ?
[11:30] <ubot3> Malone bug 396286 in linux "kernel 2.6.31-generic oops after loading initramfs" [Undecided,New] https://launchpad.net/bugs/396286
[11:30] <Keybuk> why are you talking about adding firmware to the initramfs for a *network* card ?!
[11:30] <Keybuk> a network card isn't critical to mounting the root filesystem
[11:31] <apw> Keybuk, it is if its on a netowkr?
[11:31] <Keybuk> apw: so we should add wpa_supplicant to the initramfs as well, just in case they want to NFS mount over a WPA-secured wireless network?! :p
[11:31] <apw> nfsroot i assume in this case, cjwatson was involved in the changes to bring the firmware to a udeb, and may know the use model
[11:32] <Keybuk> when we originally added the netroot support, we decided we'd only support sensible cards
[11:32] <Keybuk> wired network cards that didn't need firmware
[11:32] <Keybuk> also the bug doesn't sound like the user is trying to netboot from it
[11:32] <apw> i am suspicious that we have brought in the bnx2 card to fix something, and that has broken general bnx2 support
[11:32] <Keybuk> it sounds like they have a problem that the module doesn't work even after the system is fully booted
[11:33] <Keybuk> which is more likely a module bug than a udev one
[11:33] <Keybuk> since udev will just supply the firmware later
[11:34] <cjwatson> apw: I was involved in adding firmware to the *udeb*, not to the initramfs, FWIW
[11:34] <apw> for the installer, yes, i am conflating
[11:34] <Keybuk> I would guess that this is a module bug
[11:34] <Keybuk> it's probably setting some insanely stupid timeout for firmware
[11:34] <Keybuk> "if I don't get firmware within 500 ms I'm going to lobotomise myself"
[11:35] <apw> looks like 60s per card in this case yes
[11:35] <Keybuk> 60s should be long enough to boot
[11:35] <Keybuk> but if they have scsi drives, it might not be
[11:35] <apw> but the issue seems to be if it fails, then the driver is loaded, and does not get loaded
[11:35] <cjwatson> we could just take bnx2 out of the initramfs ...
[11:35] <Keybuk> wait, back up again!
[11:35] <apw> cjwatson, that would work i suspect in this case
[11:35] <Keybuk> stop trying to ride the rollercoaster of assumptions
[11:35] <apw> but but but we like that game its loads of fun
[11:36] <Keybuk> there is a wonderful system called "uevents" tied with this thing called the "/sys filesystem"
[11:36] <apw> yep
[11:36] <Keybuk> when a module wants firmware, it creates a kobject in the firmware class
[11:36] <apw> yep
[11:36] <Keybuk> so if a module is calling out for firmware, there will be an entry in /sys/class/firmware for it
[11:36] <cjwatson> (FWIW I'm not assuming anything about the problem here other than "why is bnx2 in the initramfs in the first place, since it needs firmware to work")
[11:36] <Keybuk> cjwatson: well, yes that I'd agree with - I was talking to apw ;)
[11:36] <Keybuk> apw: now, if the module calls out for firmware and just *waits*
[11:37] <apw> my only assumption was that the bug was real and needed fixing :)
[11:37] <Keybuk> then when we run udevadm trigger while booting the full system
[11:37] <Keybuk> udev will see that there's the outstanding firmware request
[11:37] <Keybuk> and
[11:37] <Keybuk> ...
[11:37] <Keybuk> *supply the firmware*
[11:37] <Keybuk> so, all you should need to do to fix this is make the module more patient
[11:37] <Keybuk> arguably it's also a bug that after it fails to get firmware it stays loaded
[11:37] <Keybuk> it should fail to load
[11:37] <apw> but at that point the kernell is waiting 
[11:37] <Keybuk> no
[11:37] <Keybuk> the kernel isn't waiting
[11:37] <Keybuk> the module is waiting
[11:38] <apw> indeed, but the boot process is waiting for the load
[11:38] <Keybuk> no it isn't
[11:38] <apw> so we get a full 2 minute delay for giggle in this case
[11:38] <Keybuk> no we don't
[11:38] <apw> dmesg dissagrees with you
[11:38] <Keybuk> right
[11:38] <Keybuk> that's exactly my point
[11:38] <Keybuk> this is a buggy module
[11:38] <Keybuk> it's doing firmware wrong
[11:38] <Keybuk> it's most likely sitting in a loop going "Dude, where's my firmware?"
[11:39] <apw> well request_firmware interface is the standard way, and thats its semantic
[11:39] <apw> get the firmware and wait for it to occur
[11:39] <apw> so there are three ways forward
[11:39] <apw> 1) fix loading firmware in initramfs
[11:39] <apw> 2) stop loading bnx2 somehow
[11:39] <apw> 3) fix bnx2 somehow
[11:40] <Keybuk> but why is request_firmware() a problem here?
[11:40] <apw> because its a blocking interface
[11:40] <Keybuk> it should only block that one module's _init()
[11:40] <apw> and will that not block modprobe
[11:40] <Keybuk> also request_firmware_nowait() 
[11:41] <Keybuk> though not much uses that
[11:41] <Keybuk> it'll block modprobe
[11:41] <Keybuk> oh, duh
[11:41] <Keybuk> sorry, I was going on a "but we don't call udevadm settle in the initramfs" line
[11:41] <Keybuk> but we do now
[11:41] <Keybuk> to fix a different bug
[11:41] <Keybuk> ok, I concede your point ;)
[11:42] <Keybuk> the way we do the initramfs means you'll block waiting for that modprobe to complete - and it can't
[11:42] <apw> heh ... at least i am not completley mad
[11:42] <Keybuk> yeah, so just don't ship that module in the initramfs ;)
[11:42] <apw> ok ... what decides whats in there i wonder
[11:43] <ogra> auto_add_modules() in /usr/share/initramfs-tools/hook-functions iirc
[11:43] <Keybuk> ogra: correct, it's a hardcoded list there
[11:43] <cjwatson> yes, I have it fixed in my tree
[11:44] <cjwatson> I'll upload now if folks are ok with that
[11:44] <apw> why is bnx2 in there now?
[11:44] <apw> is that a manual list of modules without firmware?
[11:44] <cjwatson> we added lots of random network modules
[11:45] <cjwatson> keen though I normally am to find the reasons why things are as they are right now, I think you ascribe too much thought to that code
[11:45] <apw> hehe ... :)  probabally
[11:45] <apw> ok so i'll shove this bug over to initramfs-tools then
[11:46] <cjwatson> aye
[11:46] <Keybuk> cjwatson: of course, we should probably address the whole needing firmware thing
[11:46] <Keybuk> that code isn't exactly fluffy
[11:46] <Keybuk> if you want to do netroot, we could apply much more common sense to it
[11:47] <apw> is it so bad to just include the firmware loader for that (when and if we decide to so support)?
[11:47] <apw> seems to be two files and the firmware
[11:48] <apw> wihch mostly used to be in the kernel and is sliding out into files
[11:56] <Keybuk> apw: yes, because then we'll suddenly need all the firmware in the initramfs
[11:56] <Keybuk> 11M	/lib/firmware
[11:56] <Keybuk> which is larger than the initramfs itself!
[11:57] <ogra> surely compresses good :P
[11:57] <Keybuk> ogra: why, it's binary blob?
[11:57] <apw> i am never quite sure why we don't only put in the ones we need
[11:57] <apw> into the initrd
[11:57] <ogra> Keybuk, thus the ":P"
[11:57] <apw> given it is rebuilt for every machine
[11:57] <Keybuk> apw: because the kernel never bothered to add any header to a module to list the associated firmware files? :)
[11:58] <Keybuk> so we can't actually *tell* what firmware files we need
[11:58] <Keybuk> and instead would have to maintain a list by hand, to go with the by-hand list of modules
[11:58] <apw> heh now thats a valid arguemnt if there ever was one
[12:08] <cjwatson> apw: we've also long had a general design goal to make disks portable across hardware - that is, if you replace some components in your computer, your Ubuntu installation shouldn't fail to boot, and you should even be able to boot the system on a totally different computer to some reasonable extent - think USB disks
[12:08] <cjwatson> apw: which is why we don't use the MODULES=dep initramfs building mode by default
[12:09] <apw> i have wondered at times if it would make sense to use the current mode for the recovery boot, and a =dep mode for the initrd for the default entry
[12:09] <apw> loading the initrd is pretty slow generally
[12:34] <Keybuk> apw: not really, the fallback case isn't pretty
[12:34] <Keybuk> ie. if we can't mount the filesystem, then we can't write the magic that tells grub to try recovery mode next time
[12:34] <apw> indeed it would be manual i guess
[12:46] <Keybuk> more interesting would be if grub could somehow set that itself
[12:51] <Keybuk> ie. after any menu selection, it remembers that the *next* time it must always use the equivalent recovery mode
[12:51] <Keybuk> a successful boot overrides that
[12:58] <apw> the problem is storing that needs
[13:31] <rtg> apw: are you dropping EXTRA_CFLAGS from Karmic ubuntu/compcache/Makefile ?
[13:32] <apw> i hadn't looked at them, that does seem odd
[13:33] <apw> want me to do that
[13:33] <rtg> apw: I forgot to look at the package from the buildd, but did compcache actually get compiled?
[13:34] <apw> no cause i missed half the fix when committing somehow
[13:34] <apw> its in there as of 1 minute ago and is build tested
[13:34] <rtg> apw: ok, as long as you're mucking around in it, why don't you also fix EXTRA_CFLAGS
[13:34] <apw> yep will do, and i'll shove it into my PPA to build test
[13:35] <rtg> apw: doh! CONFIG_TLSF. what a dunce I am. 
[13:36] <apw> how stupid do i feel having seen it, then not noticed it was missing from the commit
[13:36] <rtg> apw: I'll bet I spent an hour messing with that Kconfig
[13:36] <apw> its in the one above ... which is confusing
[13:41] <amitk> the power of 20-20 hindsight
[13:49] <Keybuk> apw: it looks to me like *everything* exploded
[13:49] <Keybuk> I'm going through that "out of warranty" vs. "not fit for purpose" battle :)
[13:49] <apw> Keybuk, heh ... been connecting mains to the wrong end again?
[13:50] <apw> always loads of fun indeed
[13:50] <Keybuk> of course, I've already found and bid on a replacement unit on ebay
[13:50] <Keybuk> but I like arguing with companies
[13:50] <apw> waht was it before it exploded, it looks very industrial
[13:50] <Keybuk> apw: Creative/Cambridge SoundWorks S750
[13:50] <Keybuk> THX 7.1 amp
[13:51] <apw> wow ... you must like your sound
[13:51] <Keybuk> this is the baby for the office
[13:51] <Keybuk> I have a real amp connected to the tv/blu-ray downstairs :)
[13:51] <Keybuk> my neighbours ... do not like my sound
[13:55] <apw> heh uk houses are not well designed for anything over a pin drop often
[13:55] <apw> Keybuk, you tested that devramfs thing and it worked iirc, is that coming downstream?
[13:56] <Keybuk> apw: it worked well enough that we found udev bugs as a result ;)
[13:56] <Keybuk> ie. devtmpfs is better than udev
[13:56] <Keybuk> it's in gregkh's tree at the moment
[13:56] <apw> heheh
[13:56] <Keybuk> I may ask you to pull it early if it doesn't look like it'll hit .31 but definitely .32
[13:56] <Keybuk> it's self-contained enough that it shouldn't be a problem
[13:57] <apw> yeah its pretty self conftained, though i guess it'd be in .31 if it was going to be
[13:57] <apw> its not exactly a bug fix :)
[13:57] <Keybuk> I'm never sure how the merge window works
[13:57] <apw> in theory once the window closes (when -rc1 ships) no new functionality should be commited
[13:58] <Keybuk> right, which means it's already not in .31 right?
[14:00] <Keybuk> I never quite understand how things work wrt mm
[14:00] <Keybuk> if a patch is "added to the mm tree", how does that then end up in Linus' tree?
[14:04] <amitk> Keybuk: *maybe*, if it is baked for enough time and gets ACKs from some key developers.
[14:05] <apw> yeah on the flip side it _was_ in linux-next
[14:05] <apw> and that means it was meant tomake .31... so hard to tell
[14:05] <amitk> there have been instances of stuff being dropped from -mm after a while
[14:05] <apw> can tell cause steven is bitching that its still there
[14:05] <apw> and -next should in theory go to 0
[14:12] <Keybuk> apw: steven ?
[14:12] <Keybuk> I assume that "its still there" => devtmpfs?
[14:13] <apw> rothwell who runs linux-next, yep devtmpfs is still in the meant for the release pile
[14:13] <apw> yet not merged
[14:14]  * Keybuk wonders how Jan and Val are getting on
[14:15] <apw> last conversation i saw, there was a serious locking issue which needs a rearchitect to fix.  so i am not expecting it to be ready any time soon frankly
[14:15] <apw> we need to start thinking about a fallback position
[14:16] <apw> i am guessing we still have aufs support out there in our tools
[14:19] <Keybuk> we have the unionfs fuse implementation
[14:19] <Keybuk> that seems to vaguely work
[14:19] <apw> i thought performance was poor
[14:22] <Keybuk> sure
[14:22] <Keybuk> poor performance > nothing
[14:22] <Keybuk> especially if we know we have something better still down the line
[14:27] <Keybuk> one day I'll meet the guy who came up with /var/run/utmp and /var/log/wtmp
[14:28] <Keybuk> and if I'm lucky, I will have a chainsaw
[14:33] <ogra> you think he is a lumberjack and need some device to start a conversation ? 
[14:46] <apw> Keybuk, was it you who has the machine that had particularly sucky performance under very high IO load?
[14:46] <Keybuk> yes
[14:47] <apw> if so you might want to test the 31-2.16 kernel, as i have it on my machine and it seems much better.  there are some reclaim changes which are supposed to help keep binary pages in core
[14:47] <apw> which is fingered for the huge 'delays' where apps grey out under compiz
[14:52] <Keybuk> apw: Kay seems very confident that devtmpfs will be in for .32
[14:52] <Keybuk> oh, interesting
[14:52] <Keybuk> is that on the archive now?
[14:53] <apw> yes, any of those on the archive has the fix (for karmic)
[14:53] <apw> i am building in the background here and not spitting feathers
[14:54] <Keybuk> ok installing
[15:08] <rtg_> Keybuk: is the gateway command in /etc/network/interfaces still valid in Jaunty? Mine seems to have stopped working, yet all of the other static address setup commands are correct.
[15:09] <Keybuk> rtg_: don't see why not
[15:10] <rtg_> damn, its the last statement in the file. I've tried several times to get it to set a default route. wonder what gives?
[15:43] <bjf_afk> >
[15:43] <bjf_afk> > Ubuntu Kernel Team Meeting Announcement
[15:43] <bjf_afk> > Today at 17:00 UTC in #ubuntu-meeting
[15:43] <bjf_afk> >
[16:33] <cjwatson> Keybuk: grub/recovery mode> that should be feasible with grub2
[16:36] <cjwatson> Keybuk: there are load_env, list_env, and save_env commands; you give them a preallocated file to scribble in
[16:36] <Keybuk> sure, but that only works once you've got a file to scribble in ;)
[16:37] <Keybuk> if you can't mount the root filesystem, how do you scribble?
[16:37] <cjwatson> right, this only works if grub itself can mount the root filesystem
[16:37] <cjwatson> but if you can't mount the root filesystem, recovery mode is no use anyway!
[16:38] <cjwatson> and there are certainly cases where grub can manage to load the kernel but the initramfs fails for some reason
[17:26] <apw> right, if the file is in the /boot directory we know grub can handle that dir, else it cannot load either itself nor the kernek
[17:59] <bjf> >
[17:59] <bjf> > Ubuntu Kernel Team Meeting Announcement
[17:59] <bjf> > Starting now in #ubuntu-meeting
[17:59] <bjf> >
[17:59] <ogra> scary
[17:59] <ogra> :)
[18:22] <apw> cjwatson, the majority of the recommendations on that ssd blueprint was to use ext4 which you have already done, the other part was about partition alignment
[18:23] <cjwatson> yes, partition alignment is fairly non-trivial
[18:23] <cjwatson> I'm familiar with the issue from a previous mail thread
[18:23] <cjwatson> mostly it depends on a newer parted that's unlikely to be released in time for karmic
[18:24] <cjwatson> using fdisk is totally unacceptable
[18:24] <cjwatson> (in the installer at any rate) - it's very dependent on parted
[18:24] <cjwatson> I'd like to deal with the alignment thing, certainly, just not sure when we can
[18:28] <Sarvatt> an ext4 no journal option would probably be a good thing to add to the installer for SSDs
[18:36] <cjwatson> Sarvatt: is that a mke2fs or mount option?
[18:37] <cjwatson> and is it supported with the kernel/e2fsprogs combination we have?
[18:39] <Sarvatt> mkfs.ext4 -O ^has_journal
[18:39] <Sarvatt> yeah its supported by karmics, not jaunty's though of course
[18:41] <cjwatson> hmm, there's nothing generic I can hook into, will take a bit of work
[18:41] <Sarvatt> it was introduced just after e2fstools 1.41.4
[18:41] <cjwatson> somebody should file a bug on partman-ext3 for it I think
[18:41] <Sarvatt> http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=commit;h=a90f5391dda78f7bc4a8196a78355584ace0adf5
[18:46] <Sarvatt> its nice that e4defrag works now on .31, just defragged 700k files on a drive i converted from ext3
[18:51] <cjwatson> apw,cking: unionfs-fuse is I think barely acceptable, but I'd *much* rather have something in-kernel
[18:51] <cjwatson> it's very much a last resort in my book
[18:51] <apw> cjwatson, ok ... thanks for the input
[19:17] <kdub> kernel bug day?
[19:18] <ogra> apw, unionfs-fuse isnt acceptable for ltsp (where we use union mounted squashfses as well)
[19:20] <ogra> apw, it puts thin client boots into a 4 - 5 min zone 
[19:20] <apw> ogra, thanks for that also
[23:34] <JFo> hi ogasawara sorry it took me so long to get here
[23:34] <JFo> :)
[23:34] <ogasawara> JFo: what's up, glad you made it
[23:34] <JFo> just busier than I thought I would be today
[23:34] <JFo> glad to be here
[23:35] <ogasawara> JFo: have you had a chance to browse through the bug day list - https://wiki.ubuntu.com/KernelTeam/BugDay/20090707
[23:36] <JFo> so I see the bug list and I assume that the name above each group is the assigned engineer for those particular bugs?
[23:36] <JFo> I have :-D
[23:36] <ogasawara> JFo: correct, there is a community section towards the bottom for anyone else interested in helping
[23:36] <JFo> ok
[23:37] <ogasawara> JFo: we can also go through some simpler types of bugs first though if you like
[23:37] <JFo> that sounds good
[23:37] <JFo> I'd like to understand a bit more before I dive in
[23:37] <ogasawara> JFo: right, gimme a sec to get a list of good starter bugs
[23:37] <JFo> ok :)
[23:41] <JFo> interesting, I logged in to Launchpad, but it looks like I am not logged in when I view the kernel bug pages
[23:41] <JFo> I suspect that may be due to some permission I lack
[23:41] <JFo> or team that I am not yet a part of
[23:41] <JFo> hmmm
[23:41]  * JFo goes digging
[23:41] <ogasawara> JFo: no, it's because I stole the lp template for the bug page
[23:42] <JFo> ah hah :-)
[23:42] <JFo> everything becomes clear
[23:42] <JFo> this is a listing you have created just for this purpose I assume?
[23:43] <ogasawara> JFo: correct
[23:43] <JFo> that explains the missing icons
[23:43] <JFo> :)
[23:46] <ogasawara> JFo: ok, lets just start with bug 177026
[23:46] <ubot3> Malone bug 177026 in linux "palm z22 won't sync" [Undecided,New] https://launchpad.net/bugs/177026
[23:46] <JFo> ok
[23:47] <ogasawara> JFo: what happened recently is we transitioned quite a bit of bugs from linux-meta to the linux package
[23:47] <JFo> I see
[23:47] <ogasawara> JFo:  You'll see that the bug was reported quite some time ago (2007-12-17)
[23:48] <JFo> indeed
[23:48] <JFo> so we need the standard response to check this against Jaunty?
[23:48] <ogasawara> JFo: yes!
[23:48] <JFo> or am I skipping ahead?
[23:48] <JFo> cool
[23:48] <ogasawara> JFo: so, if you want, go ahead and post a comment asking them to test Jaunty
[23:49] <JFo> ok
[23:49] <ogasawara> JFo: I think the bug day page may have a stock reply you can use
[23:49] <ogasawara> JFo: of course you'll then set the status to Incomplete at the same time
[23:49] <JFo> right
[23:49] <JFo> the bug page does have a reply
[23:49] <JFo> first one I believe
[23:50] <ogasawara> JFo: that's the one, go ahead and just copy and paste it
[23:50] <JFo> got it.
[23:50] <JFo> where do I set as incomplete?
[23:51] <JFo> Update description/tags?
[23:51] <ogasawara> JFo: if you click on the current status on the Status column it should expand for you
[23:51] <JFo> ah
[23:51] <ogasawara> JFo: in there you can add your comment and update the status all at the same time
[23:52] <JFo> excellent
[23:52] <ogasawara> JFo: since you are not a member of ubuntu-bugcontrol yet there are some Status' you will not have the permissions to set
[23:52] <JFo> done
[23:52] <JFo> I see, what are those?
[23:52] <ogasawara> JFo: for ex Won't Fix and Triaged
[23:52] <JFo> ah, ok
[23:52] <JFo> that makes sense
[23:53] <JFo> ready for the next one :)
[23:54] <ogasawara> JFo: cool, lets just make the next logical progression and handle some Incomplete bugs
[23:54] <JFo> ok
[23:54] <ogasawara> JFo: take a look at bug 84898
[23:54] <ubot3> Malone bug 84898 in linux-source-2.6.20 "After resume, video playback is order of magnitude slower than normal" [Medium,Won't fix] https://launchpad.net/bugs/84898
[23:54] <JFo> got it
[23:54] <ogasawara> JFo: I forgot one thing, if we can backtrack just a sec
[23:55] <JFo> sure
[23:55] <ogasawara> JFo: when a bug is set to Incomplete it obviously indicates it needs more info
[23:55] <JFo> right
[23:55] <ogasawara> JFo: when I set a bug to Incomplete I usually also subscribe to the bug
[23:55] <JFo> ah, good point
[23:55] <ogasawara> JFo: that way when they do provide the information, I'll be notified
[23:56] <JFo> and that bug can be moved forward
[23:56] <ogasawara> JFo: right.  I usually just tick the checkbox "Email me about changes to this bug report"
[23:56] <JFo> I see that
[23:56] <JFo> ok
[23:57] <ogasawara> JFo: alternatively you can click on the "Subscribe" link on the right hand side of the bug
[23:57] <JFo> ok
[23:57] <ogasawara> JFo: ok, no onto the next bug
[23:57] <JFo> k
[23:57] <JFo> I see this one is a WontFix
[23:57] <JFo> for one package 
[23:57] <JFo> and Incomplete for another
[23:58] <ogasawara> JFo: right, a while back the kernel package naming convention changed from "linux-source-2.6.xx" to just "linux"
[23:58] <JFo> so this one may still be WontFix?
[23:59] <ogasawara> JFo: actually it was Won't Fix against the 2.6.20 kernel (because it's past it's End of Life)
[23:59] <JFo> I should have seen that
[23:59] <ogasawara> JFo: it could very well still exist against the current kernel
[23:59] <JFo> ok, so for the new version of the Kernel we need it tested against the Jaunty release
[23:59] <JFo> I see
[23:59] <ogasawara> JFo: right
[23:59] <JFo> ok
[23:59] <JFo> so same as before?