| 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:08 |
| Kano | but that all would only work with a working dm | 07:09 |
| Kano | and that is broken | 07:09 |
| Kano | http://patchwork.kernel.org/patch/33534/ | 07:12 |
| Kano | without all with dm is useless | 07:13 |
| 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:42 |
| Kano | and the space requirement for that module is so big ;) | 07:43 |
| Kano | why did nobody test dm functionality at all? | 07:43 |
| 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:44 |
| lifeless | TheMuso: can't you daisy chain sata? | 07:58 |
| TheMuso | lifeless: not afaik. | 08:00 |
| TheMuso | lifeless: You're probably thinking of firewire. | 08:00 |
| 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:01 |
| 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:02 |
| smb | I neither, but my knowledge could be patchy too | 08:03 |
| smb | TheMuso, Ok, seems with arbitrated loop layout you seem to be able to daisy chain the devices | 08:06 |
| Kano | well you can use port mulitpliers for sata | 08:07 |
| TheMuso | I'm not sure how well those would work. | 08:09 |
| 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:17 |
| 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:18 |
| cking | ..so I've only just tested hibernate | 09:19 |
| apw | cking, you should be sleeping when the clock has those kind of times on it | 10:05 |
| cking | eh? | 10:05 |
| 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:06 |
| 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:08 |
| cking | not sleeping wrecks the memory | 10:10 |
| jjohansen | cking: yep | 10:11 |
| jjohansen | actually I do usually sleep, I just have a tendency to work until 2 or 3 in the morning | 10:14 |
| apw | jjohansen, stop confusing me | 11:00 |
| jjohansen | apw: ? | 11:00 |
| apw | by being awake allt he time | 11:00 |
| jjohansen | apw: is that a not so subtle hint? | 11:02 |
| apw | heh ... you are a little time challenged ... | 11:03 |
| 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:08 |
| 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:24 |
| cjwatson | g | 11:25 |
| cjwatson | apw: Keybuk should sign off on this really | 11:25 |
| Keybuk | we've generally tried to avoid having firmware in the initramfs *sigh* | 11:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| Keybuk | which is more likely a module bug than a udev one | 11:33 |
| Keybuk | since udev will just supply the firmware later | 11:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| apw | wihch mostly used to be in the kernel and is sliding out into files | 11:48 |
| 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:56 |
| 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:57 |
| 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 | 11:58 |
| 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:08 |
| 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:09 |
| 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:34 |
| Keybuk | more interesting would be if grub could somehow set that itself | 12:46 |
| 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:51 |
| apw | the problem is storing that needs | 12:58 |
| rtg | apw: are you dropping EXTRA_CFLAGS from Karmic ubuntu/compcache/Makefile ? | 13:31 |
| apw | i hadn't looked at them, that does seem odd | 13:32 |
| 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:33 |
| 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:34 |
| === smb changed the topic of #ubuntu-kernel to: Karmic Kernel Plan: 2.6.31 -- Kernel Team Bug Day https://wiki.ubuntu.com/KernelTeam/BugDay/20090707 | ||
| rtg | apw: doh! CONFIG_TLSF. what a dunce I am. | 13:35 |
| 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:36 |
| amitk | the power of 20-20 hindsight | 13:41 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:55 |
| 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:56 |
| 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:57 |
| Keybuk | right, which means it's already not in .31 right? | 13:58 |
| 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:00 |
| amitk | Keybuk: *maybe*, if it is baked for enough time and gets ACKs from some key developers. | 14:04 |
| 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:05 |
| Keybuk | apw: steven ? | 14:12 |
| Keybuk | I assume that "its still there" => devtmpfs? | 14:12 |
| apw | rothwell who runs linux-next, yep devtmpfs is still in the meant for the release pile | 14:13 |
| apw | yet not merged | 14:13 |
| * Keybuk wonders how Jan and Val are getting on | 14:14 | |
| 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:15 |
| apw | i am guessing we still have aufs support out there in our tools | 14:16 |
| Keybuk | we have the unionfs fuse implementation | 14:19 |
| Keybuk | that seems to vaguely work | 14:19 |
| apw | i thought performance was poor | 14:19 |
| Keybuk | sure | 14:22 |
| Keybuk | poor performance > nothing | 14:22 |
| Keybuk | especially if we know we have something better still down the line | 14:22 |
| Keybuk | one day I'll meet the guy who came up with /var/run/utmp and /var/log/wtmp | 14:27 |
| Keybuk | and if I'm lucky, I will have a chainsaw | 14:28 |
| ogra | you think he is a lumberjack and need some device to start a conversation ? | 14:33 |
| apw | Keybuk, was it you who has the machine that had particularly sucky performance under very high IO load? | 14:46 |
| Keybuk | yes | 14:46 |
| 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:47 |
| 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:52 |
| 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:53 |
| Keybuk | ok installing | 14:54 |
| 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:08 |
| Keybuk | rtg_: don't see why not | 15:09 |
| 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:10 |
| 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 | > | 15:43 |
| cjwatson | Keybuk: grub/recovery mode> that should be feasible with grub2 | 16:33 |
| 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:36 |
| 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:37 |
| cjwatson | and there are certainly cases where grub can manage to load the kernel but the initramfs fails for some reason | 16:38 |
| 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:26 |
| === bjf_afk is now known as bjf | ||
| 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 | :) | 17:59 |
| === ogasawara_ is now known as ogasawara | ||
| 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:22 |
| 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:23 |
| 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:24 |
| === sconklin is now known as sconklin-brb | ||
| Sarvatt | an ext4 no journal option would probably be a good thing to add to the installer for SSDs | 18:28 |
| === sconklin-brb is now known as sconklin | ||
| cjwatson | Sarvatt: is that a mke2fs or mount option? | 18:36 |
| cjwatson | and is it supported with the kernel/e2fsprogs combination we have? | 18:37 |
| Sarvatt | mkfs.ext4 -O ^has_journal | 18:39 |
| Sarvatt | yeah its supported by karmics, not jaunty's though of course | 18:39 |
| 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:41 |
| Sarvatt | its nice that e4defrag works now on .31, just defragged 700k files on a drive i converted from ext3 | 18:46 |
| 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 | 18:51 |
| === pace_t_zulu is now known as pace_t_zulu|afk | ||
| kdub | kernel bug day? | 19:17 |
| ogra | apw, unionfs-fuse isnt acceptable for ltsp (where we use union mounted squashfses as well) | 19:18 |
| ogra | apw, it puts thin client boots into a 4 - 5 min zone | 19:20 |
| apw | ogra, thanks for that also | 19:20 |
| === pace_t_zulu|afk is now known as pace_t_zulu | ||
| 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:34 |
| ogasawara | JFo: have you had a chance to browse through the bug day list - https://wiki.ubuntu.com/KernelTeam/BugDay/20090707 | 23:35 |
| 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:36 |
| 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:37 |
| 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:41 |
| 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:42 |
| ogasawara | JFo: correct | 23:43 |
| JFo | that explains the missing icons | 23:43 |
| JFo | :) | 23:43 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| JFo | ready for the next one :) | 23:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!