[07:02] <unstable> @schedule New_York
[07:02] <Ubugtu> Schedule for America/New_York: 15 Mar 15:00: Audio Team | 15 Mar 17:00: Ubuntu Development Team | 16 Mar 06:00: MOTU Council | 17 Mar 11:00: Xubuntu | 19 Mar 11:00: Kernel Team | 21 Mar 08:00: Edubuntu
[09:58] <dmang> beep
[09:59] <dmang> ping?
[09:59] <dmang> pong!
[09:59] <dmang> zooooooom!
[06:25] <Klaidas[anapnea] > @schedule Vilnius
[06:25] <Ubugtu> Schedule for Europe/Vilnius: 15 Mar 21:00: Audio Team | 15 Mar 23:00: Ubuntu Development Team | 16 Mar 12:00: MOTU Council | 17 Mar 17:00: Xubuntu | 19 Mar 17:00: Kernel Team | 21 Mar 14:00: Edubuntu
[07:49] <tsmithe> wow that was surprisingly subconscious
[07:55] <tsmithe> could someone ping me when the meeting starts; i'm going through my whore of an inbox
[08:01] <crimsun> tsmithe: ping
[08:01] <tsmithe> ho!
[08:02] <crimsun> all right, let's get started
[08:02] <TheMuso> Is it just us three?
[08:03] <tsmithe> looks like it... does it really matter?
[08:03] <crimsun> Bug triaging best practices (crimsun)
[08:03] <bdmurray> me too!
[08:03] <TheMuso> oh right
[08:04] <crimsun> first, to many people there's some confusion regarding alsa
[08:04] <TheMuso> Re bugs, I have seen what bdmurray, crimsun, and Andrew Ash have been doing in responding to bugs.
[08:04] <crimsun> here we'll lay out guidelines to make triaging a bit less painful
[08:05] <tsmithe> (*smiles*)
[08:06] <crimsun> symptoms such as "sound not working", "sound muted", and anything else falling under "not being able to hear sound under Ubuntu but being able to under $another_os" should be triaged against linux-source-2.6.x, where x is the kernel version for that Ubuntu release
[08:07] <tsmithe> yep
[08:08] <crimsun> i.e., use linux-source-2.6.x instead of alsa-driver, generally, because we don't actively patch the alsa-source binary package (against which alsa-driver, which is in universe, is responsible), whereas we do take care of the kernel
[08:08] <bdmurray> Is ubuntu-audio a subscriber to thse bugs?
[08:09] <crimsun> u-audio subscribes to alsa-driver but not the former, because bugs against linux-source-2.6.x aren't necessarily audio bugs
[08:09] <bdmurray> right, so would it be appropriate to manually subscribe them?
[08:09] <crimsun> yes, that is perfectly acceptable
[08:10] <crimsun> alternately, you can, as you've been doing, triage the bug against alsa-driver, and we'll reassign as appropriate
[08:10] <crimsun> this brings up another subtle point
[08:11] <crimsun> there is one corner case (in terms of actual kernel sound drivers) in which one should triage bugs against alsa-driver instead of linux-source-2.6.x, and that is if alsa-source provides the actual driver instead of linux-source
[08:12] <tsmithe> that's understandable
[08:12] <tsmithe> how do we know that that is the case?
[08:12] <crimsun> in previous Ubuntu releases, this was constrained to drivers like the EchoAudio ones
[08:12] <tsmithe> (just learn?)
[08:12] <TheMuso> crimsun: I guess to check that we need to check what package a driver belongs to?
[08:13] <crimsun> TheMuso: because it's a corner case, modinfo on a default Ubuntu install will help there
[08:13] <TheMuso> crimsun: I still don't quite understand.
[08:14] <crimsun> for instance, if we can see from the bug report that the reporter is using snd-foo, then we can run ``modinfo snd-foo''
[08:14] <crimsun> if nothing is returned, then instead of using linux-source-2.6.x as the triaged package, we can use alsa-driver
[08:14] <TheMuso> crimsun: Right.
[08:14] <tsmithe> ah clever
[08:15] <crimsun> ok, that covers the kernel side ["sound inaudible"] 
[08:15] <crimsun> now, the userspace portion is more mundane
[08:16] <crimsun> generally speaking these bugs are pretty easy to classify: anything dealing with "volume not being restored properly on (reboot)" or the like falls under alsa-utils
[08:17] <crimsun> anything dealing with "resampling sounds very bad" falls under alsa-lib
[08:17] <tsmithe> right
[08:19] <crimsun> now, take for example, bugs that mention volume problems like "regression from Ubuntu X: volume too low" would be linux-source-2.6.x issues, not alsa-utils
[08:19] <tsmithe> uhuh... why so?
[08:19] <tsmithe> does alsa-utils not regress?
[08:20] <TheMuso> Alsa-utils would generally know about the mixer values already I'm guessing.
[08:20] <TheMuso> So it can usually set them.
[08:20] <crimsun> right, Luke's got the idea
[08:20] <tsmithe> hmm ok
[08:20] <crimsun> there are two classes of drivers that will have these types of regressions, the first far more common than the second
[08:21] <crimsun> HDA- and AC97-based ones, respectively
[08:21] <TheMuso> crimsun: Does hda stand for anything?
[08:21] <tsmithe> high-definition audio
[08:21] <tsmithe> :S
[08:21] <crimsun> high definition audio, interestingly enough
[08:21] <TheMuso> right
[08:22] <crimsun> HDA regressions and fixes can be expected for quite some time; we're only beginning to get better support for these newest models
[08:22] <TheMuso> Lovely
[08:22] <crimsun> and as you can tell just by browsing the linux-source-2.6.20 and alsa-driver bugs, most of the audio issues have to do with HDA-based chips
[08:23] <tsmithe> TheMuso, remember, cynicism is not a good path
[08:23] <crimsun> the HDA ones are easier to triage, because we can narrow them to a specific file
[08:23] <TheMuso> tsmithe: Cynicism was furthest from my mind.
[08:24] <tsmithe> :)
[08:24] <crimsun> the file that is the culprit is based on the HDA codec used, which one can get on an Ubuntu install from ``tail -2 /proc/asound/oss/sndstat''
[08:25] <tsmithe> ok
[08:25] <crimsun> [the proper location for HDA is /proc/asound/card0/codec*, but it's different for AC97-based ones, which use /proc/asound/cardX/*codec*/* . Because /proc/asound/oss/sndstat abstracts that difference, and because we load snd-pcm-oss by default in Ubuntu, we use /proc/asound/oss/sndstat] 
[08:26] <TheMuso> Makes sense.
[08:27] <crimsun> one of the more important pages that we use is https://help.ubuntu.com/community/DebuggingSoundProblems
[08:27] <crimsun> this generally gathers enough info for us to triage correctly
[08:27] <TheMuso> I've seen that be requested many a time.
[08:27] <tsmithe> yeah
[08:27] <tsmithe> and people always do it wrong...
[08:28] <TheMuso> tsmithe: ?
[08:28] <crimsun> yeah, some people will dump it all into one comment inline, which can be painful
[08:28] <tsmithe> what he said ^^
[08:29] <crimsun> separate attachments are good
[08:29] <TheMuso> Oh right.
[08:29] <TheMuso> I thought tsmithe meant something different.
[08:29] <tsmithe> no :)
[08:30] <crimsun> a few of us in #alsa are working on a script to grab similar info, http://bulletproof.servebeer.com/alsa/scripts/alsa-info.sh
[08:30] <crimsun> this script will find its way into the upstream project [#upstream/Freenode] , which should help us
[08:31] <crimsun> the long-term intent (jumping ahead momentarily) is to tie this functionality into the hwdb-client
[08:31] <TheMuso> Right.
[08:31] <tsmithe> that would be very nice :)
[08:31] <crimsun> therefore making it transparent to the user.
[08:32] <crimsun> ok, are there any questions on triaging practices, then?
[08:32] <TheMuso> Not from me, everything makes sense.
[08:32] <tsmithe> yea
[08:33] <aouaou> how about the professional audio devices?
[08:33] <crimsun> aouaou: with respect to triaging, can you be more specific?
[08:34] <aouaou> is something going to change in those devices? (sorry i am not an expert just audio professional)
[08:35] <crimsun> aouaou: the scope of your question is fairly broad
[08:35] <aouaou> yes u are probably right.. i should probably let you carry on
[08:36] <crimsun> aouaou: if alsa already supports said pro audio device, then we can work to get it into linux-source-2.6.x if it's not already there
[08:36] <aouaou> ok
[08:36] <crimsun> aouaou: if there are issues other than getting support, like actually adding a driver, that's better addressed upstream [to alsa-devel@ ] 
[08:37] <aouaou> from end-user's scope i think there are some problems with the audio latency
[08:37] <tsmithe> if that's supposed to be @ sourceforge, then they really need to get that subscribers only
[08:37] <aouaou> is there anything that can change that?
[08:38] <_MMA_> aouaou: Latency where?
[08:38] <crimsun> aouaou: on feisty, there're two workarounds of sorts: -lowlatency kernel and the PAM realtime access. Both of these are documented.
[08:38] <aouaou> ok thank you very much. i will check them out
[08:39] <crimsun> aouaou: check in #ubuntustudio
[08:39] <_MMA_> crimsun: There is also a script that addresses some PCI latency issues but thats another topic.
[08:39] <_MMA_> las mentioned it.
[08:39] <crimsun> _MMA_: right, remind me when we get to "Looking ahead to Feisty+1"
[08:39] <TheMuso> I would think that would only be a problem if your hardware was causing latency issues.
[08:39] <_MMA_> k
[08:40] <crimsun> ok, moving on
[08:40] <crimsun> Items remaining for the Feisty release (crimsun)
[08:41] <crimsun> the first issue we have is to make sure we don't regress from Dapper and Edgy for linux-source-2.6.20
[08:41] <crimsun> one area in which I know there are regressions is in the AC97-based quirks
[08:41] <tsmithe> well, my diff for ac97 and intel showed only one regression
[08:42] <tsmithe> but then, there are - i'm sure - unapplied patches from kernel-team@
[08:42] <tsmithe> i'm going to go through and put them all (together?) this weekend some time
[08:42] <crimsun> ok, great
[08:43] <crimsun> for the benefit of others, these AC97-based quirks tend to show up as headphone quirks
[08:43] <TheMuso> Right.
[08:43] <crimsun> particularly with multimedia hotkeys, like VolUp/VolDown/Mute
[08:44] <crimsun> on many of these types of laptops, you often have to bind the 'Headphone' and 'Master' elements together so that the hotkeys work properly
[08:45] <TheMuso> oh fun
[08:45] <tsmithe> right - how does this happen? is there a doc somewhere?
[08:45] <crimsun> Brian and I started working through some of these types of bug reports, tagging them "jack sense" on Launchpad
[08:45] <crimsun> (which is a bit more broad than just that issue, but it narrows things down a bit)
[08:46] <tsmithe> excellent
[08:46] <crimsun> we should actually make those distinct, now that I think about it
[08:46] <crimsun> let's use the "headphone quirk" tag for that
[08:47] <tsmithe> right - this ominously suggests that there are other jack quirks
[08:47] <crimsun> tsmithe: the best documentation would be the source, (un)fortunately
[08:48] <tsmithe> i'm fine with that - any particular areas?
[08:48] <crimsun> http://hg.alsa-project.org/alsa-kernel/file/f8284261b2be/Documentation/
[08:49] <crimsun> generally speaking, ALSA-Configuration.txt is the relevant file
[08:49] <tsmithe> thanks
[08:49] <crimsun> note that f8284261b2be, the changeset hash, is continually updated, so to get the latest using the Web, you'll want to follow tip
[08:50] <tsmithe> "tip"? is that like "head" or "trunk"?
[08:50] <crimsun> (or you can just hg clone alsa-kernel, see instructions on http://www.alsa-project.org/download.php)
[08:50] <tsmithe> i think i must just do that :)
[08:50] <crimsun> yes, tip is the Mercurial equivalent of head/trunk
[08:51] <tsmithe> excellent. makes me wonder why there need be so many names
[08:51] <crimsun> there are so many systems :)
[08:52] <tsmithe> that's not an excuse  ;)
[08:52] <crimsun> ok, speaking of regressions, there's a rather serious one in bug 88332
[08:52] <Ubugtu> Malone bug 88332 in linux-source-2.6.20 "low volume through headphones on HP Pavilion ZT3000 (ICH4) [edgy regression] " [Medium,Needs info]  https://launchpad.net/bugs/88332
[08:53] <tsmithe> that wouldn't happen to be a "Fujitsu Lifebook C1211D", would it?
[08:53] <crimsun> this one's subtle and may require considerable git bisecting
[08:53] <TheMuso> heh. I got 403 when attempting to check out alsa-driver from hg.
[08:54] <crimsun> TheMuso: make sure you use hg.alsa-project instead of hg-mirror.alsa-project
[08:54] <TheMuso> crimsun: right
[08:54] <TheMuso> yep that works
[08:55] <crimsun> with James's issue, we need to cover three areas, core, ac97, and intel8x0
[08:55] <tsmithe> blimey
[08:56] <crimsun> off the top of my head, I can't see why it would have regressed. It doesn't seem to be a power management issue, and there aren't many changes on top of that to those three areas
[08:57] <tsmithe> ok - so how would you go about finding out?
[08:58] <crimsun> via the initial steps, we've established that it's an actual kernel<->hardware issue, and since edgy works where feisty doesn't, we'll need to look specifically at sound/{core/,pci/ac97/,pci/intel8x0.c} differences in the git trees
[08:58] <tsmithe> that's an awfully broad file set
[08:59] <crimsun> thankfully it's smaller than it seems
[08:59] <tsmithe> ah ok
[08:59] <crimsun> in feisty, the header files were shuffled, so we can ignore those changes in sound/pci/ac97/
[09:00] <tsmithe> mmhmm
[09:00] <crimsun> I'll spend some time this evening looking at it, and we'll need to ask James to test 2.6.20-11.18
[09:01] <tsmithe> who are "we"?
[09:02] <crimsun> we -> ubuntu-audio
[09:02] <crimsun> I'll take care of that part
[09:02] <tsmithe> right :)
[09:03] <crimsun> ok, second issue is to keep up with the seemingly endless flood of quirks
[09:03] <crimsun> I try - and I admit I used to be much better about this - to peek into #ubuntu periodically to help with audio issues
[09:04] <tsmithe> yea
[09:04] <tsmithe> i try and catch them as well
[09:04] <crimsun> quite a bit of the quirks gathered in previous Ubuntu releases were from #ubuntu and #alsa
[09:04] <tsmithe> makes triaging much easier, when the reporter is alive
[09:04] <TheMuso> Forgive me if I decide not to go in there again. That channel moves way too quickly for me to follow
[09:05] <crimsun> TheMuso: sure, it's a bear
[09:05] <tsmithe> well, to be honest, i try and catch them outside of there
[09:06] <crimsun> there are many sources besides those two IRC channels in which to get quirks
[09:06] <crimsun> I've neglected crawling through other distributions' bug databases
[09:06] <crimsun> (a glaring error, really)
[09:06] <tsmithe> grgh
[09:07] <_MMA_> Maybe something could be done through the Ubuntu Forums. I know some feedback will come from Ubuntu Studio forums once they open.
[09:07] <tsmithe> well, there has been discussion on -devel-discuss about (or maybe launchpad-users) about that kind of thing
[09:07] <crimsun> _MMA_: I know quite a few sound issues are reported on the forums, but we need a mechanism for transferring those reports into Launchpad
[09:08] <_MMA_> Didnt tsmithe have that covered somewhat with "Forum Ambassadors"?
[09:08] <_MMA_> Thats another subject though.
[09:08] <tsmithe> what was suggested was rather linking of old bugs to new posts. i think the f-a should cover vice versa
[09:09] <_MMA_> Both seem good.
[09:09] <crimsun> ok, that seems reasonable
[09:10] <crimsun> anything else that seems critical for Feisty?
[09:10] <tsmithe> not that i am aware of, certainly
[09:10] <TheMuso> Not that I am aware of.
[09:10] <crimsun> Cory, anything from ubuntustudio's perspective?
[09:11] <_MMA_> I want to ask about freebob and firewire but they might not directly relate to whet the topic here is.
[09:11] <_MMA_> I know we're going to get support questions for firewire devices.
[09:12] <_MMA_> So Im guessing that if Freebob supports it the divice is good.
[09:12] <crimsun> right, and likely freebob + jack alsa-plugin will be the way to go
[09:12] <_MMA_> Ok.
[09:12] <TheMuso> Does freebob support alsa in any way?
[09:12] <_MMA_> So we will have to place an importance on the Freebob project.
[09:12] <tsmithe> would it not have to?
[09:12] <crimsun> currently this means that the user has to download and recompile alsa-plugins (enable the jack alsa-plugin, which is currently disabled)
[09:13] <crimsun> TheMuso: not directly last I looked
[09:13] <tsmithe> so it's directly a jack-only thing?
[09:13] <_MMA_> And why is it disabled?
[09:14] <tsmithe> i was just in the middle of typing "hmm - what's the rationale for that" :)
[09:14] <crimsun> _MMA_: promotion of alsa-plugins to main for the pulseaudio plugin (for Edubuntu)
[09:14] <crimsun> (jack-audio-connection-kit is in universe, which would cause the build to fail)
[09:14] <TheMuso> ah yes
[09:14] <tsmithe> ahh
[09:15] <_MMA_> I see.
[09:15] <TheMuso> If I understand correctly, this plugin makes alsa apps appear as jack apps right?
[09:15] <TheMuso> If so, I've tried to use it before, with poor results.
[09:16] <crimsun> it routes native alsa apps to jack
[09:16] <_MMA_> So whats the way around this for a user?  Recompile alsa-plugins?
[09:16] <crimsun> _MMA_: yes, as noted above
[09:16] <TheMuso> And not all alsa apps allow you to easily change which device they use, especially custom asoundrc setups.
[09:17] <TheMuso> So I guess we ort to move to feisty+1.
[09:17] <tsmithe> yes
[09:17] <tsmithe> i'm trying to find the agenda page... where was it again?
[09:17] <_MMA_> Having a pre-built package for Ubuntu Studio users might have to happen somehow.
[09:17] <crimsun> tsmithe: https://wiki.ubuntu.com/UbuntuAudio/Meetings
[09:17] <tsmithe> thank you
[09:18] <crimsun> _MMA_: we can discuss this post-meeting/offband in us-devel
[09:18] <_MMA_> Ok.
[09:18] <crimsun> ok, moving on to Looking ahead to Feisty+1
[09:19] <crimsun> the first issue here is integrating the DebuggingSoundProblems request info and the alsa-info.sh script into hwdb-client
[09:19] <tsmithe> yup
[09:19] <tsmithe> what can we do to help with this process?
[09:20] <crimsun> well, the first step is to write up a specification so it can be considered for the next development summit in Sevilla
[09:20] <TheMuso> Who will be there to champion it?
[09:20] <crimsun> one of you, hopefully :)
[09:21] <tsmithe> hmm
[09:21] <crimsun> I'm travelling during that month, so I won't be able to attend, unfortunately
[09:22] <_MMA_> joejaxx and I have applied for sponsorship.
[09:22] <tsmithe> hmm
[09:22] <TheMuso> applying for sponsorship.
[09:22] <_MMA_> Whould be great if tsmight or TheMuso could be there.
[09:22] <tsmithe> _MMA_, *ahem*
[09:22] <_MMA_> https://wiki.ubuntu.com/UDS-Sevilla/Attendees
[09:23] <_MMA_> Jane said they will look over that list.
[09:23] <TheMuso> Nothing about sponsorship there.
[09:23] <crimsun> integrating a script into hwdb-client shouldn't be difficult. Keep in mind we need to deal with at least three classes of devices: ISA, PCI, USB
[09:24] <TheMuso> yeah
[09:24] <tsmithe> isa... awh
[09:24] <crimsun> pci and usb are fairly straightforward (with the latter substituting lsusb -vv in place of lspci -vvn)
[09:25] <crimsun> isa's a bit more hairy, so I'll need to ask Scott and others about that
[09:25] <tsmithe> do people actually want those cards supported?
[09:26] <crimsun> yes
[09:26] <TheMuso> Well some mobos have MIDI controllers that are ISA.
[09:26] <crimsun> (and Mark would probably argue yes, too)
[09:26] <TheMuso> Mine included.
[09:26] <_MMA_> crimsun: Ill also get the specific script from las to see if its useful or it might be the same one. :)
[09:26] <crimsun> _MMA_: different issue, but we'll get to it in a second
[09:28] <crimsun> so, start throwing around ideas for hwdb-client integration, and hopefully by our next meeting we have a better idea of how things should piece together
[09:28] <tsmithe> i guess i'll need to get these sources then
[09:28] <tsmithe> is an apt-get source enough, or is there somewhere else i should be looking?
[09:29] <crimsun> https://launchpad.net/products/hwdb-client
[09:29] <tsmithe> excellent
[09:30] <tsmithe> (i'm pretty sure i should be looking by myself)
[09:31] <crimsun> ok, next issue for Feisty+1 is the pro audio bent
[09:31] <crimsun> UbuntuStudio is going to drive a different set of requirements focused on much lower latency, jack integration, and so on
[09:31] <crimsun> ALSA itself needs to be prepared for that
[09:31] <tsmithe> what are the other requirements?
[09:32] <crimsun> _MMA_: is there movement on realtime?
[09:32] <tsmithe> (those that are different to the UbuntuStudio ones?)
[09:33] <TheMuso> crimsun: What needs doing alsa wise?
[09:33] <crimsun> TheMuso: the most invasive change would be a "realtime"ish kernel
[09:33] <TheMuso> right
[09:33] <crimsun> I have not inspected those additional changes; I know some of them are in .20
[09:34] <crimsun> again, this would need a specification on Launchpad, but more importantly, it's going to require convincing BenC
[09:34] <TheMuso> As far as I know, the realtime patches are for ever changing.
[09:34] <TheMuso> From release to release./
[09:35] <crimsun> it's going to be a hard sell, honestly, because it's so invasive and because it changes
[09:35] <crimsun> right
[09:35] <TheMuso> crimsun: I don't believe we will get it in.
[09:35] <_MMA_> Sorry. Kids. :)
[09:35] <TheMuso> When I ran Gentoo, the rt kernel did just totally crap out on me when I least expected it at times.
[09:36] <_MMA_> The most we can hope for are the things Ben has enabled.
[09:36] <crimsun> this is a place where UbuntuStudio can drive, since US will likely be the sole use case
[09:36] <TheMuso> -lowlatency seems to work fine here, although I haven't tested it with a lot of apps at once.
[09:36] <tsmithe> well, surely he's the guy that knows best?
[09:36] <_MMA_> Like has been said, things like Ingos patches are simple too invasive.
[09:36] <TheMuso> I believe RT will be integrated in the mainline kernel over time.
[09:37] <TheMuso> And thereby stabalised.
[09:37] <crimsun> I'm happy to defer it even further (or strike it completely)
[09:37] <TheMuso> Me too.
[09:37] <_MMA_> Ben has also mentioned that Ingo's patches are slowly making it into mainline.
[09:37] <_MMA_> :)
[09:37] <crimsun> right, piece-wise, as verifiable through testing
[09:37] <TheMuso> Yep.
[09:38] <TheMuso> SO eventually everybody will gain.
[09:38] <tsmithe> that would certainly be the best approach
[09:38] <_MMA_> Also some things are changing that make the patched unneeded.
[09:38] <TheMuso> I'm willing to wait for that, as long as we keep -lowlatency around.
[09:38] <tsmithe> i'm not for going for everything to please some people
[09:38] <_MMA_> Ben mentioned a variable timer.
[09:38] <pochu> hey thekorn!
[09:38] <crimsun> _MMA_: likely to be default in Feisty+1, since it has already been merged
[09:38] <thekorn> hi pochu !
[09:38] <crimsun> unless I misparsed linux-kernel@ and LWN
[09:39] <_MMA_> crimsun: Nice. Ill chat with you later about that.
[09:39] <_MMA_> :)
[09:39] <crimsun> (which is entirely possible, since I've been running around)
[09:39] <TheMuso> So what else is there/
[09:39] <crimsun> for Feisty+1, we should work on collaping deltas
[09:39] <TheMuso> Where does pulseaudio stand? As far as I can see, its not enabled in feisty.
[09:40] <TheMuso> crimsun: ?
[09:40] <crimsun> pulseaudio's not default [yet]  in gnome
[09:40] <TheMuso> Right.
[09:40] <_MMA_> I was wondering about PS as well.
[09:40] <_MMA_> gah
[09:40] <tsmithe> will it be?
[09:40] <_MMA_> *PA
[09:40] <crimsun> it's seeded for Edubuntu, and we can install it, but whether it becomes the default is something that would be a good discussion topic at UDS/Sevilla
[09:41] <crimsun> http://live.gnome.org/PulseAudio
[09:41] <_MMA_> I would love to be in on the spec but theres no way I can impliment it. :)
[09:42] <crimsun> _MMA_: likely there will be little to implement if upstream (gnome) pulls it in
[09:42] <_MMA_> True.
[09:43] <crimsun> ok, back to collapsing deltas. We need to ensure our changes get merged back to upstream [ALSA@] 
[09:43] <TheMuso> One thing I would like to have a look at for feisty+1, is the state of portaudio 19.
[09:43] <TheMuso> Yes.
[09:43] <TheMuso> Mainly to work out how stable it is.
[09:43] <TheMuso> I know I'm kinda scratching my own itch here, but anyway.
[09:43] <crimsun> I have been woefully slack about pushing changes back, and that will change.
[09:44] <_MMA_> crimsun: Kinda related. When will you be leaving us?
[09:44] <crimsun> As for portaudio19, I know it's the backend for feisty's Audacity. Does anyone have experience with its stability?
[09:44] <tsmithe> wired is also using portaudio19
[09:44] <ogra> for usage in a default ginem you will need a bunch of patches from the old esd package
[09:44] <ogra> *gnome
[09:44] <ogra> i worked with the pulse package nearly the whole release for ltsp
[09:44] <ogra> its great there, but not ready for gnome as is
[09:44] <tsmithe> (when it gets in)
[09:44] <TheMuso> crimsun: Not really. I am investigating it for espeak.
[09:44] <ogra> imho gnome should be fixed to not require a sound daemon
[09:44] <ogra> afaik there is even a patch to switch everyting to gstreamer
[09:45] <ogra> (for events etc)
[09:45] <tsmithe> ogra, but then there's the issue with initialising that. i'd prefer a simple library to do that
[09:45] <crimsun> _MMA_: (I'm gradually cutting back, but I'm unlikely to disappear completely simply due to the sheer enormity of audio issues)
[09:45] <ogra> tsmithe, but gstreamer is used everywhere else ...
[09:45] <ogra> its silly to dupicate backends
[09:46] <_MMA_> crimsun: So we need to make sure you have a good team in place with a good system to take more pressure of you.
[09:46] <ogra> *duplicate
[09:46] <tsmithe> yes -  but on lower end systems; at login?
[09:46] <_MMA_> *off
[09:46] <crimsun> _MMA_: (what we're doing here)
[09:46] <_MMA_> ;)
[09:47] <crimsun> anyhow, we're perilously close to the devteam meeting, so let's go ahead and close off
[09:47] <tsmithe> ah yes ok
[09:47] <tsmithe> next meeting?
[09:47] <TheMuso> crimsun: Quickly, do we want some wiki pages?
[09:47] <crimsun> TheMuso: yes, that would be useful
[09:47] <tsmithe> i think we should start chucking ideas together for hwdb-client
[09:47] <tsmithe> and minutes?
[09:47] <ogra> tsmithe, well, a cut down gstreamer-minimal ? i'd really not just replace one sounddaemon with another ... but hey i'm not a gnome dev who decides such things :)
[09:48] <tsmithe> ogra, well - i'm with you on that :)
[09:48] <TheMuso> crimsun: As for next meeting, well hows every couple of weeks to make sure we're on target with bugs?
[09:48] <ogra> i just worked with pulse the last months and wanted to throw in my 2cent
[09:48] <tsmithe> great
[09:48] <TheMuso> I'm happy to rotate times to suit other people, given enough notice.
[09:49] <crimsun> if same time on the 29th works, let's shoot for it
[09:49] <TheMuso> Fine by me
[09:49] <tsmithe> not for me
[09:49] <tsmithe> i'm going away to germany the day before, unfortunately
[09:50] <crimsun> ok, how does the 27th look?
[09:50] <crimsun> at possibly 1800?
[09:50] <TheMuso> Fine once again.
[09:50] <tsmithe> 27 is good
[09:50] <TheMuso> The notice is good for me to make it
[09:51] <tsmithe> if i find i have other things planned, i'll email you both
[09:51] <crimsun> ok, let's set it for March 27th 1800 UTC
[09:51] <crimsun> I'll work on these minutes this evening
[09:51] <crimsun> thanks, everyone
[09:51] <TheMuso> crimsun: You sure?
[09:52] <crimsun> oh, if someone else wants to, feel free :)
[09:52] <tsmithe> i'm fine with someone else doing it, tough :P
[09:52] <TheMuso> tsmithe: If you're happy to do so.
[09:52] <tsmithe> *though
[09:52] <tsmithe> ok - i will
[09:52] <tsmithe> where shall i email
[09:52] <tsmithe> ?
[09:52] <tsmithe> (it'll help get things straight in my mind)
[09:52] <crimsun> thanks, tsmithe. See https://wiki.ubuntu.com/UbuntuAudio/Meetings/Minutes  (which you'll have to create)
[09:53] <tsmithe> ok - that's great
[09:53] <tsmithe> @schedule
[09:53] <Ubugtu> Schedule for Etc/UTC: Current meeting: Audio Team | 15 Mar 21:00: Ubuntu Development Team | 16 Mar 10:00: MOTU Council | 17 Mar 15:00: Xubuntu | 19 Mar 15:00: Kernel Team | 20 Mar 18:00: Community Council
[09:53] <tsmithe> looks like ubuntu dev is soon
[09:53] <tsmithe> nothing more?
[09:53] <crimsun> I recommend following https://wiki.ubuntu.com/MOTU/Council/Meetings/Minutes as a template
[09:53] <TheMuso> nope
[09:54] <crimsun> nope, we're all up :) Thanks again!
[09:54] <tsmithe> excellent
[09:54] <TheMuso> np see you guys in other channels
[09:54] <tsmithe> ok everyone - have fun!
[09:54] <tsmithe> pah - too late
[09:55] <mdz> good evening, folks
[09:55] <tsmithe> evening
[09:55] <dholbach> hiya
[09:55] <Keybuk> good evening
[09:55] <mdz> everyone gathering for the dev meeting?
[09:55] <BenC> hey
[09:55] <gouki> Hi
[09:55] <rtg> yo
[09:55] <mdz> cjwatson: ping
[09:56] <tsmithe> crimsun, where should i email about the minutes?
[09:58] <asac> @schedule
[09:58] <Ubugtu> Schedule for Etc/UTC: Current meeting: Audio Team | 15 Mar 21:00: Ubuntu Development Team | 16 Mar 10:00: MOTU Council | 17 Mar 15:00: Xubuntu | 19 Mar 15:00: Kernel Team | 20 Mar 18:00: Community Council
[09:58] <seb128> evening
[09:58] <asac> hi all
[09:58] <mdz> hello asac
[09:58] <fabbione> evening
[09:58] <asac> still audio?
[09:58] <ajmitch> audio meeting just finished
[09:58] <mvo> hello
[09:58] <Keybuk> fabbione: for 2 minutes or in 2 minutes?
[09:58] <fabbione> for 2 minutes
[09:59] <Keybuk> :)
[09:59] <sladen> so that /was/ the audio meeting
[09:59] <asac> :)
[09:59] <mdz> Keybuk: everyone here on your side?
[09:59] <tsmithe> sladen, yes - it was :)
[09:59] <Keybuk> mdz: nowhere near yet
[10:00] <pitti> hi
[10:00] <Keybuk> mdz: Riddell may not make it, he was feeling unwell earlier
[10:01] <mdz> just left a message for colin
[10:01] <Keybuk> colin may have died, since he was up all last night
[10:01] <mdz> he wasn't dead yet a couple of hours ago
[10:02] <BenC> I haven't heard from him in 2 hours
[10:02] <Keybuk> that's about the last time I heard from him too :p
[10:02] <iwj> Colin tells me he'll be along very shortly.
[10:02] <cjwatson> pong
[10:02] <Keybuk> cjwatson: morning
[10:02] <mdz> bdmurray,tkamppeter: ping
[10:02] <pitti> yay for Colin being alive :)
[10:02] <bdmurray> here
[10:03] <mdz> cjwatson: heard from till?
[10:03] <mdz> everyone else seems to be accounted for
[10:03] <Keybuk> mdz: I haven't counted Ken or Tollef yet
[10:03] <mdz> doko is on holiday this week
[10:03] <mdz> Keybuk: colin's team, I mean
[10:04] <cjwatson> haven't heard from till aside from the update he sent
[10:04] <mdz> let's get started
[10:04] <mdz> any adjustments to the agenda?
[10:04] <bdmurray> I made one
[10:05] <mdz> I'd like to add an explicit beta bug review
[10:05] <bdmurray> Added it to the wiki page
[10:05] <kwwii> sorry all
[10:05] <mdz> ok
[10:05] <mdz> (mvo) should we move the command-not-found package to main? or let it mature for one cycle in universe?
[10:06] <Keybuk> Tollef has a broken net connection
[10:06] <mdz> mvo: I, er, thought it was already there.  I use zsh and so I don't notice if it's installed or not ;-)
[10:06] <mdz> mvo: short answer: yes, we should
[10:06] <pitti> I think we shuold only move it to main once we actually want to ship it in -desktop
[10:06] <mdz> mvo: in fact iirc sabdfl wanted it installed by default
[10:06] <pitti> otherwise it doesn't make much sense
[10:06] <mdz> agreed
[10:07] <mvo> mdz: fine with me,  I will add it to the desktop-seed as recommend
[10:07] <mvo> if none objects
[10:07] <mdz> it's equally useful on servers
[10:07] <pitti> mvo: has this exit status bug been fixed?
[10:07] <mdz> but we don't have a proper server metapackage yet, eh?
[10:07] <pitti> mdz: is there something like standard-recommends?
[10:07] <cjwatson> the bug I filed about it has been closed, at least ...
[10:07] <mdz> pitti: that would be a good classification for it
[10:07] <cjwatson> pitti: should work fine in the normal way if you use that seed syntax
[10:07] <mvo> pitti: yes and it will only run in non-posix and interactive shell mode
[10:07] <mdz> standard-recommends would be the place for it
[10:07] <pitti> cjwatson: ah, cool
[10:08] <pitti> mvo: heh, would indeed be nasty in shell scripts :)
[10:08] <fabbione> mdz: ubuntu-minimal basically
[10:08] <mdz> at least one person will write an excited blog entry about that feature ;-)
[10:08] <mdz> fabbione: standard, I think
[10:08] <mvo> :)
[10:08] <pitti> 'hey, I lost my command, and that thing found it'
[10:08] <fabbione> ehheeh
[10:08] <cjwatson> fabbione: ... I'm not sure I want to mess with Recommends in debootstrap; not offhand sure what that would do
[10:08] <cjwatson> I agree with mdz, standard
[10:09] <fabbione> cjwatson: my bad.. -standard
[10:09] <mdz> mvo: ok, so you'll make the necessary changes?
[10:09] <mvo> yes
[10:09] <mdz> sounds good
[10:09] <mdz> (pitti) More interested people for doing source NEW?
[10:09] <mvo> ACTION-ITEM: mvo to seed command-not-found and update the database in it
[10:09] <mdz> pitti: any motivational words to add? :-)
[10:09] <pitti> well, so far I think seb128 does a few source NEWs, but other than that the queue doesn't really shrink except for the things I review
[10:10] <pitti> mdz: yes
[10:10] <iwj> I'd be quite happy to volunteer, if the contributors can stand my pickiness.
[10:10] <pitti> LET'S GET MORE SHINY CRACK INTO UBUNTU!
[10:10] <ogra> yay
[10:10] <kylem> pitti, i'd be interested in source NEW powah.
[10:10] <ogra> iwj, isnt pickiness mandatory for that job ?
[10:10] <pitti> right, it takes a fair while
[10:10] <mdz> iwj: all of the admins should be following the same guidelines, preferably codified
[10:10] <fabbione> iwj: paranoia is mandatory for NEW
[10:11] <iwj> ogra: Sure, but look at the effect on the poor sods whose MIRs I've occasionally touched ...
[10:11] <pitti> reviewing all the files for redistributability, reviewing copyrights, etc.; reviewing packging, too
[10:11] <mdz> I think there is at least one written document
[10:11] <iwj> written document> Excellent, that's what I like to hear.
[10:11] <pitti> iwj: the MIR template is wonderful now
[10:11] <pitti> at least for me, the policy came to me via mouth propaganda
[10:12] <pitti> I'll look for a document
[10:12] <mdz> there's one which comes from debian ftpmaster iirc
[10:12] <cjwatson> it should be linked from ArchiveAdministration
[10:12] <pitti> ah, reject FAQ or so
[10:12] <mdz> which is more like a checklist
[10:12] <cjwatson> (may not be right now)
[10:12] <cjwatson> http://ftp-master.debian.org/REJECT-FAQ.html
[10:12] <ogra> iwj, yes, and even if i will curse you loud and often for all the MIRs you will reject from mine, i love the fact that software entering main will be very well reviwed ... it makes me sleep better :) so apology in advance for the cursing and thanks as well ;)
[10:12] <iwj> pitti: I'd be happy to help codify any random piles of verbiage and woolliness you come across.
[10:12] <cjwatson> I'll make sure it's linked
[10:13] <mdz> pitti: is queue/new visible without archive admin privileges?  that would make it easier to open up review
[10:13] <pitti> mdz: not really
[10:13] <mdz> pitti: I think that would be a good idea
[10:13] <pitti> but it's trivial to copy the packages somewhere
[10:13] <mdz> that way, a large group of reviewers could look at the packages and provide feedback
[10:13] <pitti> right
[10:13] <mdz> perhaps many could be rejected without archive admins having to review yet
[10:13] <pitti> I could build an sftp:// deb archive from chinstrap
[10:14] <cjwatson> Mithrandir: could you extend your unapproved queue mirrorer to do NEW as well?
[10:14] <mdz> pitti: why not http?
[10:14] <cjwatson> tollef already has code for this, might as well reuse it
[10:14] <pitti> mdz: I'm reluctant to put it on a public place
[10:14] <mdz> pitti: these are all signed packages from registered developers
[10:14] <pitti> mdz: since if the stuff is really not redistributable, this might bite us
[10:14] <cjwatson> https:// from chinstrap would be fine
[10:14] <mdz> pitti: things won't stay there permanently, and it's trivial to take things down if there's a problem
[10:15] <pitti> ok, fine for me
[10:15] <iwj> If it's public you'll start getting people referring others to packages in the NEW queue.
[10:15] <cjwatson> we have other stuff there that's passworded
[10:15] <mdz> it doesn't need to be passworded, imo
[10:15] <Mithrandir> cjwatson: no, I would preferably not do that.  It might not be redistributable?
[10:15] <cjwatson> it can be, or can be not, I don't mind
[10:15] <cjwatson> Mithrandir: are you reading the discussion? :-)
[10:15] <pitti> passworded from chinstrap sounds good so far
[10:15] <Mithrandir> cjwatson: yes, just doing so now.
[10:15] <Mithrandir> I can mirror it to chinstrap just fine.
[10:16] <Mithrandir> ideally I'd like an ubuntu-archive account there too, but I guess that's doable.
[10:16] <mdz> I think we only need to worry about w4r3z being redistributed, not developer mistakes
[10:16] <mdz> it's a temporary holding area
[10:16] <pitti> hm, right, any ubuntu-dev could in theory put w4r3z into an existing package as well
[10:17] <mdz> so long as it comes from someone we know, we can publish it temporarily.  if something non-redistributable ends up there, the worst that could happen is that someone points it out and we reject the package -- which is exactly what we're hoping for! :-)
[10:17] <mdz> so fewer barriers -> more review -> less archive admin work
[10:17] <Mithrandir> mdz: point.  So you're fine with making it public?
[10:17] <mdz> Mithrandir: yes
[10:18] <Mithrandir> ok, I'll set that up.
[10:18] <mdz> in the words of the sab, "I'll take the bullets"
[10:18] <pitti> grat
[10:18] <pitti> Mithrandir: you can use your existing code for the unapproved queue archive?
[10:18] <mdz> pitti: you'll talk with iwj about policy, and get something written?
[10:18] <Keybuk> mdz does his neo trick ...
[10:18] <Mithrandir> pitti: it probably needs a small hammer applied to it, but yes, mostly the same code.
[10:18] <pitti> mdz: yes
[10:18] <cjwatson> anything that involves not having to be lp_archive@drescher to do code review is good in my book
[10:18] <iwj> Since there are lots of volunteers perhaps the existing admins should conduct some kind of interview/appointment?
[10:19] <BenC> "Words are like bullets, they pass right through me"
[10:19] <mdz> ACTION: pitti and other archive admins, iwj to codify guidelines for acceptance of new packages
[10:19] <cjwatson> full lp_archive privileges are (a) big and scary and (b) lots of work
[10:19] <mdz> (heno) I'd like to confirm that people generally agree with the 'just in time' ISO testing plan. The aim is to reduce the number of tests each distro person does, though we have to be ready to help out when there are gaps (as always). I'll also do my best to get some baseline test coverage from the community.
[10:19] <cjwatson> so having people come up via NEW review sounds sensible
[10:19] <mdz> heno: I like it
[10:20] <heno> ok, cool
[10:20] <mdz> I gave more detailed feedback on the list
[10:20] <iwj> This plan is what has been discussed in the emails so far, right ?  Is it currently written down in a coherent all-edits-included form ?
[10:20] <mdz> heno: it's only getting better so far
[10:20] <heno> iwj: it's only written in my post to -distro
[10:20] <mdz> iwj: I think this is heno soliciting further feedback before doing that :-)
[10:21] <iwj> mdz: Right :-).
[10:21] <heno> I'm learning as I go :)
[10:21] <mdz> are folks comfortable with the workload balance?
[10:21] <cjwatson> heno: I've started polishing up your descriptions of the various install methods, btw
[10:21] <heno> cjwatson: great, thanks
[10:21] <mdz> we need a lot of hands to cover the testing requirements, but everyone should be able to continue fixing bugs without it interfering
[10:22] <heno> please just email me with individual workload or other feedback
[10:22] <mdz> the process should be mostly non-interactive
[10:22] <Riddell> dfgt#
[10:22] <mdz> download ISOs in the background, start a test and let it run in the background
[10:22] <ogra> Riddell, really ?
[10:22] <Riddell> heno: do the test plans include edg
[10:22] <heno> cr3 is doing some very interesting work with automating iso testing btw
[10:22] <Riddell> heno: edgy to feisty upgrades?
[10:23] <mdz> everyone has at least VMWare, and preferably one machine where they can do install testing without it blocking your work
[10:23] <heno> Riddell: I've not looked enough at that, they should
[10:23] <pitti> seb128: it's really great
[10:23] <pitti> seb128, ogra, asac: module will fail to compile on 2.6.20; talk to me, I have a patch for that
[10:23] <seb128> and I've no machine where I can easily take over the disk
[10:24] <mdz> someone needs to make a patch for vmware-config.pl which uses the pre-built modules from l-r-m
[10:24] <BenC> you can download ws6 beta's with temp license
[10:24] <Keybuk> I only have vmware, and find I can manage quite a few tests
[10:24] <BenC> and test paravirt+vmi too
[10:24] <heno> vmware has a bad accessibility bug though :(
[10:24] <seb128> pitti: ok
[10:24] <mdz> with a fast machine, it's easy to run multiple tests in parallel in vmware
[10:24] <Keybuk> mdz: it can do that?  I just let it build each time
[10:24] <heno> you can't escape out of a session without Ctrl+Alt
[10:24] <cjwatson> heno: I thought you could tweak that in the .vmx
[10:24] <mdz> Keybuk: I'm told that they work, but the perl made me choke when trying to get it to try
[10:24] <mdz> BenC: can someone from the kernel team try a hand at sorting t hat out?
[10:25] <heno> cjwatson: in virtualbox yes, not seen it in vmware
[10:25] <cjwatson> http://www.easyvmx.com/cgi-bin/ikonboard/ikonboard.cgi?act=ST;f=3;t=4
[10:25] <heno> (could be I missed it)
[10:25] <mdz> BenC: you've put the work into getting the modules pre-built and available, we should make use of them to make our lives easier
[10:25] <BenC> mdz: VMWare is working on it for me
[10:25] <BenC> mdz: I'll reping them about it
[10:25] <cjwatson> though that only suggests different combinations of ctrl/alt/shift; having just one of those as the release hotkey would probably be annoying
[10:25] <mdz> note that a patch is required to get the workstation 5.3 modules to build with the feisty kernel
[10:25] <mdz> at least, it was for me
[10:25] <fabbione> mdz: same here
[10:26] <mdz> the details are easily googled if your compile fails
[10:26] <Keybuk> ah, my vmware machine is still on edgy :p
[10:26] <BenC> mdz: Right, our modules are patched to work with 2.6.20, ws6 works out of the box
[10:26] <pitti> mdz: right, I have a fixed vmmon.tar here, I'll pass it to anyone who wants it
[10:26] <mdz> heno: ok, happy with the feedback about your test plan?
[10:26] <cjwatson> iirc the patch is something like "vmware-any-any"
[10:26] <BenC> cjwatson: that's it
[10:27] <mdz> it's a one-liner
[10:27] <heno> mdz: yes, just wanted a basic all clear to proceed as I have been
[10:27] <mdz> ok, great
[10:27] <mdz> (bdmurray - sneaking in) initial bug classification - i.e. with audio bugs crimsun said to use alsa-driver if you weren't positive of the package. What about printing bugs? What about X bugs? and others.
[10:27] <pitti> yes, it's just removing an obsolete #define or so
[10:27] <heno> so no one is very surprised
[10:27] <mdz> really?  I thought audio bugs should move from alsa-driver to the kernel
[10:27] <mdz> given that we don't use the driver in alsa-driver
[10:27] <mdz> I wish alsa-driver were called something else
[10:28] <cjwatson> maybe crimsun finds them easier to handle there or something?
[10:28] <Keybuk> I think the rationale there is that the kernel person who fixes the bugs is subscribed to alsa-driver
[10:28] <mdz> probably a little easier to work with than tags
[10:28] <Keybuk> and they're at least related source
[10:28] <bdmurray> He said they ideally should go to linux-source-x but alsa-driver is subscribed to by ubuntu-audio
[10:28] <Keybuk> and it prevents them getting tangled in random other hardware bugs
[10:28] <dholbach> subscribe the ubuntu-printing team for printer bugs - they usually sort it out
[10:28] <cjwatson> perhaps we could collect names of packages which are used as general holding bins for bugs
[10:28] <cjwatson> or teams
[10:28] <bdmurray> cjwatson: yeah, that was my hope
[10:28] <mdz> bdmurray: there's a web page about teams and bugs
[10:28] <cjwatson> debian-installer, partman-base are other similar holding packages
[10:29] <dholbach> https://wiki.ubuntu.com/Bugs/Teams
[10:29] <mdz> dholbach: thanks, google wasn't finding it
[10:29] <bdmurray> dholbach: however that isn't a package in lp per se
[10:29] <bdmurray> so they still show up in bugs w/o a package which seems less useful
[10:29] <dholbach> bdmurray: i know - but in tricky cases it's best to let a team deal with it, if you really don't know
[10:29] <mdz> bdmurray: I don't know why there are three tables of teams on that page
[10:29] <dholbach> right
[10:30] <mdz> bdmurray: it would probably be a lot clearer if they were collapsed into one
[10:30] <cjwatson> dholbach: there's often a suitable package to be a starting point
[10:30] <dholbach> bdmurray: then I'd suggest setting at least the importance of the bug, so it doesn't show up in unconfirmed/undecided any more
[10:30] <mdz> bdmurray: printing bugs can be in a variety of packages which don't relate directly to printing
[10:30] <dholbach> cjwatson: right
[10:30] <mdz> bdmurray: so they should be filed against whatever's appropriate for the software involved, and the printing team subscribed
[10:30] <cjwatson> I mean very few installer bugs *actually* belong on debian-installer, but it's a perfectly good place to keep them anyway
[10:30] <dholbach> like meta-gnome or gnome-desktop, right seb128? :)
[10:31] <cjwatson> if somebody names a wiki page to put this stuff in, I'll happily brain-dump what I know
[10:31] <bdmurray> cjwatson: right so I was wondering if there were any other perfectly good places for printing and x bugs
[10:31] <cjwatson> if a few other people do that then that should clear up the guts of the problem
[10:31] <mdz> cjwatson: Bugs/Teams is where similar content is; perhaps it should be renamed
[10:31] <seb128> dholbach: gnome-desktop usually yeah :/
[10:32] <mdz> bdmurray: how about first cleaning up Bugs/Teams, getting Colin's brain dump merged into it, and announcing it on -devel-announce to get further feedback?
[10:32] <bdmurray> mdz: what about FindRightPackage?
[10:33] <mdz> that's useful too
[10:33] <dholbach> mvo: . o O { FindingPackages :-) }
[10:33] <mdz> isn't that aimed at reporters rather than triagers though?
[10:33] <bdmurray> true, but is usually reporters who assign bugs to no package
[10:33] <mdz> I had an idea about bug reporting categories once...I think I even wrote it down
[10:33] <cjwatson> there's also a small amount of this on https://wiki.ubuntu.com/Bugs/CommonTasks
[10:33] <mvo> dholbach: :)
[10:34] <bdmurray> so maybe I'll take the team update and trim it down for FindRightPackage
[10:34] <cjwatson> I like having it in Bugs/FindRightPackage
[10:34] <mdz> I agree, those should be merged
[10:34] <cjwatson> I want to be able to tell reporters where to file things in the first place too, for the small subset of them who read that ...
[10:34] <mdz> though neither of the names is suitable for the merged content
[10:35] <dholbach> I think Bugs/Teams is still valid, as some teams have different triaging guides/policies
[10:35] <mdz> dholbach: the content on FindRightPackage isn't really about teams though
[10:35] <dholbach> but let's first just see how big that merged page gets
[10:35] <mdz> ACTION: bdmurray to merge Bugs/Teams and Bugs/FindRightPackage, solicit feedback from developers
[10:36] <mdz> bdmurray: naming is up to you ;-)
[10:36] <bdmurray> mdz: thanks, I guess
[10:36] <mdz> bdmurray: thanks for bringing it up
[10:36] <mdz> (mdz) Review of beta blocker status
[10:37] <mdz> http://launchpad.net/ubuntu/feisty/7.04-beta
[10:37] <mdz> minus the bugs which are already fixed, of course
[10:37] <Keybuk> 404
[10:37] <Ubugtu> Malone bug 62495 in malone "Milestone bug list doesn't sort properly" [High,Confirmed]  https://launchpad.net/bugs/62495
[10:37] <Keybuk> http://launchpad.net/ubuntu/+milestone/7.04-beta
[10:37] <bdmurray> I got a bin file too, if we could have a survey about that later
[10:37] <mdz> right
[10:37] <mdz> defeated by my own error in my firefox history
[10:38] <dholbach> https://beta.launchpad.net/ubuntu/+milestone/7.04-beta for people using beta
[10:38] <seb128> I'm wondering why Mithrandir listed the xmodmap GNOME bug there
[10:38] <Mithrandir> seb128: prompted by James
[10:38] <seb128> dholbach: launchpad does auto redirection to beta
[10:38] <dholbach> seb128: it didn't work for me, it just added beta. for me
[10:38] <seb128> Mithrandir: that doesn't look a beta stopper for me, he's the only one who complained about it
[10:38] <mdz> seb128: yeah, it just takes 30 seconds sometimes
[10:39] <dholbach> it oopsed 3 times and told me the page didn't exist
[10:39] <mdz> dholbach: the url hasn't changed; I just pasted the wrong one
[10:39] <dholbach> ah
[10:39] <seb128> dholbach: Keybuk copied the right one after mdz
[10:39] <mdz> Mithrandir: can you do a greasemonkey script to filter out the fixed bugs from that page? ;-)
[10:39] <dholbach> lalala, ok
[10:40] <mdz> is someone looking into bug 86857?
[10:40] <Ubugtu> Malone bug 86857 in brltty "libbrlapi1 file overwrite with brltty (dup-of: 86694)" [High,Fix released]  https://launchpad.net/bugs/86857
[10:40] <Mithrandir> mdz: yes, I'm intending to.
[10:40] <Ubugtu> Malone bug 86694 in brltty "edgy->feisty dist-upgrade stops at libbrlapi1 ("trying to overwrite /lib/brltty/libbrlttybba.so")" [High,Fix released]  https://launchpad.net/bugs/86694
[10:40] <mdz> oh, it's fixed
[10:41] <cjwatson> xmodmap so does work in feisty, my down key relies on it
[10:41] <mdz> iwj is looking into bug 75681, but the milestone list doesn't show it
[10:41] <Ubugtu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  https://launchpad.net/bugs/75681
[10:41] <Mithrandir> cjwatson: it works for me too, so it's something about the office, I believe.  James has some other bugs nobody are able to reproduce too.
[10:41] <mdz> cjwatson: your lack-of-a-down-key, you mean
[10:41] <Keybuk> mdz: shows it for me
[10:41] <cjwatson> mdz: 75681 is on the list
[10:41] <mdz> Keybuk: it doesn't show the assignment
[10:41] <cjwatson> mdz: exactly
[10:41] <cjwatson> ah
[10:41] <Keybuk> mdz: so does <g>
[10:42] <Keybuk> (though why it appears twice in the list, I've no idea)
[10:42] <cjwatson> because it has multiple bug tasks and apparently somebody can't spell "SELECT DISTINCT"
[10:42] <mdz> I must be crosseyed from the small fonts
[10:42] <iwj> (excuse me, my network just dropped out briefly)
[10:42] <Keybuk> if we're going to discuss launchpad bug list bugs, as well as our own, we'll be here all night <g>
[10:43] <asac> mdz: ctrl-mousewheel :)
[10:43] <mdz> Mithrandir: can you review that list and send out a mail to ubuntu-devel with the real list of beta blockers and who's working on them?
[10:43] <ogra> or ctrl++
[10:43] <Mithrandir> mdz: yes.
[10:43] <mdz> asac: that's dangerous; things get big FAST
[10:43] <mdz> ACTION: Mithrandir to mail out list of beta blockers and assignees to ubuntu-devel
[10:44] <mdz> fabbione: how about certification bugs?  there seemed to be some confusion about how many issues there were
[10:44] <fabbione> mdz: sorted with last Ben email
[10:44] <fabbione> mdz: without info we can't reassign properly.. so they are in a limbo
[10:45] <mdz> fabbione: ok, so they are new bugs without enough info yet, not known issues
[10:45] <fabbione> mdz: they were known for at least 2 milestones
[10:45] <mdz> in that case they are not yet our responsibility to fix
[10:45] <mdz> fabbione: er
[10:45] <fabbione> mdz: but we can't triage them if i don't know where the problem comes from
[10:45] <BenC> fabbione: The ones still in needs info?
[10:45] <fabbione> and they are stalled in needinfo
[10:45] <fabbione> BenC: yes.. the last 3 i mentioned in the mail
[10:45] <BenC> Ok
[10:45] <mdz> fabbione: so they were found a month ago and don't have details yet?
[10:46] <BenC> mdz: Right
[10:46] <fabbione> mdz: yeps.. right.. not enough details to know what is at fault
[10:46] <BenC> aside from that, we only have one real bug we can work on for cert
[10:46] <mdz> ok, I misunderstood, I thought they were somehow new
[10:46] <fabbione> nope
[10:46] <fabbione> there have been no new bugs since herd-4
[10:47] <fabbione> from that point of view herd-5 was really good with no regressions
[10:47] <mdz> fabbione: ok, I will follow up by email about this then
[10:47] <fabbione> mdz: ok
[10:47] <mdz> all actions from the previous meeting were complete?
[10:47] <mdz> that's great
[10:48] <Keybuk> yup
[10:48] <Keybuk> well done everyone
[10:48] <mdz> indeed
[10:48] <mdz> Mithrandir: I heard today that the ISOs have been oversized for a while; is that fixed now
[10:48] <mdz> s/$/?/
[10:48] <pitti> mdz: I removed all langpacks today, so that I can start from a clean slate tomorrow
[10:48] <pitti> wrt. input support and such
[10:49] <Mithrandir> mdz: they haven't been for a while, at least not that I've seen.  I've been waiting for pitti to do his magic wrt langpacks.
[10:49] <pitti> mdz: the only problematic one is ppc/alternate, it's huge and has no langpacks
[10:49] <mdz> i386 desktop is 708M
[10:49] <cjwatson> Jani mailed me today about oversizing in Xubuntu
[10:49] <Mithrandir> pitti: you know you can just ask me for respins too?
[10:49] <pitti> Mithrandir: right
[10:49] <cjwatson> haven't looked at it yet
[10:49] <pitti> mdz: today's images are still too big, tomorrow's ones should fit (except for ppc, but let's not worry about that ATM)
[10:50] <cjwatson> we don't have to worry about powerpc, that was kind of the point of desupporting it
[10:50] <mdz> so the fact that nobody reported this during their pre-beta testing means that you're all using DVD media for your tests, right?
[10:50] <mdz> pitti: indeed
[10:50] <Mithrandir> mdz: I gave all my CDs away more than a year ago.
[10:50] <Mithrandir> being fed up with cdrecord.
[10:50] <fabbione> i still use CD's
[10:50] <Mithrandir> pitti: I'm fine with just ripping random bits off the ppc alternate.  Or even dropping it and saying "desktop or -server".
[10:50] <ogra> mdz, we were probably busy with fixing bugs instead of playing with little silver disks :)
[10:50] <fabbione> but server images are just smaller
[10:51] <kylem> mdz, er, i386-alternate was fine for me on 700M cd.
[10:51] <cjwatson> mdz: or vmware pointed at a .iso ...
[10:51] <mdz> kylem: ok, maybe the oversizing is more recent than I thought
[10:51] <kylem> ah, alternate-i386 is only 701M
[10:51] <Seveas> (i'm fixing ubugtu not to change the topic during meetings, sorry for the annoyance)
[10:52] <pitti> mdz: since Tuesday's feisty langpacks probably
[10:53] <mdz> ok
[10:53] <mdz> any other business?
[10:54] <pitti> mdz: how badly do we want hwdb-increase on the live system?
[10:54] <Keybuk> just a quick SoC note from me:
[10:54] <pitti> mdz: I'm still blocked on that live fs script change for that
[10:54] <Keybuk> the webapp seems broken (shock) and won't show me who's applied to be a mentor yet
[10:54] <Keybuk> but if you could visit the URL I sent out, and fill that in, they should turn up eventually
[10:54] <mdz> pitti: important enough to escalate that to management
[10:55] <pitti> Keybuk: it worked fine today
[10:55] <mdz> has anyone followed up with elmo on it?
[10:55] <pitti> mdz: I can mail elmo about that RT, sure
[10:55] <Keybuk> pitti: yeah, it'll show you as pending -- but it  won't show you as pending to *me* :p
[10:56] <pitti> aha
[10:56] <mdz> Keybuk: what's the deadline?
[10:56] <Keybuk> mdz: for mentor applications?  Marc 23
[10:56] <Keybuk> with an "h" in there
[10:57] <mdz> ok
[10:57] <Keybuk> ideally way before that, since mentors need to rate applications and claim students, etc.
[10:57] <mdz> maybe best to ping individually the people who volunteered on-list and confirm that they signed up
[10:57] <Keybuk> (that's also the student application deadline)
[10:57] <Keybuk> yes
[10:57] <mdz> ok, that's everything then
[10:57] <mdz> thanks, all
[10:57] <mdz> and good night
[10:57] <dholbach> thanks
[10:57] <seb128> thanks mdz
[10:57] <dholbach> to you too
[10:57] <asac> thanks
[10:57] <fabbione> night
[10:58] <bdmurray> thanks and good night
[10:58] <ogra> do we need to have a suggestions page like last year ?
[10:58] <ogra> oh ... to late
[10:58] <iwj> Goodnight everyone.
[10:58] <Keybuk> ogra: wiki.uc/GoogleSoC2007
[10:58] <ogra> Keybuk, thanks ...
[10:58] <ogra> somehow life passed me the last days with beta preparation ....
[10:58] <heno> ogra: I found that the quality of the applications were much better where there was already a detailed spec
[10:59] <ogra> heno, well, on the other had you probably get good initial (but unusable) applications that can get picked up later by others
[11:00] <ogra> but yes, we had that too last year ...
[11:00] <ogra> i'm still undecided if i want to mentor
[12:05] <Seveas> @schedule