[08:49] <risman> i want compile gcc 2.95.3 but i cant compile on ubuntu 6.10
[08:50] <risman> help me!
[09:03] <leoquant> 6.10 = eggy?
[09:03] <leoquant> not supported anymore by ubuntu
[09:06] <leoquant> please upgrade your system
[09:07] <persia> Well, as importantly, this isn't the right place to ask for support, even when a given version is supported.
[09:09] <stdin> umm [08:51]* risman has quit ("http://www.mibbit.com ajax IRC Client")
[09:09] <stdin> too late
[09:10] <persia> stdin: Indeed, far too late.  The two minute barrier is just as critical :)
[09:45]  * e-jat brb .. zzZZzz sleepy .. 
[09:46]  * e-jat back .. 
[11:20] <nijaba> @schedule
[11:58] <NCommander> good morning all
[11:58] <NCommander> (or afternoon)
[11:58] <norsetto> good TOD
[11:59] <NCommander> It's almost time for the release meeting, no?
[11:59] <TheMuso> Yes pretty much.
[12:00] <NCommander> Any objection if I start it?
[12:00] <norsetto> NCommander: yes
[12:00]  * NCommander doesn't start it then
[12:00] <ScottK> I'm here.
[12:01] <norsetto> sistpoty|work: ?
[12:01] <laga> i'm here, too. the other mythbuntu guys are probably asleep so i'll be the mythbuntu representative.
[12:01]  * ScottK looks around for sistpoty|work
[12:01] <sistpoty|work> sorry, was just at the restroom
[12:02] <sistpoty|work> shall I start?
[12:02] <TheMuso> Ok lets get this show on the road.
[12:02] <sistpoty|work> #startmeeting
[12:02] <sistpoty|work> hm...
[12:02] <sistpoty|work> [startmeeting]
[12:02] <NCommander> THis isn't scheduled meeting is it?
[12:02] <NCommander> Well, offically scheduled
[12:02] <TheMuso> not so much as its on the calendar etc.
[12:03] <NCommander> We've had issues starting xubuntu-dev meetings when we fall off the calendar
[12:03] <NCommander> That or the bot crashed again
[12:03] <sistpoty|work> ok, let's do w.o. MootBot then
[12:03] <persia> The bot hasn't been responsive for the past couple days.
[12:03] <sistpoty|work> welcome everyone to the motu-release meeting :)
[12:03] <NCommander> Thank you sistpoty|work
[12:03] <NCommander> ;-)
[12:03] <sistpoty|work> anyone volunteering to write minutes?
[12:04] <sistpoty|work> if noone volunteers, I'd be up for it
[12:04] <TheMuso> No, as I intend to pull myself from Ubuntu work after this meeting for a week.
[12:04] <TheMuso> sorry
[12:04] <NCommander> I'll do it if no one volunteers
[12:04] <sistpoty|work> ok, thanks NCommander
[12:04] <NCommander> I didn't see an agenda posted for this meeting
[12:05] <ScottK> There isn't a formal one.
[12:05] <sistpoty|work> well, it's pretty much in my head *g*
[12:05] <NCommander> Anyone want to just recap whats on the floor so everyone is on the same page?
[12:05] <ScottK> This is an organizational meeting.
[12:05] <NCommander> oh
[12:05] <sistpoty|work> as it was just brought up on ubuntu-motu, let's start with motu-release <-> ubuntu-release
[12:05] <sistpoty|work> there was the question, whether ubuntu-release may approve motu-release bugs, if there's need
[12:06]  * siretart waves
[12:06] <sistpoty|work> which imo makes sense, what do you think?
[12:06] <sistpoty|work> hi siretart
[12:06] <ScottK> sistpoty|work: They've certainly done it in the past.
[12:06] <TheMuso> Thats fine by me.
[12:06] <ScottK> I doubt we can convince them they aren't allowed to.
[12:06]  * NCommander can't see an issue with it
[12:06] <ScottK> My view is that they may, but they generally ought not.
[12:07] <norsetto> sistpoty|work: I don't see a problem with that, supposed they really willing to take over ...
[12:07] <siretart> consider packages in main with binaries in universe. that's for ubuntu-release anyway, no?
[12:07] <sistpoty|work> siretart: imho yes
[12:07] <TheMuso> sistpoty|work: agreed.
[12:08] <ScottK> Of course.
[12:08] <sistpoty|work> I guess the main use case is packages with MIR's pending (where I usually handed over to ubuntu-release anyways)
[12:08] <sistpoty|work> ok, so we agreed on that one... what next
[12:08] <ScottK> Obviously ubuntu-release must make the release as a whole work and if there's an urgent issue they need to deal with it.
[12:08] <ScottK> Freeze exceptions
[12:08] <sistpoty|work> ScottK: yes, agreed
[12:09] <ScottK> I don't recall.  Did we do one or two ack's in Hardy?
[12:09] <NCommander> I know offhand both mythbuntu and wine have requested standing freeze exceptions, are there any others?
[12:09] <sistpoty|work> ok, how do we handle freeze exceptoins? two acks? one acks? different handling for upstream versions and new packages?
[12:09] <NCommander> (both had sFFes in hardy. It required two acks from -release)
[12:09] <ScottK> NCommander: I was going to go with standing exceptions next
[12:09] <TheMuso> 2
[12:10] <NCommander> Oh, my bad
[12:10] <persia> I'd like to request that any universe flavour be permitted to shift selected software, etc. without a specific freeze exception.
[12:10] <TheMuso> we did 2 afaicr
[12:10] <laga> persia: ACK
[12:10] <TheMuso> persia: seconded
[12:10] <sistpoty|work> persia: what do you mean with "shift selected software"?
[12:10] <norsetto> 2
[12:10] <ScottK> persia: Let's deal with exceptions after the basic process.
[12:10] <persia> Also tweak default settings, and the like.
[12:10] <persia> sistpoty|work: changes to seeds.
[12:10] <sistpoty|work> ah, yes, sure
[12:10] <laga> persia: and add new artwork ;)
[12:11]  * ScottK gives up.
[12:11] <persia> laga: Well, that's covered under the ArtWorkDeadline, which I believe is separate.
[12:11] <laga> indeed.
[12:11] <sistpoty|work> ok, do we want to go with 2 acks again?
[12:11] <ScottK> laga: But not if it has to go through the New queue.
[12:11] <ScottK> Yes.
[12:11] <TheMuso> yes.
[12:11] <ScottK> persia: I don't think there is one anymore.
[12:11] <\sh> what is a universe flavour?
[12:11] <norsetto> +1
[12:11] <persia> \sh: Xubuntu, Mythbuntu, Ubuntu Studio, Ubuntu Mobile, Ubuntu MID
[12:11] <ScottK> Nevermind, there is.
[12:11] <sistpoty|work> ok, so 2 acks it shall be
[12:11]  * NCommander has some notes on seeds when we get there
[12:12] <ogra> ScottK, Artwork deadline is in about a month
[12:12] <ScottK> ogra: Thanks.  Just looked.
[12:12] <sistpoty|work> ogra: there is more than one artwork deadline actually *g*
[12:12] <NCommander> There were some recent changes w.r.t. to how seeds are being handled now. Not sure if -release is fully aware
[12:12] <laga> ScottK: i don't see what's wrong with getting new artwork thru NEW
[12:12] <\sh> persia: shrug
[12:12] <cjwatson> FWIW our experience in core was that seed freezes were tempting but a waste of time
[12:13] <ScottK> laga: Part of the reason for not allowing new packages is late in the release cycle is archive admins have stuff other than New to do.
[12:13] <cjwatson> they're not necessarily more disruptive than other code changes and might as well just be considered in the same light, i.e. whether they're internal changes or whether they actually introduce new features
[12:13] <ScottK> Personally, I think each flavor with a seed needs to manage it.
[12:13] <ScottK> I don't see that as an issue for motu-release.
[12:13] <sistpoty|work> ok, maybe we want to go straight to delegatoins?
[12:13] <NCommander> ScottK, that's happened. At least with xubuntu, we directly control our own seed now.
[12:14] <laga> ScottK: there are always exceptions. not allowing NEW packages because "archive admins have other stuff to do" is not exactly a good reason.
[12:14] <sistpoty|work> do we want delegations again?
[12:14] <ScottK> laga: Requiring one ask for an exception is not the same thing as saying none will be allowed.
[12:14] <ScottK> sistpoty|work: Yes.
[12:14]  * sistpoty|work is also in favor
[12:14] <laga> ScottK: agreed. EOD.
[12:14] <norsetto> sistpoty|work: definetively yes from me
[12:14] <TheMuso> agreed.
[12:14] <\sh> if we can move those packages handled by the "universe flavour teams" out of the scope of the general motus, agreed...if they break something, we are not at fault...
[12:15] <persia> And if they break something, their images fail, which tends to be a strong motivation to fix it.
[12:15] <\sh> that means, merging, syncing for the next release will only be work on by those teams, right?
[12:15] <ScottK> \sh: Not necessarily.
[12:15] <ScottK> It just means they get to manage their own release process.
[12:15] <sistpoty|work> ok, so what teams do we delegate to? iirc we had mozilla, kubuntu, desktop, mythbuntu and xubuntu in the last cycle... any team I forgot?
[12:15] <raphink> @schedule paris
[12:16] <norsetto> sistpoty|work: didn't we have ubuntustudio too
[12:16] <NCommander> sistpoty|work, studio
[12:16] <ScottK> Not a team, but we also had WINE.
[12:16] <TheMuso> I'm expecting there to be a bit of activity as we settle the rt kernel.
[12:16] <sistpoty|work> norsetto: right, I forgot that TheMuso handled studio
[12:16] <sistpoty|work> (as a delegate *g*)
[12:17] <sistpoty|work> any teams we should add to the list for this cycle?
[12:17] <persia> ubuntu-mobile-dev for Ubuntu Mobile and Ubuntu MID please
[12:17] <ScottK> I think KDE should definitely be delegated to Riddell.  He'll manage it for Main and it'd be silly for us not to let him deal with the whole thing.
[12:17] <norsetto> any reason actually to have wine having a standing exception?
[12:17] <persia> Also, Ubuntu-Studio-dev for Ubuntu Studio
[12:17] <ScottK> persia: We need individuals.
[12:18]  * ogra raises hand for ubuntu-mobile
[12:18] <persia> ScottK: OK.  _MMA_ for Ubuntustudio, ogra for ubuntu-mobile, lool for ubuntu-mid
[12:18] <\sh> norsetto: because you want the latest release always for wine...
[12:18] <sistpoty|work> what's ubuntu-mid?
[12:18] <NCommander> norsetto, wine drops new updates every two weeks, and very few rdepends. Having a newer wine allows better windows software compatibility
[12:18] <norsetto> \sh:  why?
[12:18] <persia> sistpoty|work: Really small devices.
[12:18] <laga> superm1 and me for mythbuntu
[12:18] <ogra> sistpoty|work, 4-7" devices
[12:18] <ScottK> sistpoty|work: Similar to mobile
[12:18] <sistpoty|work> ah
[12:18] <norsetto> yes, thats also true for other packages, I don't see why wine is special
[12:18] <ogra> ScottK, totally different :) but yes
[12:18] <laga> (unless there are objections because i'm not a motu)
[12:18] <sistpoty|work> what about edubuntu? ogra do you have sets in universe?
[12:19] <\sh> norsetto: because with every release wine gets better, we have two week releases...and that needs to be handled ... wine has at least no rdepends and doesn't break anything else
[12:19] <ogra> sistpoty|work, there is one metapackage LaserJock maintains
[12:19] <ogra> sistpoty|work, bit the bigger amount is in main
[12:19] <norsetto> \sh: as I said, that true for., hmmm, 50% of universe packages?
[12:19] <persia> \sh: Wine does have rdepends.
[12:19] <ScottK> I think superm1 for mythbuntu
[12:19] <cjwatson> sistpoty|work: "mobile internet device"
[12:19] <siretart> NCommander: I'm not sure I follow that argument, because if we did, we would have to update it every two weeks in -updates as well
[12:19] <NCommander> That was (roughly) the justification the original standing FFE was given last time around
[12:20] <NCommander> I'm not saying it was right or not ;-)
[12:20] <laga> ScottK: i'd like to nominate myself, too. i've spent a lot of time inside these packages.
[12:20] <persia> laga: I think it's best one person per flavour, unless you think it oughtn't be cody-sommerville
[12:21] <laga> alright.
[12:21] <NCommander> This is for seed managment?
[12:21] <sistpoty|work> ok, ScottK suggested superm1 for mythbuntu... +1 from me
[12:21] <laga> not sure what cody-sommerville has to do with mythbuntu ;)
[12:21] <\sh> persia: oh well...I see...i wonder what is education-desktop-othger
[12:21]  * NCommander got slightly lost
[12:21] <\sh> other even
[12:22] <sistpoty|work> norsetto, TheMuso, DktrKranz: superm1 for mythbuntu?
[12:22] <ScottK> I'm going to suggest that WINE should no longer get a free pass because it's past 1.0 now.
[12:22] <TheMuso> Yes.
[12:22] <persia> NCommander: For delegated approvals for seed-specific stuff.
[12:22] <norsetto> ScottK: +1
[12:22] <NCommander> If its xubuntu related, I can do it
[12:22] <TheMuso> ScottK: I am enclined to agree.
[12:22] <DktrKranz> sistpoty|work, +1
[12:22] <\sh> can someone ask yokozar ?
[12:22] <norsetto> sistpoty|work: +1
[12:22] <sistpoty|work> ok, so superm1 for mythbuntu...
[12:22] <NCommander> Agreed on wine, +1
[12:22] <TheMuso> Yes.
[12:22] <siretart> sistpoty|work: I'd like to nominate \sh and myself for updates to 'fai'
[12:22] <sistpoty|work> cody for xubuntu?
[12:22] <ScottK> \sh: If he wants an exception, I'm unlikely to say no, but I think he should ask.
[12:22] <siretart> sistpoty|work: and 'live-initramfs'
[12:23] <norsetto> sistpoty|work: +1
[12:23] <ScottK> sistpoty|work: Yes.
[12:23] <TheMuso> cody for xubuntu yes
[12:23] <\sh> ScottK: na now that I see that other packages are stupidly depending on wine...
[12:23] <sistpoty|work> ok, agreed on xubuntu/cody
[12:23] <ScottK> siretart: Why does FAI need an exception?
[12:23] <sistpoty|work> let's first discuss the remaining teams we already agreed on so far, ok?
[12:24] <NCommander> Has anyone asked cody about handling approvals of seed related stuff? ATM, any xubuntu-dev can manipulate the seed now
[12:24] <sistpoty|work> kubuntu: Riddell? (and Riddell would you accept the delegation again?)
[12:24] <ScottK> NCommander: How he manages that is up to him.
[12:24] <sistpoty|work> agreed
[12:24] <NCommander> ok
[12:24] <ScottK> sistpoty|work: Definitely.
[12:24] <NCommander> +1 on Riddel for kubuntu
[12:24] <ScottK> asac for mozillateam
[12:25] <TheMuso> ScottK: +1
[12:25] <sistpoty|work> ScottK: yep... asac also ok with the delegatoin?
[12:25] <\sh> what about python-launchpad-bugs?
[12:25] <ScottK> \sh: What about it?
[12:25] <DktrKranz> \sh, isn't it in main?
[12:25] <sistpoty|work> let's first discuss teams please... instead of single packages :)
[12:25] <ScottK> Historically there have been very few per-package delegations.
[12:25] <ScottK> OK.
[12:25] <\sh> oh good :)
[12:26] <ScottK> Did we cover all the teams?
[12:26] <Riddell> sistpoty|work: can do
[12:26] <NCommander> What about xubuntu-eee, that's a different team from normal xubuntu
[12:26] <sistpoty|work> excellent, thanks Riddell
[12:26] <siretart> ScottK: I haven't merged the current svn yet. It doesn't make too much sense to merge it in the beginning of the cycle anyways
[12:26] <TheMuso> who did we decide for studio?
[12:26] <ScottK> NCommander: Is that a derivative for xubuntu then?
[12:26] <persia> NCommander: It's not an official flavour at this point.
[12:26] <ScottK> TheMuso: You.
[12:26] <sistpoty|work> TheMuso: we didn't anything yet... do you want to handle studio again?
[12:27] <TheMuso> I'm not bothered either way, only that I won't be here for the next week.
[12:27] <NCommander> Ok, just making sure
[12:27] <persia> I propose _MMA_ for approvals, unless TheMuso especially wants it.
[12:27] <TheMuso> I'm not bothered either way.
[12:27] <ScottK> _MMA_ then.
[12:27] <sistpoty|work> +1
[12:27] <TheMuso> +1
[12:28] <sistpoty|work> norsetto, DktrKranz?
[12:28] <DktrKranz> no objections
[12:28] <ScottK> Before we get off of teams, I think we also need to discuss what packages it covers.
[12:28] <norsetto> sistpoty|work: sorry, I was distracted by another discussion
[12:28] <laga> ScottK: yes.
[12:28] <sistpoty|work> np
[12:29] <persia> ScottK: There are more teams.  Can we cover the rest before we move to that?
[12:29] <sistpoty|work> we still have -desktop
[12:29] <sistpoty|work> (at least)
[12:29] <ScottK> Gnome has a standing freeze exception
[12:29] <sistpoty|work> for hardy, I think it was policy to subscribe ubuntu-desktop, but I'd actually prefer an individual
[12:29] <ScottK> That's from ubuntu-release.
[12:29] <sistpoty|work> ScottK: but only core gnome-packages
[12:30] <sistpoty|work> (i.e. these that drop out of a gnome release)(
[12:30] <ScottK> OK.
[12:30] <sistpoty|work> well, any suggestions?
[12:31] <DktrKranz> isn't a "gnome freeze exception" too free for sparse packages in universe?
[12:31] <ScottK> I think for those that get release in Gnome, it's covered.  For desktop packages in Universe, not in Gnome there is no exception.
[12:31] <ScottK> DktrKranz: It's packages released as part of Gnome, not all packages that use Gnome.
[12:31] <persia> I think only if they are part of the official GNOME release.
[12:31] <ScottK> Yes.
[12:31] <ScottK> Same for Riddell and KDE.
[12:31] <DktrKranz> ah, thanks for the clarification
[12:32] <norsetto> ScottK: so, should we assume all kde4- packages have a standing freeze exception or not ?
[12:32] <sistpoty|work> ScottK: hm... actually I thought Riddell could handle any kde packages, wether these were part of kde or the surroundings (since he certainly knows best how these fit in)?
[12:33] <ScottK> sistpoty|work: For delegations, I agree.  For the standing freeze exception that I know KDE will need, no.
[12:33] <sistpoty|work> ah, k
[12:33] <ScottK> I'd leave it to Riddell to decide if it's KDEish enough and approve it if he cares to.
[12:34] <sistpoty|work> agreed
[12:34] <ScottK> It may be there's a person or two on motu-release who knows a little about KDE also.
[12:34]  * sistpoty|work only uses it :P
[12:34] <ScottK> We'll work on that.
[12:34] <sistpoty|work> ok, back to gnome-desktop... do we want delegations, and if so whom?
[12:35] <ScottK> Isn't Keybuck the lead for that?
[12:35] <DktrKranz> seb128?
[12:35] <ScottK> Personally I think we don't need it.
[12:35] <persia> I thought pitti was the Desktop lead now.
[12:35] <norsetto> sistpoty|work, scottk: wasn't that seb128?
[12:35] <ScottK> I've no idea.
[12:35] <sistpoty|work> norsetto: certainly was... no idea if he still is though
[12:35] <norsetto> last cycle it was seb128 anyway
[12:36] <Riddell> seb128 is your man for gnome packages
[12:36] <ScottK> Riddell: Thanks.
[12:36] <persia> Anyway, for Ubuntu Desktop, Ubuntu Server, and Edubuntu, everything ought be in main, so I don't see the rationale for motu-release delegation: surely that requires ubuntu-release attention.
[12:36] <sistpoty|work> ok, agreed then, but we'll still need to ask him
[12:37] <sistpoty|work> ubuntu-mobile?
[12:37] <ScottK> persia: I know the KDE situation better.  In that case there are official KDE packages that we leave in Universe.  I'd imagine Gnome is the same.
[12:37] <ScottK> That was ogra, right?
[12:37] <sistpoty|work> +1 for ogra
[12:37] <persia> ScottK: Ah, that makes sense then.  Objection withdrawn.
[12:38] <TheMuso> +1
[12:38] <ogra> yep, that was me
[12:38] <DktrKranz> if ogra is fine with it, +1
[12:38] <sistpoty|work> norsetto?
[12:38]  * ogra is :)
[12:38] <norsetto> also if ogra is not fine with it, +1 :-)
[12:38] <ogra> lol
[12:38] <sistpoty|work> heh
[12:39] <sistpoty|work> ubuntu-mid?
[12:39] <ScottK> ogra: Will you be working out of the official repository this release or will you maintain something separate also?
[12:39] <ScottK> sistpoty|work: lool
[12:39] <sistpoty|work> +1
[12:39] <ogra> ScottK, official only
[12:39] <ScottK> ogra: Thanks.
[12:39]  * ogra has never used PPAs for packages 
[12:40] <ogra> i'm actually not a fan of separation :)
[12:40] <sistpoty|work> DktrKranz, TheMuso, norsetto: lool for ubuntu-mid?
[12:40] <DktrKranz> persia, aren't you involved in -mid too?
[12:40] <TheMuso> +1
[12:40] <ogra> DktrKranz, as he is in mobile
[12:40] <norsetto> sistpoty|work: +1
[12:40] <sistpoty|work> and lool: would you accept the delegation?
[12:40] <ogra> DktrKranz, persia is involved in *everything* ;)
[12:41] <persia> DktrKranz: Yes, but I'm not on a release team.
[12:41] <DktrKranz> heh :)
[12:41] <DktrKranz> +1 for lool for -mid as well
[12:41] <norsetto> persia aka the Ubuntu deus-ex-machina
[12:41] <ScottK> I have to go wake up my daughter.  Back in two.
[12:41] <sistpoty|work> ok, any other team that I forgot right now?
[12:41] <ogra> yeah, he has root on all your machines ... beware
[12:41]  * sistpoty|work is scrared *g*
[12:42] <persia> sistpoty|work: Did you do -server?
[12:42] <sistpoty|work> nope
[12:42] <persia> Do you want to do -server?
[12:42] <lool> sistpoty|work: I do
[12:42] <DktrKranz> there are several packages in universe, AFAIK
[12:42] <sistpoty|work> so what about -server? imo it's covered by ScottK, but I wouldn't necessarily mind a delegation
[12:42] <sistpoty|work> thanks lool
[12:42] <DktrKranz> (for -server)
[12:43] <DktrKranz> so, if server team has plans for some of them, a delegation should be granted
[12:43] <lool> win 10
[12:43] <lool> Ups
[12:44] <sistpoty|work> TheMuso, norsetto: server-team? if so, suggestions?
[12:44] <ScottK> If you all want to delegate, I'm OK with it.
[12:44] <DktrKranz> mathiaz could do the job, if he agrees
[12:44] <TheMuso> I don't know who to suggest, but I'm ok with deligations.
[12:44] <sistpoty|work> DktrKranz: -1
[12:44] <ScottK> I would object to Mathiaz
[12:44] <sistpoty|work> due to recent incidents *g*
[12:44] <norsetto> sistpoty|work: whats better than good old ScottK
[12:44] <sistpoty|work> norsetto: +1 for ScottK
[12:44] <DktrKranz> ah... ruby...
[12:45] <ScottK> I'm not convinced we need a server delegate, but if others feel the need, I don't object.
[12:45]  * siretart has to agree with ScottK that the ruby issue wasn't handled very ubuntu-like. at least not what I would expect from someone who signed the CoC
[12:45] <norsetto> siretart: pls. lets not start this here ...
[12:45] <sistpoty|work> ScottK: /me doesn't have a preference, as you'll handle it either way ;)
[12:46] <sistpoty|work> DktrKranz, TheMuso, norsetto: so ScottK as delegate, or motu-release for server?
[12:46] <sistpoty|work> (or s.th. else=
[12:47] <persia> I don't see the point of assigning a delegate who is also motu-release.
[12:47] <persia> Let's skip server.
[12:47] <norsetto> sistpoty|work: I said it already, scottk all the way
[12:47] <TheMuso> If ScottK is up for it, thats fine by me, thats if he thinks the server team needs deligations.
[12:47] <ScottK> persia: It means I don't need ack #2.
[12:47] <persia> Ah, then it is worth a vote :)
[12:47] <DktrKranz> I'm fine with ScottK, motu-release hat is not a blocker, IMHO
[12:48] <sistpoty|work> otherwise TheMuso would be out *g*
[12:48] <sistpoty|work> (for studio)
[12:48] <sistpoty|work> ok, then ScottK/ubuntu-server
[12:48] <sistpoty|work> more teams?
[12:48] <DktrKranz> sistpoty|work, if persia had motu-release, he's out for *everything* :)
[12:49] <sistpoty|work> haha
[12:49] <norsetto> DktrKranz: be aware, He is taking notes
[12:49] <sistpoty|work> ScottK: you were questioning about package sets of delegations, right?
[12:49] <ScottK> Yes.
[12:49] <sistpoty|work> go ahead then ;)
[12:50] <ScottK> As an example, the myth packages are important to mythbuntu, but they are not the only user.
[12:50] <sistpoty|work> ok, I guess if there's a certain amount of overlap, it's better that motu-release coordinates, what do you think?
[12:50] <ScottK> For Xubuntu, I think we delegate xfce and xubuntu specific packages, but not necessarily every single package they seed.
[12:50] <ScottK> Yes.
[12:51] <ScottK> In the last cycle, there was a myth specific excption that was granted by motu-release.
[12:51] <TheMuso> sounds ok to me
[12:51] <sistpoty|work> I usually did ask the affected teams anyway last cycle for input
[12:51] <ScottK> So for mythbuntu it's packages specific to them.
[12:52] <ScottK> For xubuntu, it's xubuntu packages and xfce4
[12:52] <ScottK> For Studio it's there specific packages and ???? - not sure what
[12:52] <ogra> .oO(what *are* xubuntu packages ? seeded ones ?)
[12:52] <ogra> (or mobile in my case)
[12:52] <ScottK> Their meta-packages, artwork, the like.
[12:52] <persia> meta, settings, artwork, etc. ?
[12:53] <_MMA_> -rt
[12:53] <ogra> not the ones that are only used n their seeds as well ?
[12:53] <sistpoty|work> well, I assume that delegates will ask back if unsure, so I'm not too sure if need to come down to specific package sets
[12:53] <ScottK> I'd like to ask the delgatees what they think it should cover.
[12:53]  * ogra would like to cover all packages that are only explicitly in his seed 
[12:53] <ScottK> ogra: Perhaps, but not if you aren't the only one that has it seeded
[12:53] <ogra> right
[12:53] <ogra> then motu-release needs to apply
[12:53] <ScottK> ogra: Could you generate a list of what that covers?
[12:54] <sistpoty|work> oh, damn... I must run in 7 minutes :(
[12:54] <ogra> not right away yet, but i can do one, yes ... we should probably all do that
[12:54] <ScottK> Generically, I'd like to see each delegate give us a list of what they think they've got covered
[12:54] <ScottK> Yes.
[12:54] <ogra> yeah
[12:54] <NCommander> sistpoty|work, I may have to run before this meeting is over, if so, I'll read the logs and write the notes when I get back
[12:54] <sistpoty|work> ScottK: sounds like a nice idea..
[12:54] <_MMA_> Rough list: https://wiki.ubuntu.com/UbuntuStudio/PackageList
[12:54] <laga> ScottK: for mythbuntu, we'll need everything in the mythbuntu-* namespace, anything involving mythtv and stuff like xmltv
[12:55] <sistpoty|work> at least it would avoid confusion whom to ask
[12:55] <sistpoty|work> NCommander: kk
[12:55] <ScottK> laga: We'll have to argue over that a bit then since you aren't the only interested party with mythtv, but we needn
[12:55] <ScottK> needn't do it now
[12:55]  * DktrKranz needs to go right now, read the log
[12:55] <persia> Right.  Perhaps delegates could reply to the mail including the meeting minutes with an explicit list of packages they are asking to be able to approve?
[12:55] <ogra> right
[12:55] <persia> motu-release could then approve or amend the list?
[12:56] <TheMuso> sounds good.
[12:56] <ogra> or suggest changes
[12:56] <_MMA_> ﻿But it doesn't need to be everythng. Off the top of my head I'd say anything ubuntustudio-*, -rt kernel Ardour and JACK are usually ones that need love in past cycles.
[12:56] <laga> ScottK: same argument applies to xubuntu - they aren't the only ones interested in xfce.
[12:56] <persia> laga: Let's not argue specifics here.  Just submit the list, and see what can be approved.
[12:57] <ogra> we should probably discuss that on the ML ... i would think the team that *mostly* uses them might also be a valid case
[12:57] <laga> okay.
[12:57] <_MMA_> sure
[12:57] <sistpoty|work> ok, agreed on the lists thingy
[12:57] <ogra> laga, i.e. i might like dvb-utils in mobile at some point ... but i'd happily leave decisions for that to mythbuntu
[12:58] <ScottK> I'll be back in about two minutes
[12:58] <ScottK> Keep going
[12:58] <sistpoty|work> ok, what else do we need to cover?
[12:58] <norsetto> wifeys is calling for luch, gotta go
[12:58] <laga> ogra: i dont think dvb-utils sees that many changes :) and it's not like people want to break stuff. IMHO it's about taking care of packages you know well without having too much bureaucracy
[12:59] <laga> but that's a bit OT now
[12:59] <ogra> was just an example :)
[12:59]  * ogra has a conf call now ... but will lurk
[12:59] <sistpoty|work> standing freeze exception process?
[12:59]  * lool same as ogra 
[12:59] <sistpoty|work> how about a mail to ubuntu-motu and at least three ubuntu-release membes giving a +1 to grant one? other ideas?
[13:00] <sistpoty|work> s/ubuntu-release/motu-release/
[13:00] <sistpoty|work> damn, gotta run as well :(
[13:00] <TheMuso> sistpoty|work: sounds good
[13:00] <TheMuso> i will reply when I return from my holiday.
[13:01] <sistpoty|work> TheMuso: have fun!
[13:01] <ScottK> Fine with me.
[13:01] <sistpoty|work> oh, personal side note: I'll be on vac during next week as well...
[13:02] <ScottK> Per package delegations is next.
[13:02] <sistpoty|work> ScottK: can you take over hosting, as I need to go now?
[13:02] <ScottK> OK.
[13:02] <sistpoty|work> thanks
[13:02] <ScottK> I'm not convinced we have a quorum anymore for decision making.
[13:03] <ScottK> I'd suggest anyone who feels a need for a per-package delgation mail the MOTU ML and we'll discuss it.
[13:04] <TheMuso> I agree.
[13:04] <ScottK> OK.  Anything else?
[13:04] <james_w> I have a suggestion
[13:04] <james_w> well, two
[13:04] <ScottK> Yes?
[13:04] <ScottK> I have something else too
[13:05] <ScottK> I propose we get rid of the diffstat requirement in freeze exceptions.  It's pretty meaningless.
[13:05] <ScottK> james_w: Go ahead.
[13:05] <james_w> firstly, I think having a clear policy within the team about how a member should put a hold on a particular freeze exception while more discussion happens, or something similar, is a good idea.
[13:06] <james_w> and perhaps extending that to how people outside the team might be able to do that.
[13:06] <ScottK> Generally we've done that by needing +2 but not approving if any motu-release member had an objection.
[13:07] <ScottK> And if others have input, I don't think we'd ignore that an press on.
[13:07] <siretart> james_w: like in 'writing 2-3 sentences risk analysis' for each requst?
[13:07] <james_w> well, there was an incident last cycle where a couple of members were unhappy that a change was uploaded while they felt their concerns were still outstanding
[13:07] <TheMuso> ScottK: +1 for removing the need for diffstats.
[13:08] <james_w> making it clear what should happen should help avoid that.
[13:08] <ScottK> Fair enough.
[13:08] <siretart> ScottK: the diffstat shows that the requester did take a look at the diff
[13:08] <ScottK> siretart: I think it shows they know how to run the diffstat command.
[13:09] <ScottK> Actually looking is a different issue.
[13:09] <james_w> I think asking for an overview of the changes and an assesment of the risk is far more effective at showing that, and far more useful
[13:09] <ScottK> I know this is something cjwatson had a strong opinion on.
[13:09] <cjwatson> oh god yes
[13:09] <cjwatson> namely, please get rid of the diffstat requirement, it's never been useful :)
[13:09] <ScottK> +1
[13:09] <siretart> ScottK: well, it still makes it more obvious at once how big the changes are. but maybe we are too lax anyways with granting exceptions to large changes so they've become meaningless already
[13:10] <cjwatson> in fact in some cases it's been counterproductive because people send the diffstat rather than the diff :)
[13:10] <siretart> oh
[13:10] <ScottK> I think having something about risk assessment is more useful.
[13:10] <cjwatson> if release team members want a diffstat it's surely not difficult to run it themselves; they need to glance over the diff anyway
[13:10] <cjwatson> if a release team member is approving things without looking at the diff then they aren't doing their job right, imo
[13:10] <siretart> k
[13:11] <ScottK> I remember the other thing we need to discuss ...
[13:11] <ScottK> Do bugfix only releases need an exception?
[13:11] <ScottK> We experimented with not last time and I think it worked well.
[13:14] <james_w> I think it's reasonable, but I think you need more -release members to discuss it
[13:14] <persia> I like having a bug for those, whether a special ACK is required or not.
[13:15] <ScottK> Which is what we did last time
[13:15] <ScottK> So we can take it to the ML
[13:15] <ScottK> Are we done then?
[13:15] <persia> Right.
[13:15]  * ScottK says the meeting is over.
[13:15] <persia> Did you get enough votes to squelch diffstat, or will that need to be discussed at the later meeting as well?
[13:16] <TheMuso> Ok thanks folks. See you all in 10 days or so.
[13:19] <ScottK> persia: I'm going to believe that I did.
[13:19] <persia> ScottK: OK.  Let's hope it makes the minutes.
[13:19]  * persia thinks diffstats are actually useful.
[15:54] <lool> w00t
[16:02] <lool> slangasek: Are you chairing the meeting today?
[16:07] <mdz> slangasek: hello?
[16:07] <mdz> #startmeeting
[16:07] <mdz> MootBot: :'-(
[16:07] <lool> Yeah, broken
[16:07] <slangasek> mm, sorry
[16:08] <slangasek> morning :/
[16:08] <slangasek> no MootBot today?
[16:08] <mdz> afraid not
[16:08] <lool> http://paste.ubuntu.com/41581/ agenda
[16:08] <mdz> let's charge ahead though
[16:09]  * slangasek nods
[16:09] <mdz> would be good to have hyperlinks in the agenda for the bug lists
[16:09] <lool> (Mootbot is broken for a couple of ubuntu-mobile meetings)
[16:09] <slangasek> are folks here?
[16:09] <mdz> davidm and pgraner are here, just spoke to them
[16:09] <mdz> cjwatson is on a phone interview
[16:09] <mdz> heno_ connected a moment ago
[16:09] <heno_> hi
[16:10] <lool> Scott is on leave I think
[16:10] <mdz> yes
[16:10] <lool> as well as pitti
[16:10] <mdz> missing dendrobates?
[16:10] <davidm> I bugged the scribes about mootbot yesterday
[16:10] <lool> I saw Hobbsee some hours ago I think, but she's offline right now
[16:11] <slangasek> yes, Hobbsee let me know she wouldn't be able to make it
[16:11] <slangasek> and I think that accounts for everyone
[16:11] <lool> ScottK was invited as well
[16:12] <lool> and Riddell
[16:12] <slangasek> Riddell is also on leave, I believe; ScottK: there?
[16:13] <lool> Here he is
[16:13] <mdz> we have a quorum; let's get started
[16:14] <slangasek> agenda, with links: http://paste.ubuntu.com/41584/
[16:15] <mdz> bug 255635 pitti was working on, but he's not back from holiday until Monday I think
[16:15] <slangasek> the list of known blockers is short, but we have two among them that currently don't have assignees
[16:16] <mdz> bug 250506 is is milestoned but not assigned to anyone
[16:16] <slangasek> I can try to look at 255635 today, and pass it back to pitti again if I don't get through it
[16:16] <mdz> there are also 3 critical bugs on https://bugs.edge.launchpad.net/ubuntu/intrepid/+bugs (not on the agenda, but should be)
[16:17] <slangasek> I think 250506 was seb's/pitti's area, both of whom are currently out
[16:17] <lool> Agreed on #250506, and as it's quite security sensitive, pitti is the right person IMO
[16:18] <slangasek> ok; I'll assign 250506 to pitti
[16:18] <lool> We could either revert to GDM doing shutdown/reboot, or allow everybody to shutdown/reboot via dbus as upstream does, or find a creative solution
[16:18] <lool> I suspect the former will happen as it might take a while to sort out
[16:19] <slangasek> cjwatson: the last bug on there is yours, bug #254042 - any concerns there?
[16:20] <cjwatson> no concerns but I haven't made progress yet, as it were
[16:20]  * slangasek nods
[16:21] <slangasek> ok, moving to https://bugs.edge.launchpad.net/ubuntu/intrepid/+bugs as mdz pointed out
[16:21] <slangasek> there are three bugs listed as critical there: bug #197680, bug #253076, and bug #247376
[16:22] <slangasek> bug #197680 appears to have been considered fixed already, and was reopened last week
[16:23] <slangasek> I'll follow up with bryce about that today
[16:23] <lool> bug #253076 looks fixed in .27
[16:23] <lool> "
[16:23] <lool> "Seems to be fixed in .27-1
[16:23] <tseliot> bug # 247376 depends on the fact that (currently) the fglrx driver doesn't work with the new Xorg ABI
[16:24] <tseliot> #247376
[16:24] <lool> I understand that fglrx for intrepid might land post intrepid
[16:25] <slangasek> right, bug #253076 is tentatively resolved, contingent on 2.6.27; we'll come to that later
[16:25] <tseliot> lool: yes, this is likely. superm1 can you comment on this?
[16:26] <slangasek> in any case, that's not something we can set an alpha-5 timetable for
[16:26] <slangasek> unfortunately
[16:26] <lool> Bryce also said on ubunu-devel that AMD had based work on 2.6.26 rather than .27, but as fglrx now builds against linux 2.6.27 in Ubuntu that should be ok
[16:26] <lool> I don't think we can do anything for alpha 5 except sit and wait for a new fglrx; perhaps something to mention in the known bugs?
[16:27] <slangasek> yes, good point; adding an ubuntu-release-notes task
[16:28] <tseliot> we should do it for the 2 nvidia legacy drivers affected by the same problem too
[16:28] <tseliot> (96, 71)
[16:29] <slangasek> there are a significant number of other high-importance bugs on that list without milestones; I don't think we need to go through those individually right now, I'll go through the list myself afterwards to find any that need to be milestoned
[16:29] <slangasek> let's move on to talking with the teams, about any would-be-blockers they have that aren't on that list
[16:30] <slangasek> lool: would you care to start?
[16:30] <mdz> the list of high-importance bugs targeted for intrepid might be a good source of would-be blockers as well
[16:31] <lool> slangasek: Sure
[16:31] <slangasek> er, yes - I meant, any would-be blockers that aren't already milestoned
[16:31] <lool> So concerning mobile, we now have daily images being built daily for the mid seed
[16:31] <lool> The mid seed is the intrepid seed for hardy's mobile seed
[16:32] <lool> The images are around since a couple of days and have many technical issues, but it's good to have something to test and work on now
[16:32] <lool> The major things to land are the installer
[16:32] <lool> Emmet is still working on tweaking Ubiquity and we will include his work before alpha 5
[16:32] <lool> Another major thing is 2.6.27
[16:33] <slangasek> cjwatson: I'm assuming that it's best to leave you 'til last since you're on a phone call now, shout if you become available sooner
[16:33] <lool> We're using the linux-lpia source package, which is still at 2.6.26
[16:33] <mdz> lool: are the test images for the Q1 Ultra?
[16:33] <lool> I'm experiencing issue with our dailies which point at the kernel (apt-get update hangs), so .27 might be worhthwhile
[16:33] <slangasek> are the ubiquity tweaks on-track to be in the archive before Tuesday (milestone freeze)?
[16:34] <lool> mdz: You can boot the image in kvm and the Q1, but it's super ugly; Xorg wont come up without fixing the upstart event for instance
[16:34] <lool> (fixed this morning)
[16:34] <pgraner> lool: is assistnace needed from the kernel team to help get you to .27
[16:34] <lool> slangasek: I would have to check with persia; we basically set a hard deadline on having an installer before alpha 5
[16:35] <lool> slangasek: I'll confirm with him that he knows about the deadline
[16:35] <slangasek> lool: ok; if those aren't going to be done by Tuesday, please keep the release team informed, since that will impact ISO building
[16:35] <lool> pgraner: I've proposed a phone call between Michael Frey and Amit next week
[16:35] <lool> pgraner: I've summarized our dilemma on ubuntu-devel@; basically we asked Intel for .26 drivers and still haven't got any
[16:35] <slangasek> next week> so linux-lpia to .27 is looking like post-alpha-5?
[16:36] <pgraner> lool: we need to revisit that amit is on other things, I'll join the call in his place
[16:36] <lool> In all cases, it's likely we aim at using whatever intrepid uses as a kernel number
[16:36] <lool> pgraner: Ok; we need to discuss security support of linux-lpia for the intrepid cycle too; will include you when I setup the meeting next week
[16:36] <davidm> we may have issues for the poulsbo drivers however, trying to sort that out.
[16:36] <pgraner> lool: ack
[16:37] <pgraner> davidm: eta on that? need anything from us?
[16:37] <lool> slangasek: linux-lpia .27 should be decided after next week's call with Intel was my proposal; this week's call didn't help us in any way sadly
[16:37] <slangasek> ok
[16:37] <davidm> pgraner, I'll catch you off line, to review possible steps
[16:37] <pgraner> davidm: ack
[16:37] <slangasek> lool: are there any particular ubiquity bugs that I should add to my milestoned list?
[16:37] <davidm> pgraner, no eta, working with Intel
[16:38] <lool> Finally, the other major things we need to land for mobile are some new source packages, most in NEW or REVU pending upload to NEW
[16:38] <lool> All mobile specific naturally
[16:39] <lool> In terms of feature, we didn't yet decide of which IM and mail client we would include; I pushed modest and we didn't push the pidgin-maemo fork which are the main candidates, versus thunderbird and empathy ATM
[16:39] <lool> slangasek: No particular ubiquity bugs that I know of
[16:39] <lool> slangasek: My understanding is that Emmet's work is around simplifying the installation procedure, and fitting the UI on the small screen
[16:40]  * slangasek nods
[16:40] <lool> These are the main things for mobile, so quite a lot as you see; we're generally a bit late in the cycle
[16:41] <ogra> mdz, as soon as the ubuntu-mobile image is built, bug #261873 is fixed and ubiquity is there you can test ubuntu-mobile on the Q1 as well
[16:41] <lool> Oh right there's also the evtouch issue on the Q1
[16:41] <lool> and ath5k doesn't work on the Q1
[16:41] <slangasek> fwiw, unless there've been more uploads since yesterday, I believe all your NEW packages have cleared the queue now
[16:41] <ogra> right
[16:41] <lool> even with .27, according to ogra's testing
[16:41] <ogra> i'll attack evtouch mid next week
[16:42] <ogra> and i'm supposed to file the ath5k bug before end of my workday today and connect with rtg for that
[16:42] <lool> slangasek: I see my uploads were cleared; don't know when the other NEW packages were pushed exactly
[16:42] <slangasek> sounds like we've pretty thoroughly covered mobile then, and everyone knows what's on their plate; anything else before moving on?
[16:42] <lool> Oh soryr forgot that we also have to select media player
[16:42] <ogra> note that most/many of your NEW packages are universe
[16:43] <lool> No NEW package invoved though as moblin-media isn't an option so far
[16:43] <ogra> (so migth not actually be on steves radar)
[16:43] <lool> ogra: (good point)
[16:43] <ScottK-laptop> And motu-release has delegated authority for their respective areas to lool and ogra so in Universe they control their own destiny.
[16:43] <lool> slangasek: Ok to move on
[16:44] <slangasek> lool: since you're the emergency contact for the desktop team this week too :), do you have anything on that front?
[16:44] <lool> One thing I'd like to mention is the Gtk+ screen flicker issue
[16:44] <lool> #245383 I think
[16:44] <lool> bug #245383
[16:45] <lool> It's quite annoying as it causes a delay on startup and will cause your screen to go black and  light again
[16:45] <mdz> there are a variety of GNOME crashers (gnome-power-manager and gvfsd-trash come to mind) which seem fairly important but I don't see on the bug lists (they are reported though)
[16:46] <lool> The issue is also relatively deep and the proposed fix is to add xrandr API which will take a long while
[16:46] <lool> I guess we might revert gtk+'s changes on this area, but I'm not sure how easy taht is
[16:46] <lool> mdz: Could you please bump them to >= high?
[16:46] <slangasek> 245383 is milestoned, but doesn't have anyone assigned (beyond "desktop")
[16:47] <slangasek> lool: do you know who would look into the GTK flicker problem?
[16:47] <mdz> lool: bug 252174 is already high
[16:47] <lool> I don't have much time to work on it before alpha 5  :-/
[16:47] <mdz> 46 duplicates!
[16:47]  * ogra has seen it as well already
[16:47] <mdz> probably deserves an apport dupe filter
[16:48] <lool> slangasek: I guess to revert the gtk changes could go on seb128's plate if he doesn't mind, but I didn't check when he comes back
[16:48] <nizarus> @schedule tunis
[16:48] <lool> Probably too late
[16:48] <slangasek> seb128 is back Monday, I believe
[16:48] <mdz> the gnome-power-manager one I am thinking of most closely matches bug 149746 but that's very old
[16:49] <lool> I've had gnome-settings-daemon crash on me a couple of times, but as a heisenbug already reported with some dups
[16:50] <slangasek> ... which is pretty standard, so assigning it to seb128 wouldn't be worse than assigning it to anyone else; should I do so, or do you want to talk with seb first?
[16:50] <ogra> tedg is the g-p-m maintainer
[16:50] <lool> Please assign to seb and mention that I can help on the issue
[16:52] <slangasek> assigned
[16:52]  * k0p is away: I'm busy right now
[16:52] <slangasek> bug #252174 escalated; with 46 dupes, we should try to get that out of the way for alpha-5
[16:53] <slangasek> ... if I can pick the right milestone from the pull-down, that is
[16:53] <slangasek> mdz: should a new bug report be filed about the g-p-m crash, or do you think 149746 is the same bug?
[16:54] <mdz> slangasek: I have a crash file for what I saw; it looked sufficiently similar that I didn't file a new one, but since it's happening to me constantly, I don't think it's the same
[16:55] <mdz> I will file a new bug with the crash report when I'm at home where the crash file is, and drop you a note with the bug number
[16:55] <slangasek> mdz: ok, thanks
[16:55] <mdz> (though I'm curious if I'm the only one with a spastic g-p-m)
[16:55] <slangasek> any other high-profile desktop bugs?
[16:56] <lool> dunno whether I should be reporting on specs progress again; I mentionned that the fast-user-switch-applet IM and session integrations landed, but IM doesn't work properly for me
[16:57] <slangasek> was just about to ask about specs :)
[16:57] <ogra> mdz, i didnt have issues yet ... so might be HW or settings specific
[16:57] <slangasek> lool: are you still working with tedg on those IM issues, then?
[16:57] <lool> I was asked to work on better-login-speed intrepid-menus-review as time permits
[16:57] <slangasek> neither of those are alpha-5 material, I guess
[16:58] <lool> slangasek: I think he reproduces; he received all my complaints and knew about the most important ones already
[16:58] <lool> slangasek: I understand that he will address them ASAP, but we didn't discuss any alpha 5 deadline for them
[16:59] <slangasek> you and I talked about intrepid-device-permissions, I think that was already mostly done before pitti went on vacation and I fixed the last PAM bit this week
[16:59] <lool> I find the red button icon ugly when you startup a fresh intrepid image for instance, because there's no IM running at all
[16:59]  * slangasek nods
[17:00] <lool> One personal desktop thing I'd like to land before alpha 5 is an elisa update
[17:00] <lool> 0.5.x series
[17:01] <lool> I have to finish reviewing the packaging and push them, I hope today or this WE, just after I get an ack on a FFE
[17:01] <slangasek> yes, you mentioned that to me earlier; is a FFe bug filed?
[17:01] <lool> Not yet
[17:01] <lool> Will do just after the meeting
[17:01] <slangasek> ok
[17:01] <slangasek> anything else, or should we move on?
[17:01] <lool> Finally, now that I have a webcam I can pick the cheese update
[17:02] <lool> We still are on 2.22 cheese and miss many new features developped during gsoc
[17:02] <mdz> slangasek: let's move on, this is starting to drag
[17:02] <lool> I was the casual cheese sponsor, tremolux was doing the packaging updates; sadly he has been busy or on holiday
[17:02] <slangasek> dendrobates: hi
[17:03] <dendrobates> slangasek: hi
[17:03] <slangasek> dendrobates: what news in the land of servers?
[17:03] <ScottK-laptop> slangasek: I can generally speak to Kubuntu status if you want it.
[17:03] <dendrobates> we would really like to get bug 261847 taken care of.
[17:04] <slangasek> ScottK-laptop: let's pick that up after server team
[17:04] <slangasek> dendrobates: I believe I saw some uploads in connection with that?
[17:04] <slangasek> or were those uploads to make other packages use -headless?
[17:05] <mdz> doko doesn't seem to be online
[17:05] <slangasek> doko is also on holiday this week, until Monday
[17:05] <dendrobates> slangasek: part of the problem was fixed, but at least, as of yesterday, this still existed.
[17:05] <slangasek> dendrobates: has someone spoken with doko about this directly yet?
[17:06] <dendrobates> we also have a serious regression in likewise-open, bug 262264
[17:06] <dendrobates> slangasek: yes, but we haven't reached an agreement yet.
[17:06] <slangasek> right, that'll be tied to the new pam framework landing
[17:06] <dendrobates> slangasek: yes, Jerry is working on it now.
[17:06] <slangasek> dendrobates: ok, so it's more than just a question of whether doko will have time to work on it Monday, even
[17:07] <dendrobates> slangasek: we can do it, it is really, wheter he will agree to it or not.
[17:07] <slangasek> 261847 is milestoned to alpha-6, which looks like the right target under the circumstances
[17:07] <mdz> slangasek: doko is not back until Tuesday
[17:07] <slangasek> oh, indeed
[17:07] <mdz> perhaps someone else should have a look
[17:08] <lool> (What's the rationale for having the mdns recommends?)
[17:08] <dendrobates> cjwatson is aware of this as well.
[17:09] <slangasek> mdz: well, it appears to be a design decision rather than a straightforward bugfix; do we have anyone other than doko who would make such decisions for openjdk?
[17:10] <slangasek> dendrobates: it'd be really great if we could get likewise using the new pam framework; feel free to point Jerry my way on that
[17:10] <mdz> slangasek: punt to cjwatson
[17:10] <slangasek> mdz: ok
[17:10] <dendrobates> slangasek: already did.  :)
[17:11] <dendrobates> we also have landscape-client that is almost done with it's security review.
[17:11] <slangasek> dendrobates: any other bugs to be escalated, or "unsettling" changes between now and the milestone?
[17:11] <dendrobates> slangasek: no.
[17:12] <slangasek> ok.  you and I can discuss landscape-client status offline/as-needed; let's move on so we can stay within time
[17:12] <slangasek> pgraner: kernel?
[17:12] <pgraner> slangasek: sure
[17:12] <slangasek> oh, sorry
[17:12] <slangasek> backing up
[17:12] <slangasek> ScottK-laptop: kubuntu?
[17:13] <ScottK-laptop> The big thing for Kubuntu is KDE 4.1.1 was released this week.
[17:13] <ScottK-laptop> It's being packaged now and we plan to push it on Monday.
[17:13] <ScottK-laptop> So that should be a bit interesting.
[17:14] <ScottK-laptop> The only major bug issue I'm aware of is Knetworkmanager not working with networkmanager right now.  I think Riddell was looking at it.
[17:14] <slangasek> well, looks like kubuntu ISOs currently have plenty of space to grow, so at least that's not a concern :)
[17:14] <ScottK-laptop> We updated the remaining KDE bits in Intrepid to 3.5.10 this week.
[17:15] <ScottK-laptop> Published the full suite to hardy-backports with only a few minor regressions reported and none that relate to packages that are still KDE3 in Intrepid
[17:15] <ScottK-laptop> I think that's it.
[17:16] <ScottK-laptop> On a personal note 3.5.10 was the first time I've packaged an entire KDE release all by myself.  That was interesting.
[17:16] <slangasek> ScottK-laptop: thanks for the update
[17:17] <slangasek> pgraner: kernel :)
[17:17] <ScottK-laptop> You're welcome.
[17:17] <cjwatson> ok, sorry I couldn't make it until now
[17:17] <pgraner> slangasek: sure (one more time :-) )
[17:17] <pgraner> 2.6.27 Call for Testing (CFT) went out yesterday. So far we've been tracking upstream regressions [LINK http://bugzilla.kernel.org/showdependencytree.cgi?id=11167&hide_resolved=1]
[17:17] <pgraner> In addition to Regressions reported by our users [LINK https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-2.6.27] they are tagged with regression-2.6.27 for easy searching
[17:18] <pgraner> Bugs in 2.6.26 and prior that are fixed by 2.6.27 are tagged with fixed-2.6.27 [LINK https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=fixed-2.6.27]
[17:18] <pgraner> New 2.6.27 bugs are tagged with linux-2.6.27 [LINK https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=linux-2.6.27]
[17:18] <pgraner> The fallback plan in the event of everything going south is documented here: [LINK https://wiki.ubuntu.com/KernelTeam/2.6.27-kernel-plan]
[17:19] <pgraner> So far the worst regression from 2.6.26 is https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/253076
[17:19] <pgraner> Suspend/Resume failures
[17:20] <slangasek> are the incompatibilities with third-party drivers also being tracked as "regressions"?
[17:20] <mdz> pgraner: and bug 262539 of course ;-)
[17:20] <pgraner> slangasek: other than the nvidia/fglrx no
[17:20] <slangasek> ok; but those two are?
[17:21] <pgraner> slangasek: we are tracking them but they were broke in some form or fashion in 2.6.26 so we are not calling them "regressions" to 2.6.27, we are tracking tho.
[17:21] <slangasek> 253076> seems to be a bug that was a regression in /2.6.26/, and is fixed in 2.6.27
[17:22] <slangasek> (as mentioned earlier)
[17:22] <pgraner> slangasek: it would appear so on 253076
[17:23] <mdz> and it's tagged fixed-2.6.27, not regression-2.6.27
[17:24]  * pgraner nods
[17:24] <mdz> I'll test a couple of laptops with 2.6.27 over the weekend and see what happens
[17:24] <heno_> the fallback plan looks workable to me from a QA perspective
[17:24] <slangasek> I notice that on <https://wiki.ubuntu.com/KernelTeam/2.6.27-kernel-plan>, fglrx/nvidia are not listed as decision criteria
[17:24] <mdz> heno_: what about the 2.6.27 certification test?
[17:24] <slangasek> nor is there mention of certification test
[17:24]  * ogra can report 253076 fixed on his laptop
[17:24] <heno_> I have a call with pgraner after this meeting to coordinate beefing up hardware testing in our labs with .27 and have discussed it with Marc also
[17:25] <pgraner> slangasek: certification is working after this meeting, will be updated once a plan is decided
[17:25] <ogra> (with .27)
[17:25] <heno_> we are planning specific push on that
[17:25] <slangasek> mdz: I guess the 'linux-2.6.27' tag made it show up on the list of "new 2.6.27 bugs"
[17:26] <pgraner> slangasek: Given we don't have much control over nvidia/fglrx I'm not sure we want to use that as decision criteria
[17:26] <heno_> We need to run more comprehensive tests on all the machines (autotest, LSB etc) and see what falls out
[17:27] <slangasek> well, I think we need to have our eyes open to the consequences of not treating nvidia/fglrx as a blocker
[17:27] <heno_> and also make sure the kernel team has easy access to machines for debugging and testing
[17:27] <pgraner> heno_: ack on that
[17:27] <ogra> slangasek, and communicate that well in advance and very loud this time ...
[17:28] <slangasek> that's not something I look forward to being in the middle of trying to communicate
[17:28] <lool> release notes task again?
[17:29] <ogra> well, we shoudl do better than we did for the 8.04.1 hardy issues i mean
[17:29] <ogra> which imho was not loud enough as the footnote we had put in
[17:30] <slangasek> ... I'm not looking forward to the binary driver support turning into an 8.10.1, either
[17:30] <ogra> indeed ...
[17:31] <mdz> next?
[17:31] <cjwatson> I guess that can be me
[17:32] <cjwatson> feature freeze exceptions raised by my team were:
[17:32] <slangasek> cjwatson: go ahead
[17:32] <cjwatson>  * new pulseaudio to match new alsa and new kernel
[17:32] <cjwatson>  * experimental python 3 packages (not by default, maybe not really FFe)
[17:32] <cjwatson>  * system-cleaner (tonight, I'm told)
[17:32] <cjwatson>  * usb-installer-images (ditto)
[17:33] <cjwatson>  * dvd-performance-hacks (ditto)
[17:33] <cjwatson>  * timezone map changes for ubiquity
[17:33] <cjwatson>  * openoffice.org 3 (again, not by default, parallel-installable)
[17:33] <cjwatson>  * xorg-options-editor needs promotion to main I think
[17:34] <cjwatson> and I think that's about it
[17:34] <mdz> freeze exceptions should probably be a standing agenda item from here on out
[17:34] <lool> pulseaudio> I understand git's version carries plenty of fixes; wouldn't it make sense to simply push that before alpha 5 to get more testing and revert to the current version if it's too borken?
[17:34] <cjwatson> as others have said, the fglrx issue is a major one. I'm told that the devprivates rework in the X server has left fglrx with a bit of catching up to do
[17:34] <mdz> has fglrx been screwed twice, by X and kernel?
[17:34] <cjwatson> mdz: yes
[17:35] <mdz> fantastic
[17:35] <cjwatson> lool: only thing is that Luke's on holiday next week
[17:35] <cjwatson> I was told that 2.6.27 would "add to the risk", and I think that was posted on the -devel thread
[17:35] <mdz> next year, let's everyone go on holiday at the same time, it would be much more convenient
[17:36] <lool> That's actually what happens in August in France *cough*
[17:36] <cjwatson> several people mentioned 261847. doko is caught between a rock and a hard place here; he had (semi-legit) release-critical bugs filed in Debian when it was the other way round, because Java's network resolver was unable to resolve names without libnss-mdns
[17:36] <mdz> cjwatson: unable to resolve names *at all*?
[17:36] <cjwatson> e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477211
[17:36] <cjwatson> yes. I have no idea why
[17:37] <cjwatson> I think that is a bug but simply dropping the recommendation to a suggests does not seem like the obviously right fix
[17:37] <cjwatson> so I am very reluctant to overrule doko in his absence, and would rather wait 'til he gets back
[17:37] <lool> Isn't it because using system's nsswitch.conf in a 32-bits jvm which couldn't find libmdns?
[17:38] <mdz> that bug looks like it's probably specific to biarch, no?
[17:39] <cjwatson> in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430917 Aurelien said "The 64-bit version should also depends on libnss-mdns. If it is not installed you get the exact same error."
[17:40] <cjwatson> I haven't ripped my system apart to test, but Aurelien isn't someone I'd automatically mistrust
[17:40] <lool> He might mean the 64 bits version in a 32-bits system?
[17:40] <cjwatson> he might, but that wasn't the implication I drew
[17:40] <mdz> we can't debug it here, but it seems like this would benefit from a closer look
[17:40] <mdz> perhaps even before matthias gets back
[17:41] <slangasek> let's pick that up on #ubuntu-devel after, then
[17:42] <cjwatson> it's a one-day delay, and as slangasek said alpha-6 does not seem an unreasonable target for this. I agree that it's intrepid-critical to resolve but don't see that it's alpha-5-critical
[17:42] <slangasek> cjwatson: so for xorg-options-editor, is "x-kit" the package in need of promotion?
[17:42] <cjwatson> that and screen-resolution-extra I think
[17:43] <slangasek> neither appears to have MIRs going yet?
[17:43] <cjwatson> I asked bryce to file those but looks like he hasn't yet
[17:43] <cjwatson> I'll remind him
[17:43] <slangasek> ok
[17:44] <slangasek> heno_: QA?
[17:44] <heno_> Our smoke testing found some problems with OEM mode. It seems to work on Ubuntu now, but there is still an open bug on Kubuntu (#251634). See: https://wiki.ubuntu.com/Testing/DailySmoke
[17:45]  * slangasek targets
[17:45] <heno_> Other than that, we have concerns about the kernel SRUs we will get after Intrepid is out
[17:45] <slangasek> in general / as a perceived consequence of 2.6.27?
[17:46] <heno_> as noted, I'll have some talks with pgraner about the .27 process
[17:46]  * slangasek nods
[17:46] <heno_> slangasek: the latter, we are scheduling an SRU before release here
[17:47] <heno_> though we often have kernel SRUs post release anyway, but I was hoping to reduce that
[17:47] <ogra> wasnt that reduced by the new policy ?
[17:47] <heno_> anyway, we'll monitor it over the next few weeks
[17:48] <slangasek> ok
[17:48] <slangasek> anything else you've noted that should be alpha-5 critical?
[17:48] <heno_> not that I'm aware of
[17:48] <mdz> we need to see hardware test results very soon
[17:49] <heno_> agreed. It's on my urgent list
[17:49] <mdz> thanks
[17:49] <slangasek> ScottK-laptop: anything for motu-release?
[17:50] <ScottK-laptop> We had a good organizational meeting this morning.
[17:50] <ScottK-laptop> 4 of 5 are returning from Hardy, so the team's in good shape.
[17:50] <cjwatson> on 251634, I could do with help from a KDE developer
[17:50] <slangasek> interleaving a bit, since we're over time: ISO size has been stable and very good, the last round of reductions made a big difference
[17:50] <ScottK-laptop> The hot ticket at the moment is that it seems there are some developers who might have rushed to upload stuff before FF.
[17:50] <cjwatson> I'm not sure how much of the stderr spew there is actually fatal
[17:51] <cjwatson> rushed> just like every other Ubuntu freeze :)
[17:51] <ScottK-laptop> Rushed yes, but rushed some things that appear to have been particularly unfortunate.
[17:51] <ScottK-laptop> So we're looking into it.
[17:52] <Riddell> cjwatson: the oem stuff is on my todo to look at, I can try and look next week
[17:52] <cjwatson> ta
[17:53] <slangasek> ScottK-laptop: FFe process under control for you guys at the moment?
[17:53] <ScottK-laptop> yes.
[17:53] <ScottK-laptop> We're repeating mostly what we did for hardy and doing a lot of delegation to experts.
[17:53]  * slangasek nods
[17:54] <ScottK-laptop> We're also repeating the idea of continuing to allow new upstreams that are only bugfix.
[17:54] <ScottK-laptop> No other news.
[17:54] <slangasek> sounds good
[17:54] <slangasek> ok, items left on the agenda
[17:54] <slangasek>  * Hardware testing
[17:54] <slangasek> that's been discussed above
[17:55] <slangasek>  * Future issues expected to impact the release (e.g. major upstream changes pending)
[17:55] <slangasek> I /hope/ those have all been covered by this point, if not please contact me ASAP after the meeting to discuss :)
[17:55] <slangasek>   * status of issues found in previous milestone
[17:55] <slangasek> I'll go through those myself after the meeting, to not hold people up, and escalate any that still need attention
[17:56] <slangasek> anything else, or shall we adjourn?
[17:57] <slangasek> #endmeeting
[17:57] <slangasek> thanks, folks!
[17:57] <mdz> slangasek: do you maintain a list of those (future upstream issues) somewhere?
[17:57] <lool> Bye
[18:00] <slangasek> mdz: not currently; I don't think there's been any carry-over from previous milestones, but I'll review the previous logs to confirm, and can make a point to add any that do carry over to the agendas
[21:33] <keffie_jayx> j #openbravo
[21:33] <keffie_jayx> upssss