[11:53] <flint_> good morning Matt
[12:13] <flint_> emgent, bon martina
[15:55] <james_w> hi all
[15:57] <evand> good morning/afternoon/evening everyone
[15:59] <cjwatson> hello
[15:59] <liw> hi
[16:00] <ArneGoetje> hi
[16:01] <calc> hi
[16:01] <cjwatson> so, we have a few outstanding actions, but mostly I want to talk bugs this meeting
[16:02] <cjwatson> oh yes, let's get this logged
[16:02] <cjwatson> #startmeeting
[16:02] <MootBot> Meeting started at 10:02. The chair is cjwatson.
[16:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:02] <cjwatson> [TOPIC] Outstanding actions
[16:02] <MootBot> New Topic:  Outstanding actions
[16:02] <cjwatson> * liw to give calc access to desktop machine for OOo builds
[16:02] <cjwatson> I think that became irrelevant?
[16:02] <liw> yeah
[16:02] <cjwatson> calc: remember, by the way, that you should have access to the porting machines in the datacentre
[16:03] <TheMuso> UUUUUuUUUUUUUUUUUUUUSSSSSSS/C
[16:03] <TheMuso> .C
[16:03] <cjwatson> calc: I was wondering if it would be worth setting up some kind of shared ccache arrangement there so that multiple people could work on OOo without each having to invest substantial local facilities
[16:03] <TheMuso> OOPS
[16:03] <cjwatson> * calc to upload 3.0 to PPA by end of week
[16:03] <cjwatson> I believe that is now done, thank you
[16:03] <calc> yes that is done
[16:04] <calc> yea at the time i was still evacuated, but got home later that day (iirc)
[16:04] <asac> oops. hi!
[16:04] <calc> but point taken for future use :)
[16:05] <cjwatson> calc: re backports: yes once 3.0 is the default in jaunty; otherwise it's at the discretion of the backports team
[16:05] <calc> ok
[16:07] <cjwatson> doko to extract information about what we lose by targeting Java 1.4 and report back
[16:07] <cjwatson> doko: did you get anywhere on this?
[16:08] <doko> yes, on the phone, 10min
[16:08] <cjwatson> doko: ok, we'll come back to you
[16:08] <cjwatson> hmm, I forgot roll call :-)
[16:08] <cjwatson> asac,slangasek: ping?
[16:09] <cjwatson> bryce seems to be offline
[16:09] <asac> 17:04 < asac> oops. hi!
[16:09] <asac> ;)
[16:09] <cjwatson> oh yes
[16:09]  * TheMuso wipes his eyes. Yay for changing time differences. :)
[16:10] <cjwatson> looks like the Portland mafia had a good night last night
[16:11] <cjwatson> ok, in the meantime, the main thing I'm concerned about at the moment is getting the 8.10 bug list down
[16:12] <cjwatson> I recently discovered https://bugs.launchpad.net/ubuntu/intrepid/+nominations which sort of scared me, although since anyone can nominate I'm not clear on how much I should actually be scared by that
[16:12]  * asac looks
[16:12] <james_w> there are a lot of things on there that could be rejected in my opinion
[16:13] <liw> 556? ouch
[16:13] <cjwatson> I agree, we need to process it but it's not necessarily a matter of adding that all to the intrepid-targeted list
[16:13] <cjwatson> anyway, in the meantime we have the milestoned and targeted lists which are quite long enough
[16:14] <cjwatson> first off, mdz noted that there are quite a few things on https://bugs.launchpad.net/ubuntu/+bugs?field.milestone%3Alist=1326 which aren't on https://bugs.launchpad.net/ubuntu/intrepid/+bugs?field.milestone%3Alist=1326; now that's sort of by design, but the list also includes things at high/critical importance which seems rather odd
[16:14]  * liw adds #278963 to the nominated list
[16:15] <asac> is there an easy way to see the diff?
[16:15] <cjwatson> so this is a reminder, if you're using milestones, please consider whether the bug also needs to be targeted to intrepid - it will only be considered release-critical if it's targeted, otherwise the milestone is just for your own organisational reference
[16:15] <cjwatson> asac: not that I know of ...
[16:16] <cjwatson> there is a long kernel list; while I'm told they believe they can handle it, if there's anything you feel you can help with there, don't be inhibited
[16:17] <cjwatson> 268674 seems in-progress, so I've set it accordingly
[16:18] <cjwatson> calc: I think somebody mentioned 272772 earlier, but it should be a one-liner
[16:19] <calc> cjwatson: ok
[16:19] <cjwatson> asac: summary of 259157?
[16:19] <cjwatson> oops
[16:19] <calc> i'll be doing a new upload for 2.4.1 in the next day or two
[16:19] <cjwatson> [TOPIC] Milestoned bugs
[16:19] <MootBot> New Topic:  Milestoned bugs
[16:20] <asac> cjwatson: i had a short conversation with rtg about driver status yesterday
[16:20] <cjwatson> calc: ok, please set things to fix-committed in the interim so that we know where you are and can avoid bugging you about things you've done :)
[16:20] <asac> cjwatson: we decided that he will look into disabling all "hardware-auto-magic" default parameters for intel drivers
[16:20] <asac> cjwatson: ath8k and ath9k should be in proper shape
[16:21] <asac> i will get more details from him about what that actually means in real life
[16:21] <cjwatson> asac: oh, this is more on the "auto-association in the kernel is bad, mkay" story?
[16:21] <asac> yeah its part of the general discussion we had.
[16:21] <asac> cjwatson: this particular bug was about madwifi/atheros and orinoco
[16:22] <asac> madwifi is now supposed to work with wext
[16:22] <asac> (and not the special madwifi wpasupplicant module)
[16:22] <cjwatson> yeah, it wasn't clear whose court the ball was in from the bug
[16:22] <asac> and rtg said taht hsould be ok
[16:22] <asac> orinoco is most likely not ok. but i am not sure how much effort we should put into these not so widely used cards
[16:23] <asac> cjwatson: its all kernel. and if kernel team says, that they cannot fix something we might need to try to add tweaks in NM ... which isnt really great and there is no guarantee that we can find tweaks that will help more than they break
[16:23] <cjwatson> I have an orinoco in my server :) I don't use NM there though ...
[16:24] <asac> cjwatson: you could at least try. maybe the driver has improved and we dont know :)
[16:24] <cjwatson> we used to have tweaks for those devices, didn't we? so these are regressions
[16:24] <asac> cjwatson: are you using wpa and wext?
[16:24] <asac> cjwatson: well. madwifi tweak isnt possible anymore because wpasupplicant doesnt have that module anymore
[16:24] <cjwatson> asac: neither, and let's just say that arranging to run Ubuntu desktop + NM on that machine would be ... nontrivial
[16:24] <cjwatson> err, sorry, I am using wext
[16:24] <cjwatson> anyway, it's an ancient machine on an old kernel
[16:25] <asac> cjwatson: orinoco tweaks we could look at. but first i want to see a bug about that being reported
[16:25] <asac> cjwatson: it was me who filed this bug when i didnt ported the tweaks ;)
[16:25] <asac> cjwatson: right. i think orinoco is too ancient. if i get complains i will look. but so far i havent seen complains
[16:26] <cjwatson> I know, I'm just noting in general that regressions are the highest-priority category of bugs
[16:26] <asac> cjwatson: right. which is why i created this bug ;)
[16:28] <cjwatson> evand: did anyone get anywhere with 270423?
[16:29] <evand> cjwatson: not yet.  My attention has been focused elsewhere, but I'll give it another look.
[16:29] <evand> very odd bug
[16:29] <cjwatson> asac: do you need help on 247281? the bug doesn't seem to be conclusive
[16:30] <cjwatson> (on what you need a decision on)
[16:31] <asac> cjwatson: yeah. i just made the decision. we cannot have the "real" solution in xulrunner. I will add a hook in ubufox that allows admin to overwrite preferences set in ubufox in /etc/
[16:31] <cjwatson> just made the decision> :-)
[16:31] <asac> thats as simple as adding a link
[16:32] <asac> e.g. /etc/firefox-3.0/pref/ubufox.js -> /usr/lib/ubufox/defaults/preferences/000system-pref.js
[16:33] <cjwatson> hmm, /etc -> /usr symlinks are awkward. It's going to be very tempting for a sysadmin to try to edit that without noticing it's a symlink
[16:33] <liw> the other way around might work better?
[16:34] <asac> cjwatson: sorry it was wrong direction ;)
[16:34] <cjwatson> asac: ah, ok, in that case yes that sounds reasonable
[16:34] <asac> ;)
[16:35] <slangasek> ah, so there is a meeting today :/
[16:35] <cjwatson> evand: 180309 seems to have a patch, although it's risky as it stands because of its use of popen
[16:35] <cjwatson> ~/wg 23
[16:35] <cjwatson> (oops)
[16:36] <evand> Indeed, I talked with the guy from Mandriva a while back about this
[16:36] <evand> Is it appropriate to add that dependency to m-a when it could potentially be included on the alternate CDs some day?
[16:37] <cjwatson> evand: it would have to have a fallback
[16:37] <cjwatson> or argue with the people who decided that localised directory names were a good idea in the first place :)
[16:37] <liw> "
[16:37] <liw> Yet another reason why localised directory names are a daft idea and should be abolished, IMO." -- +1
[16:38] <evand> I suspect the second option would result in a lot of yelling and not any amount of progress :/
[16:39] <cjwatson> well, they should be localised in the UI not the filesystem
[16:39] <evand> cjwatson: fallback>  Do you mean recommends and type?
[16:39] <cjwatson> or words to that effect in C
[16:39] <evand> err type /usr/bin/xdg-user-dir
[16:40] <evand> err right
[16:40] <evand> ok, will do
[16:40] <cjwatson> i.e. use the unlocalised version if calling xdg-user-dir fails
[16:40] <cjwatson> it's not ideal but would probably help
[16:41] <liw> is there no C library to do what xdg-user-dir(1) does?
[16:41] <cjwatson> ok, those are the major bugs I'm concerned about; does anyone have anything else on their packages that they think should be on the list?
[16:42] <evand> yes
[16:44] <cjwatson> evand: ...
[16:44] <evand> the remaining bits for proper usb disk support> uuids in grub/grub-installer, filtering out the /cdrom device, not writing /cdrom to fstab, and handling the grub install target better in ubiquity
[16:44] <evand> not all of those have bug numbers yet, but I'll take care of creating a few
[16:44] <cjwatson> where are we on the UUID work?
[16:44] <liw> why not write /cdrom to fstab?
[16:45] <cjwatson> we have to write /cdrom to fstab for apt
[16:45] <cjwatson> it could be done by uuid if appropriate though
[16:45] <evand> a bit stuck.  KVM USB disk support is broken, so I'm going to have to switch to real hardware to continue developing this, but I should be able to tackle that today.
[16:46] <cjwatson> at least some of the uuid bit should be applicable to hard disks too, I expect
[16:46] <evand> I thought to do it only for USB disks as it would be less risky this late in the cycle
[16:46] <evand> should I shoot for all disks instead?
[16:48] <cjwatson> I would suggest that it'll be quicker to develop it for everything, and then relatively easy to limit it to USB disks only if that's what we choose
[16:48] <evand> noted, will do
[16:48] <cjwatson> doing it for everything would close about a million bugs
[16:48] <mvo> if /cdrom and apt is a problem we should discuss this on the next UDS, a hal based helper would probably a good idea to bring some freshness into the cdrom method
[16:49] <evand> Oh and I've missed 274076 - nominating now
[16:49] <evand> cjwatson: lol, indeed
[16:49] <cjwatson> oh, of course we can't use a UUID for /cdrom, I'm on crack
[16:49] <cjwatson> we may just have to live with that breakage for the moment
[16:49] <evand> ok
[16:50] <cjwatson> mvo: yeah, I agree
[16:50] <cjwatson> apt should definitely autodiscover it
[16:50] <calc> if we could pull some sort of device id to base the mount point off of it could work, but yea removable media doesn't work too well for that :)
[16:50] <cjwatson> by-path, I suppose
[16:50] <calc> probably based off serial number of device or something like that?
[16:51] <cjwatson> as long as it's of the drive not of the disk
[16:51] <calc> yea
[16:51] <mvo> apt-cdrom add/the cdrom method could just try all cdroms via hal
[16:51] <cjwatson> we could do *that* for USB disks only if by-path in sysfs is reliable
[16:51] <mvo> "just"
[16:51] <evand> Can we just not write that line for installation from USB in Intrepid then?  I suspect the lack of functionality will be far less painful than the bug.
[16:51] <evand> ah
[16:51] <cjwatson> evand: that sounds feasible too, yes; it's in partman-target
[16:52] <cjwatson> well, hmm
[16:52] <cjwatson> no, we'd have to remove it at the end of installation instead - /cdrom is used during installation
[16:52] <cjwatson> anyway, we're approaching time
[16:52] <cjwatson> doko: are you off the phone? :)
[16:52] <doko> version for class formats: 1.4, 1.5, and 1.6 do have different class versions, which means that a class file built with a newer class version format cannot be used by older vm's. free vm's like gij or cacao are usually sloppy about this and continue to work as long as no unknown bytecode is seen. but sun's own older vm's are unhappy with this. now fixed by setting the class target version explicitely when building ant (so that
[16:52] <doko>  people can build there own code with a non-Ubuntu vm and the ant binary from Ubuntu). So in the short term nothing is broken in Ubuntu when using our default vm (or gij), but in the long term, every package should explicitely set the minimum source and target format and not use the default target format of the vm. imo, it should be enough to do this for jaunty.
[16:52] <doko> yes
[16:54] <asac> doko: what was the topic again? drop compilers that can produce 1.4 compatible code or drop VMs that can run that code?
[16:54] <cjwatson> the question was the bytecode for which our java packages should be built, and how to achieve that
[16:54] <doko> asac: we had .class files which didn't work with sun-java5 and sun-java-1.4 (aka blackdown)
[16:54] <cjwatson> since openjdk generates 1.6 by default
[16:55] <cjwatson> doko: ant itself, or the cdbs ant task?
[16:55] <doko> changing openjdk-6 isn't an option, upstream doesn't like it
[16:55] <doko> ant itself
[16:56] <asac> yeah ant default would make sense ... have we tried howmany build failures we would get (e.g. because a package needs 1.6, but doesnt say so in ant)?
[16:56] <doko> we maybe could inject the source and target format in the ant task or in cdbs, but again, then will break packages which require 1.5, and not just 1.4.
[16:58] <cjwatson> doko: ok, I agree with you that that's fine for intrepid, but we should include a mention in the release notes
[16:58] <cjwatson> doko: could you write up something for Steve?
[16:58] <doko> ok, will do
[16:58] <cjwatson> [ACTION] doko to write up release notes item about Java bytecode generation
[16:58] <MootBot> ACTION received:  doko to write up release notes item about Java bytecode generation
[16:58] <cjwatson> [TOPIC] AOB
[16:58] <MootBot> New Topic:  AOB
[16:58] <cjwatson> do we have any?
[16:58] <james_w> I've got a couple
[16:59] <asac> a couple for two minutes ;)
[16:59] <cjwatson> james_w: go ahead
[16:59] <james_w> first one is a quick one, if you have any skill at debugging crashes in threaded C code and a spare hour or two please look at the consolekit bug list
[17:00] <james_w> it's plenty crashy it seems, and when it does the user has to restart their session to get things like suspend and some admin access back
[17:00] <james_w> second was something jcastro brought up yesterday, though he's not around right now
[17:01] <james_w> and is something kees brought up a while ago: https://lists.ubuntu.com/archives/ubuntu-devel/2008-September/026460.html
[17:01] <bryce> morning
[17:01] <james_w> we could be releasing Intrepid with regressions in a lot of webcams
[17:02] <asac> james_w: what are the crashes with most dupes?
[17:02] <james_w> http://lwn.net/Articles/291036/
[17:02] <MootBot> LINK received:  http://lwn.net/Articles/291036/
[17:03] <james_w> unfortunately I don't know what needs to happen beyond getting the lib in to main for Intrepid, which is already enough work at this point
[17:03] <slangasek> james_w: is consolekit really all that crashy still?  It hasn't crashed for me since the last upload
[17:04] <slangasek> james_w: workaround for this, if you don't know, is to run 'ck-launch-session' again from a terminal
[17:04] <TheMuso> Yeah a recent ck upload actually allowed the use of sound from the console without being logged tinto GNOME.
[17:04] <asac> slangasek: i cant tell for sure, but yesterday i debugged NM for a while only to find that the issue came from policykit not liking consolekit having crashed at some point
[17:04] <cjwatson> kees' comment is (a) library in main (installed by default?), (b) gstreamer preload patches
[17:04] <james_w> slangasek: no, pitti's done a good job with it, but I still think it could be problematic, and the crashes are beyond my skill.
[17:05] <asac> slangasek: ck-launch-session will make the XDG_SESSION_COOKIE valid again?
[17:05] <james_w> slangasek: I thought that only gave you a bash shell in with a ck session, your desktop session doesn't have the correct key to access things.
[17:05] <james_w> er yeah, cookie, not key
[17:06] <ogra> erm, what in the installer creates the cdrom lines in fstab ??
[17:06] <cjwatson> ogra: partman-target
[17:06] <slangasek> asac, james_w: I don't remember testing NM, but ck-launch-session fixes pulseaudio for me
[17:06] <james_w> slangasek: ok, thanks
[17:06] <ogra> apparently mobile users end up with /dev/sdb /dev/cdrom lines in their installs
[17:06] <ogra> err, /media/cdrom
[17:07] <cjwatson> ogra: #ubuntu-installer or #ubuntu-devel?
[17:07] <ogra> cjwatson, well, apparently -installer
[17:07] <asac> hmm. lets see. anyway, consolekit crashing is really something we should get sorted for release (if its really an issue)
[17:07] <cjwatson> ck-launch-session really looks like it will set a new XDG_SESSION_COOKIE ...
[17:07] <asac> someone should monitor the bug list a bit and see if new crashes come in :).
[17:07] <james_w> asac: bug 269651 is one of the common ones (27 duplicates)
[17:08] <asac> james_w: does any of the dupes have a way to reproduce?
[17:08] <cjwatson> I'll put it in the meeting report (and try to get that out in a slightly more timely fashion), but giving it its own thread would probably get it more attention than that
[17:08] <cjwatson> anyway, feel free to continue discussing it on #-devel
[17:08] <james_w> asac: that's the main problem, I have yet to see a ck crash with a way to reproduce, except when pitti gave one when fixing one of the crashes
[17:09] <ogra> whoops
[17:09] <asac> james_w: is that the daemon that is crashing?
[17:10] <asac> james_w: lets move to -devel
[17:10]  * ogra aplologizes, thought i was in -devel 
[17:10] <cjwatson> ok, we're over time
[17:10] <cjwatson> anything else?
[17:11] <TheMuso> Only the desire for more sleep. :p
[17:11] <james_w> good news?
[17:12] <cjwatson> I figured we were out of time for that, but feel free
[17:12] <cjwatson> [TOPIC] Good news
[17:12] <MootBot> New Topic:  Good news
[17:12] <james_w> sorry
[17:12] <TheMuso> heh
[17:12] <liw> good news: I've done a successful upgrade of my desktop to intrepid, and apart from an fglrx snafu, everything works
[17:13] <asac> good news: we found another bug affecting the save settings feature of the NM keyfile plugin and fixed it upstream
[17:14] <james_w> good news (for me at least): since the last meeting I am a MOTU
[17:14] <TheMuso> Congrats james_w.
[17:14] <asac> so next upload will hopefully have a working system settings read/write backend (again)
[17:14] <cjwatson> good news: intrepid now supports dirac video by default
[17:14]  * asac hugs james_w 
[17:14] <james_w> good news: Intrepid looks like it will ship with a good sugar stack
[17:15] <asac> james_w: is the python-xpcom thing part of that stack?
[17:15] <bryce> congrats james :-)
[17:15] <james_w> asac: yeah, I think we've got that cracked, morgs is going to test later
[17:15] <james_w> thanks all
[17:15] <mvo> liw: you had fglrx installed? did it warn you about it and transition you to something else (u-m)?
[17:15] <liw> mvo, I did not have it installed
[17:16] <liw> mvo, well, not in use
[17:16] <liw> mvo, https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/278963, but let's discuss that elsewhere
[17:16] <cjwatson> all right, I think we're done for now, thanks all
[17:16] <cjwatson> #endmeeting
[17:16] <MootBot> Meeting finished at 11:16.
[17:16] <bryce> thanks
[17:16] <liw> thanks
[17:16] <TheMuso> thanks
[17:16] <james_w> thanks all
[17:17] <evand> thanks
[17:17] <asac> thanks!
[17:17] <ArneGoetje> thanks
[17:18] <slangasek> thanks
[17:59] <davmor2> Hi all
[17:59]  * pedro_ waves
[18:00]  * cgregan waves
[18:00] <bdmurray> Howdy
[18:00] <heno> Hey!
[18:00] <schwuk> hi
[18:00] <ara> hey!
[18:00] <sbeattie> hey
[18:02]  * ogasawara waves
[18:02] <heno> #startmeeting
[18:02] <MootBot> Meeting started at 12:02. The chair is heno.
[18:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:02] <heno> Beta is out, thanks to everyone who helped with that!
[18:03] <heno> [TOPI] Bug fallout from Beta
[18:03] <heno> dumb bot :/
[18:04] <heno> [TOPIC] Bug fallout from Beta
[18:04] <MootBot> New Topic:  Bug fallout from Beta
[18:04] <cody-somerville> heno, you mistyped TOPIC :P
[18:04] <heno> we need an AI bot thatis resiliant to speling erorrs
[18:04]  * cody-somerville nods.
[18:05] <heno> I just wanted to hear what the bug impact from beta has been
[18:05] <heno> esp on the kernel which is scheduled to freeze next thursday
[18:05] <heno> ogasawara: btw, how was the bug day yesterday?
[18:06] <ogasawara> heno: was excellent.  good participation and a lot of bugs got looked at
[18:07] <heno> ogasawara: are we forming a clear list of things that really should be looked at for intrepid?
[18:07] <stgraber> hey there
[18:07] <heno> hey stgraber
[18:08] <ogasawara> heno: yes, most of those get put on my weekly bug list and I also raise bugs on the kernel team call
[18:08] <heno> ogasawara: ok, let me know if there are some I should lobby for
[18:08] <ogasawara> heno: being that kernel freeze is almost upon us, we really need to get as many fixes in asap
[18:08] <stgraber> heno: I won't be in front of my lappy for the whole meeting, I'd just like to add a topic to the agenda: Having the testcases list updated ASAP
[18:09] <heno> we should also raise them on Friday's release meeting
[18:09] <stgraber> heno: I updated a bit the /Cases page with the list of testcases I plan to add and those I need more information to add/update
[18:10] <ogasawara> heno:  I've also started dropping patches for bugs directly to the kernel team ml and they're getting good response (ie getting applied)
[18:11] <heno> cgregan: are you still responsible for the MID/mobile cases?
[18:11] <heno> looks like they need more info
[18:12] <cgregan> heno: Not really
[18:12] <heno> davmor2: could you try making a mythubuntu alternate case?
[18:12] <sbeattie> persia was the one who added them to the page to be added
[18:12] <cgregan> I will advise people on updating, but that is about it
[18:12] <davmor2> heno: np's
[18:13] <heno> davmor2: can you work with persia on adding some MID/mobile cases too?
[18:13] <cgregan> heno: What info, other than the fact that UME is now a netbook release, do they need?
[18:14] <davmor2> heno: this is the new version correct?
[18:14] <persia> Really, the only thing we wanted was the base install cases to start.  The functional cases are not needed at this point.
[18:14] <heno> sbeattie, bdmurray: can you work together again on preparing for the release meeting? that went well last time
[18:14] <sbeattie> heno: sure.
[18:14] <davmor2> persia: when you on-line tomorrow?
[18:15] <bdmurray> heno: yep
[18:15] <heno> davmor2: it sounds like just adapting the desktop install cases should be fine
[18:15] <heno> thanks sbeattie, bdmurray
[18:15] <persia> davmor2, Probably something like 2:00 - 16:00 UTC, but maybe later.
[18:16] <heno> ok, that should cover the tracker changes
[18:16] <heno> [TOPIC] Regression bug triage
[18:16] <MootBot> New Topic:  Regression bug triage
[18:17] <davmor2> heno, persia: Okay I'll get the info off you tomorrow and build that up
[18:17] <heno> a topic for a few weeks, since we started this tracking
[18:17] <persia> davmor2, OK.  Earlier in your morning is probably better.
[18:17] <heno> how is that looking now?
[18:17] <davmor2> persia: np's
[18:17] <heno> thanks davmor2, persia
[18:18] <bdmurray> we are making some progress but there are still a lot out there
[18:19] <heno> right. not surprising as it's our first go at this and we started quite late in the cycle
[18:20] <bdmurray> I've personally started milestoning some bugs for later that should be looked at for Jaunty
[18:20] <heno> speaking of such bugs; cr3: could you test and give feedback on bug 271370 please
[18:22] <sbeattie> bdmurray: what criteria are you using to decide that?
[18:22] <bdmurray> sbeattie: a bug that isn't really important enough to get resolved for Intrepid but should still be fixed - so usually low or wishlist importance ones
[18:22] <heno> sbeattie: you were planning on splitting the list up by importance or release, any news on that?
[18:23] <heno> (not always so easy to pin to a release of course)
[18:23] <sbeattie> heno: sorry, I haven't gotten to that yet; I'll make it a priority.
[18:23] <heno> ok, thanks
[18:24] <heno> sbeattie: np - I know other random things have landed with you as well
[18:25] <heno> [TOPIC] Upgrade testing in VMs
[18:25] <MootBot> New Topic:  Upgrade testing in VMs
[18:25] <heno> I've prepared some kvm images that can be used for upgrade testing
[18:25] <heno> I'll upload them somewhere soon
[18:26] <bdmurray> heno: hardy kvms?
[18:26] <heno> does anyone want to take charge or runing and reporting from those?
[18:26] <_persia> For upgrade testing, is a piuparts run across main not scheduled already?
[18:26] <heno> bdmurray: yes, ubuntu, kubuntu 32 and 64 bit
[18:26] <davmor2> heno: I can start running upgrades on hw tomorrow
[18:27] <heno> _persia: I'll ask liw if he can do a run - it didn't find much last cycle actually
[18:27] <davmor2> heno: I can through a smoke test upgard
[18:27] <davmor2> upgrade page together
[18:27] <davmor2> even
[18:27] <heno> 'real' upgrade tests often find a few issues though
[18:28] <heno> esp with lots of packages installed
[18:28] <persia> heno, Understood, I'm just thinking both types are useful, so we don't miss a corner case.
[18:28] <heno> davmor2: that's great, thanks - do you have flashable hardy images?
[18:28] <heno> persia: agreed
[18:29] <davmor2> heno: I've got partimages of hardy on both my test boxes
[18:29] <heno> cool
[18:29] <cr3> heno: I haven't had time to test the workaround of reboot=b provided by ogasawara, but I could do that as part of my testing this afternoon
[18:30] <davmor2> heno: I'll only be running in the morning though :)
[18:30] <heno> cr3: that's great thanks. the kernel freezes next week, so we have limited time to get such fixes in
[18:31] <heno> davmor2: have you tried using the Virgin package mirror? that may have better speed
[18:32] <heno> (we have the same ISP which does some strange bw capping in the afternoon)
[18:33] <sbeattie> hrm, is there a tool that lets one mirror only a part of the archive?
[18:33] <heno> schwuk: if I get those kvm images to you can you extend them a bit and run them?
[18:34] <heno> sbeattie: probably ask cjwatson, mvo or liw
[18:34] <cr3> sbeattie: what part do you mean?
[18:34] <heno> that's it from me. any other business?
[18:35] <cr3> heno: I'd like to propose extending wireless testing which is weak at best in my lab :(
[18:35] <sbeattie> cr3: a consistent subset of packages+dependencies, so that I don't have to try to mirror the entire archive but still have a locally useful cache.
[18:35] <schwuk> heno: sure
[18:35] <cr3> sbeattie: apt-cacher?
[18:35] <davmor2> cr3: what do you propose?
[18:36] <heno> cr3: as in better coverage in the lab or in the community?
[18:36] <heno> do we have any suitable tools for wireless stress testing?
[18:36] <cr3> davmor2: some decent access point capable of supporting A/B/G, WEP/WPA, TKIP/CCK/etc. all at the same time. then, writing automated tests either using wpa-supplicant or using ara's suite for network manager testing
[18:37] <heno> we already get 'my wireless is broken' reports :)
[18:37] <cr3> heno: if written properly, this could certainly benefit the community
[18:37] <heno> ara: have you looked at nm testing yet?
[18:37] <cr3> heno: what we have is "can you connect to a wireless network" :(
[18:37] <ara> heno: nop
[18:38] <ara> I agree, there are too many hw x cases between ethernet hw and ap hw...
[18:38] <cr3> ara: something to do when you visit :)
[18:38] <ara> cr3: cool :)
[18:38] <heno> sounds like a plan
[18:38] <davmor2> cr3: I can switch mine about and test manually for now and get wifi in for jaunty
[18:38] <cr3> heno: I'll move this forward in parallel with other stuff
[18:39] <cr3> davmor2: for my use case, I can't afford to switch mine about like that :(
[18:40] <heno> cr3: can you draw up a table of modes to test against so davmor2 can test manually in the short term?
[18:40] <davmor2> cr3: most of my machine are wired so it's not so much of an issue for me :)
[18:41] <cr3> heno: sure, I'll be drawing up such a table for myself anyways, so I could glagly share it
[18:42] <davmor2> cr3: ping me with the link dude
[18:42] <heno> cr3: thanks. somewhere on https://testcases.qa.ubuntu.com/ would be good
[18:42] <heno> ok, let's wrap it up - anything else?
[18:43] <heno> #endmeeting
[18:43] <MootBot> Meeting finished at 12:43.
[18:43] <heno> thanks everyone!
[18:43] <ara> thanks!
[18:43] <davmor2> bye
[18:43] <pedro_> thanks