[05:30] <ScottK> Riddell: ^^^^ stgraber's question.
[05:30] <ScottK> I don't know.
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== henrix_ is now known as henrix
=== henrix_ is now known as henrix
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
=== mmrazik is now known as mmrazik|lunch
=== henrix_ is now known as henrix
=== mmrazik|lunch is now known as mmrazik
[12:11] <cjwatson> I could use somebody else paying some attention to the upload queue.  I think a majority of the stuff there is mine now.
[12:28] <Laney> looking
[12:31] <Laney> rejecting django-dajax, asking for FFe
=== doko_ is now known as doko
=== henrix_ is now known as henrix
[12:54] <cjwatson> Laney: excellent, thanks
[12:55] <Laney> left the ones that give me Fear
[12:55] <smartboyhw> The fear of the LORD is the beginning from wisdom (Proverbs 6:9)----fits Laney:P
=== henrix is now known as henrix_
[13:23] <stgraber> ScottK, Riddell, cjwatson: I got a reply from dpm telling me that the Kubuntu folks have no real control on what's getting in those langpacks and what's generating them. David poked pitti about it, so hopefully the few I've discovered to be broken will soon be fixed.
[13:26] <Riddell> stgraber: hmm, I think it might be my fault but it hasn't reached the top of my todo list yet
=== henrix_ is now known as henrix
[13:43] <knome> hey skaet!
[13:44] <knome> skaet, we were wondering what does "What was done engineering wise?" really refer to?
[13:44]  * smartboyhw too
[13:44] <knome> skaet, new packages? new releases? changed default settings? any uploads done?
[13:45] <stgraber> knome: any change affecting your product that you think is relevant
[13:45] <knome> relevant to who/what?
[13:45] <stgraber> knome: can be new version of a package, artwork change, settings change, ...
[13:45] <knome> if we change our appearance, i know that's relevant to the docs team, but is that something to report to the release team?
[13:46] <knome> or is the main idea of this section to gather the release notes?
[13:46] <knome> if that is it, can we rethink wording, because i think that's the sloppiest question ever :)
[13:46]  * smartboyhw thinks this is not the same thing as release notes
[13:46] <knome> i think skaet used to use something (this?) for creating release notes at some point
[13:46] <stgraber> that section is meant to keep all the other teams up to date on what you've been doing. We don't use that for the techoverview/release notes as otherwise they'd be horribly long :)
[13:46] <knome> and no, of course it's not === release notes
[13:47] <stgraber> IIRC this cycle Kate is parsing the blueprint to extract the tech overview entries
[13:47] <knome> stgraber, isn't that kind of duplicate of the "summary of bugs worked on by team"?
[13:47] <smartboyhw> Hmm..blueprints:P
[13:47] <knome> stgraber, saying kind of, because not everything is actually a bug...
[13:48] <stgraber> knome: yeah, if all you've been doing is bugfixing, it'd be quite redundant, then just put a single like "Been working on bugs, see below" :)
[13:48] <knome> stgraber, right.
[13:49] <knome> stgraber, i don't think creating a new wallpaper is "engineering"
[13:49] <knome> stgraber, so the title is still kind of... lousy
[13:49]  * smartboyhw thinks "List what have you added/deleted" is better:P
[13:50] <knome> well, no, not that either
[13:50] <knome> "Changes to images done by team" or sth
[13:51] <cjwatson> *shrug*
[13:51] <cjwatson> s/engineering/development/ only with better wording
[13:51] <tumbleweed> cjwatson: when you have a minute: https://code.launchpad.net/~stefanor/ubuntu-archive-tools/edit-packagesets/+merge/124639
[13:51] <tumbleweed> (it's landed in LP production)
[13:51] <knome> cjwatson, yep, but it's still a bad title.. ;) good to have sorted out what you are after with it though
[13:52] <stgraber> tumbleweed: yay!
[13:53] <cjwatson> tumbleweed: merged, thanks
[13:53] <cjwatson> knome: it's not necessarily meant to be constrained to just changes to images, so yours is wrong too :)
[13:54] <cjwatson> for example foundations often lists significant infrastructure work there
[13:54] <smartboyhw> cjwatson, a question from me
[13:54] <smartboyhw> === What's about to land that might impact the other teams and release as a whole? ===
[13:54] <smartboyhw> Er what does this mean?
[13:54] <stgraber> "What did your team do this past week" might be generic enough ;)
[13:55] <smartboyhw> stgraber, +1
[13:55] <cjwatson> smartboyhw: Replace "impact" with "affect" and it might be more understandable
[13:55] <cjwatson> ("impact" for "affect" is ghastly managementese)
[13:55] <knome> cjwatson, yeah, that's true. stgraber, yes, that might be good, but then it could have the bugs listed under it too.
[13:55]  * smartboyhw still doesn't understand sorry
[13:56] <cjwatson> smartboyhw: It's unlikely it will be relevant to you
[13:56] <cjwatson> Since changes to Ubuntu Studio are not likely to affect any other team
[13:56] <smartboyhw> cjwatson, OK thanks
[13:56] <knome> smartboyhw, if xubuntu uploads a new version of xfce, it's probably going to mean ubuntu studio needs to think about that too
[13:56] <smartboyhw> knome OK.
[13:56] <knome> smartboyhw, or, to say with the words in the mail, it might affect US too
[13:57] <skaet> knome,  stgraber, smartboyhw - problem with my plan is that folks don't update their blueprints :P   so that the automated extraction will work.
[13:57] <knome> skaet, hey! don't point at us :)
[13:57]  * smartboyhw is a new guy on this so don't point at him:P
[13:57] <skaet> knome,  no fingers,  its a pervasive problem from the walking through of them I did after beta 11
[13:57] <smartboyhw> I mean on the release mail thing:P
[13:57] <knome> skaet, we were just thinking that the "bugs worked on by the team" looks really similar to "open work items" :)
[13:57] <skaet> beta 1 rather.
[13:58] <knome> skaet, well, i'd say our blueprints are in a rather good shape :) or not in good - but current
[13:58] <skaet> and yes,  I use the data from the weeklies to generate the first pass of the release notes,  and then rely on the team leads to find things that aren't explained overlooked.  :)
[13:58] <smartboyhw> skaet, knome: Ours isn't in good shape (mainly all scott-work's items:P)
[13:59] <skaet> yup knome,  Xubuntu rocks at keeping their status up to date.  :)
[14:00] <skaet> smartboyhw,  if its clear that scott-work won't be able to get to things now for this cycle,  feel free to go in and mark them postponed.
[14:00] <smartboyhw> OK
[14:00] <skaet> that will get the status tracked more accurately,  and make it explicit rather than everyone guessing.  :)
[14:00] <smartboyhw> :P
[14:01] <knome> skaet, heh, thanks. i think we really benefit from being up-to-date too
[14:01]  * skaet makes a note to change the template for the weekly meeting to say "affect" rather than "impact"  ;)
[14:01] <smartboyhw> lol
[14:02] <xnox> skaet: effect & affect are confusing =) next week you might get *drumroll* in that section ;-)
=== mmrazik is now known as mmrazik|otp
[14:03] <cjwatson> effect => noun, affect => verb - except in rare cases where they're not :-)
[14:05] <cjwatson> (you might effect a change, or say that somebody with a particular psychological problem has a lack of affect - but those are rare uses)
[14:12] <stgraber> z3c.formui <- new upstream release, only listed change was marked by upstream as a feature, didn't have a FFe
[14:13] <xnox> cjwatson: memorized the regular way long time ago, never knew there was a flip side to these terms. Thanks.
[14:21]  * skaet makes  a note to defer to cjwatson on all future grammar issues... ;-)
[14:21] <smartboyhw> more lol:P
[14:23]  * smartboyhw wonders can someone help to refresh the status.ubuntu.com page for Ubuntu Studio for a bit......
[14:29] <smartboyhw> skaet, can I PM?
[14:31] <Laney> anyone want to look at the microcode FFes?
=== mmrazik|otp is now known as mmrazik
[14:35] <smartboyhw> better version: skaet can I PM (private message) you?
[14:39] <stgraber> ok, I think that's enough queue reviews for me, let's try to actually fix some stuff now
[15:09] <skaet> smartboyhw,  yes.   just juggling some things right now, so please be patient if my response time isn't as immediate as I'd like.
[15:09] <smartboyhw> OK
=== rickspencer3 is now known as rickspencer3-otp
[15:51] <cjwatson> ^- first batch of mass rebuild to attempt to get armel/main into sync with the default compiler flags
[15:53] <stgraber> cjwatson: I'll take a look before going for lunch, those should be quick to review anyway ;)
[15:54] <cjwatson> If I don't manage to finish the rebuild before final freeze, not the end of the world
[15:56] <skaet> ack
[15:57] <smartboyhw> ?
[16:03] <stgraber> cjwatson: accepted them all
[16:04] <stgraber> or rather, tried to :) let's use the command line instead...
[16:04] <cjwatson> Yeah, the web UI may have trouble accepting lots in a single request
[16:04] <cjwatson> It still has to check permissions even if bugs are closed asynchronously now
[16:06] <Laney> debfx: I'm going to reject that qt4-x11 until we see if the give-backs work
[16:07] <Laney> I've a solution that doesn't require disabling QtWebkit on arm.
[16:07] <cjwatson> Laney: abiword/armhf still killed its builder today
[16:07] <Laney> yeah, saw
[16:07] <cjwatson> So I think it may need more work
[16:08] <Laney> feel free to just copy it out of canonical-arm-dev/ppa if you don't think it'll work
[16:14] <stgraber> alright, I uploaded a new ubiquity-slideshow-ubuntu. It'd be good to get that one in the archive ASAP to give as much time as possible to the translators to update for the new copy.
[16:15] <stgraber> the diff will likely be a bit scary, but ignoring po/ in the review should bring it down to something much more reasonable (basically bug 1056456 and bug 1054346)
[16:15] <ubot2> Launchpad bug 1056456 in ubiquity-slideshow-ubuntu "[UIFe] New copy for Ubuntu installer slideshow" [Undecided,Triaged] https://launchpad.net/bugs/1056456
[16:15] <ubot2> Launchpad bug 1054346 in ubiquity-slideshow-ubuntu "welcome.jpg shows a pangolin" [High,Triaged] https://launchpad.net/bugs/1054346
[16:32] <debfx> Laney: what has changed that you think it'll build this time?
[16:33] <Laney> either a launchpad fix to the timeouts (which we suspect doesn't work ATM) or building with -gstabs instead of -g
[16:34] <Laney> stgraber: I don't see any change to the xubuntu slideshow in that diff, and the change in Slideshow.py doesn't appear documented
[16:34] <cjwatson> yeah, I think that either the production-configs fix hasn't been deployed yet or the LP change to use it doesn't work
[16:35] <cjwatson> will find out more when wgrant gets up, I guess
[16:35] <cjwatson> looks like unity perhaps ought to have gone to quantal-proposed?
[16:35] <cjwatson> it's dep-wait in quantal, and unity is uninstallable in quantal-proposed which suggests that copying compiz might be a bad idea ...
[16:36] <debfx> or disable debugging symbols completely since we throw away the binary anyway
[16:38] <cjwatson> seb128: ^- didrocks has left but perhaps you can help?
[16:42] <stgraber> Laney: hmm, I thought it was the xubuntu one I had to fix but it was the lubuntu slideshow actually
[16:42] <stgraber> Laney: ubiquity-slideshow-ubuntu-64/slideshows/lubuntu/slides/03_office.html was missing a closing </p>
[16:43] <stgraber> Laney: for Slideshow.py, I have no idea what the change does other than that the script still works fine and isn't actually shipped in the binary packages so I usually ignore it
[16:44] <stgraber> Laney: commit message says "Slideshow.py: Fixed _find_available_locale looking in wrong place for extra slides (LP: #1046511)."
[16:45] <stgraber> though that was on 5th of September, so should have made it in the previous upload... not sure what happened there
[16:47] <stgraber> Laney: looking at the bug, that change was already manually copied over to ubiquity (where that file is actually shipped)
[16:47] <xnox> didn't I merge that ?! =/
[16:47] <xnox> maybe I didn't use the right branches?!
[16:48] <Laney> stgraber: huh, OK, thanks
[16:49] <Laney> I see the fix in lubuntu
[16:49] <stgraber> xnox: the ubiquity side is good, it's just the ubiquity-slideshow-ubuntu that seems to have some out of order commits, not sure how that happened ;)
[16:50] <stgraber> timestamp: Tue 2012-09-25 10:06:19 -0400
[16:50] <stgraber> timestamp: Wed 2012-09-05 13:16:23 -0700
[16:50] <stgraber> timestamp: Thu 2012-09-20 13:29:23 -0400
[16:50] <xnox> stgraber: let's do the timewarp again!
[16:50] <stgraber> see how it went back in time ;)
[16:50] <xnox> anywho another release tracking bug bites to dust =)
[16:53]  * skaet likes release tracking bug squashing going on.... thanks xnox.  :)
[16:54]  * xnox did nothing... it's all stgraber's fault... eh... praise that is
[16:54] <stgraber> :)
[16:54] <skaet> :)  thanks stgraber then.  ;)
[16:54] <stgraber> I'm down to just one bug assigned to me on rls-q, will have to pick some more to keep me busy this week :)
[16:56] <xnox> what is the correct way to "postpone" rls-q-tracking bug? (a) in such a way that if it's fixed in r-series, it should be SRU'ed (b) in a such a way that if it's fixed later, SRU is not expected.
[16:56] <skaet> I don't think we'll run out this week though,  and you'll get bored somehow  ;)
[16:56] <skaet> xnox,  add an r-series task to it
[16:56] <Laney> milestone quantal-updates
[16:56] <Laney> or rls-q-notfixing
[16:57] <Laney> wontfix?
[16:57]  * Laney can't remember
[16:57] <skaet> target it to quantal-updates in the milestone
[16:57] <skaet> if the bug is intended to be fixed,  rls-q-notfixing, isn't really appropriate
[16:57] <Laney> cjwatson: I/someone can just no-change upload unity to -proposed if you want
[16:58] <Laney> why?
[16:58] <Laney> what's rls-q-notfixing for then?
[16:58] <skaet> if the team is not going to fix it.    Sounds like its going to be fixed,  just not in time.
[16:58] <skaet> use milestones,   to indicate timescale
[16:59] <Laney> hmm
[16:59] <xnox> I see.
[16:59] <xnox> and for (b) case, where team will fix later, but not backport to quantal?
[17:00] <skaet> then mark the quantal task as WON"T FIX,  but have the R-series task open
[17:00] <xnox> ok.
[17:00] <skaet> rls-q-notfixing is appropriate as well
[17:00] <skaet> but redundant in this case
[17:00] <xnox> but add rls-r-incoming?
[17:01] <skaet> if its targetted to the series,  than rls-r-incoming adds no additional information.
[17:01] <skaet> so not needed
[17:01] <skaet> s/series/ r-series/
[17:02] <xnox> ok.
[17:07] <seb128> cjwatson, sorry I was out, yes, compiz had an abi change so unity needs rebuild with it, I can reupload to quantal-proposed if you want
[17:22] <cjwatson> seb128: Please
=== rickspencer3-otp is now known as rickspencer3
[17:48] <seb128> thanks to whoever accepted unity ;-)
[17:48] <cjwatson> np
[18:11] <iulian> Laney: Re: microcode, I've had those on my radar. Apparently, the reporter doesn't want to supply any information at all. There are loads of new features and thus I wouldn't approve them unless I see some testing done. I suggest we nack them for quantal, even though no other package is affected by them. If somebody is willing to test the packages, then we could easily backport them.
[18:12] <iulian> I'd prefer to have the packages in a working state.
=== yofel_ is now known as yofel
[18:47] <Laney> iulian: do what you think is best; I don't really know anything about it
[19:23] <skaet> iulian +1
=== henrix is now known as henrix_
[19:57] <stgraber> jdstrand: nice apparmor profile cleanup you did there with the new abstraction :)
[19:57] <jdstrand> thanks!
[19:58] <stgraber> skaet: I'm a bit concerned by unity-firefox-extension in the queue, it's quite clearly doing string changes without a matching UIFe
[19:58] <stgraber> skaet: accepting it would very likely mean extra work for translators
[19:58] <jdstrand> it was getting ridiculous-- there was gonna by 3 with identical and one with almost identical contents without it :)
[19:58] <stgraber> I agree that those are grammar mistakes but we're now in the weird position where fixing them will break translations and require extra work
[19:59] <stgraber> jdstrand: hehe, yeah, copy/paste is bad when you have support for includes :)
[19:59] <Laney> reject, ask them to ask the translators what they think
[19:59] <stgraber> Laney: done
[19:59] <stgraber> kenvandine: ^
[20:00] <infinity> stgraber: If they're just grammar fixed, one could manually unfuzzy the strings?  (since the translations are likely to already be correct).
[20:00] <infinity> s/fixed/fixes/
[20:00] <infinity> At least, I'd hope the translations didn't literally translate poor grammar. :P
[20:00] <kenvandine> ok
[20:00] <stgraber> infinity: yeah, but someone needs to commit to going through LP and update them all as the translations aren't bundled in the source
[20:00] <infinity> stgraber: True dat.
[20:00] <kenvandine> that fix was requested by the translation team
[20:00] <kenvandine> i'll revert it and upload again
[20:01] <stgraber> infinity: and IIRC you need some special rights to be able to do that without going through all the individual translation teams
[20:01] <stgraber> kenvandine: was that dpm? I think dpm has the required rights do unfuzzy all the strings, so if he's on it, then I'll accept it
[20:01] <kenvandine> it wasn't
[20:01] <kenvandine> i'll revert it
[20:02] <stgraber> ok
[20:02] <stgraber> I'll leave a comment in the bug
[20:02] <kenvandine> thx
[20:02] <cjwatson> Sigh, I really must fix the bug where any private recipe build causes /builders to become private
[20:02] <skaet> stgraber,   reject it
[20:02] <cjwatson> SO ANNOYING
[20:03] <stgraber> cjwatson: +1
[20:03] <kenvandine> stgraber, ugh... one of these is a terrible spelling error
[20:03] <kenvandine> promt
[20:03] <skaet> stgraber,  it will be in the hold queue and we can revisit.   but there should be a UIFE for it at a minimum, and the translators should be knowing about it.   :(
[20:04] <stgraber> kenvandine: yeah, I agree that those were pretty bad mistakes, so I'd strongly recommmend coordinating with dpm to see if it can be landed and fixed without requiring work from the individual translators (assuming they didn't "translate" the mistakes ;))
[20:04] <kenvandine> yeah
[20:04] <kenvandine> to get the other bug fixed i'll revert with a patch for now and ask them to do that
[20:06] <stgraber> kenvandine: ok, sounds good
[20:08] <kenvandine> stgraber, uploaded, thx
[20:09] <skaet> cjwatson, slangasek - t-series (14.04) and u-series(14.10) have been created in launchpad now.
[20:11]  * cjwatson does not expect to use them for a year or so :)
[20:12] <stgraber> oh, looks like a few more easy reviews :)
[20:12] <iulian> Thanks to cjwatson. :)
[20:13] <cjwatson> I'm just sorry we didn't get round to this rebuild before freeze
[20:14] <stgraber> can someone review madwimax? it's the only one in the queue I can't review (I'm the uploader)
[20:14] <cjwatson> Because it's a bit of a waste of review effort really
[20:14] <stgraber> cjwatson: no worries, it really only takes 2s per package to check that the version number makes sense :)
[20:14] <iulian> stgraber: Looking.
[20:14] <cjwatson> If it doesn't, dch -R is buggy. :-)
[20:15] <cjwatson> slangasek did raise an issue of potential hardening regressions
[20:15] <cjwatson> But I think what I'm going to do for that is write a script to gather build logs and feed them to blhc
[20:15] <cjwatson> And compare precise/quantal
[20:15] <cjwatson> That's going to be a lot easier than building them all in advance to check, or auditing in some other (presumably manual) way
[20:17] <iulian> stgraber: I'll better leave that to someone else to review.
[20:17] <stgraber> iulian: ok
[20:17] <cjwatson> stgraber: accepted
[20:17] <stgraber> cjwatson: thanks
[20:23] <stgraber> kenvandine: wow, that new upload almost gave me an headache having to remember what's in the revert patch to check that it matches the translations fixes listed in the diff ;)
[20:24] <stgraber> kenvandine: anyway, looks good, accepted :)
[20:24] <kenvandine> stgraber, thx :)
[20:48] <Laney> bah, yeah, qt4-x11 died again
[21:58] <skaet> I've been doing pass through the blueprints,  finding "r" ones in the New pile.
[21:58] <skaet> There is some seriously old cruft in "New" set,  ie 2007,2008, etc.  that doesn't look touched at all.
[22:00] <skaet> Am thinking of marking anything older than 2 years as obsolete,  so it stops showing up on the New searches and wasting time in future.   Esp if the bluerpint only looks half baked (ie. couple of statements, abandoned).   Anyone have issues with that?
[22:20] <xnox> skaet: well relevant people should get an email when you change those old blueprints..... and can reactively patch things up =)
[22:24]  * xnox likes when skaet approves my draft blueprints and sets herself as "participation essential"
[22:24] <skaet> xnox, true.  :)   or ignore them... but at least I don't have to look at them again this way.
[22:27] <skaet> xnox, approved to be considered for r-series so it would show up on the searches at least.   ;-)   You'll still need to get slangasek approving it to be worked on... ;)
[22:29] <skaet> ^ btw,  some easy accepts for rebuilding are out of the queue now.
[22:30] <phillw> skaet: not sure about things, but I do get a notification each time the lubuntu tracker of stuff is done?
[22:31] <skaet> phillw,  you need to subscribe to the blueprint in order to get notifications.
[22:32] <phillw> skaet:  [Blueprint lubuntu-q-work-items] Lubuntu work items for Q
[22:32] <phillw> I get that one everytime it is updated>
[22:32] <skaet> phillw,  name on that one changed to https://blueprints.launchpad.net/ubuntu/+spec/community-r-lubuntu-work-items
[22:32] <phillw> Should i be somewhere else?
[22:33] <skaet> nah,  its release planning, so general sorts of questions are fine here.
[22:34] <phillw> skaet: stop giving me a heart attack, we're not even finished with 'Q', yet!! I know I will be allocated to 'R' :)
[22:35] <skaet> oops.  missed the "q" reference,  there was a place holder for "r" series,  I had to rename today,  so that's what I thought you were talkinga bout.
[22:35]  * skaet goes to look at the lubuntu-q-workitems
[22:38] <phillw> skaet: https://blueprints.launchpad.net/ubuntu/+spec/community-q-lubuntu-work-items does not work (I am talking Quatal)
[22:39] <skaet> no,  I left that alone - since its in use.   just wanted to make sure that the R-series one followed the right pattern to get scheduled.
[22:40] <skaet> anyhow,  just looked at the q one,  and you're on the to be notified list.  (all people subscribed, get notified, every time something changes)
[22:42] <xnox> stgraber: ogra_ : and the other authors opinion is "bin it" =)))) love it!
[22:42] <phillw> skaet: may I please say a YAY!! for a guy who has got your graph on track? first time that I have looked at his.... http://status.ubuntu.com/ubuntu-quantal/u/gilir.html
[22:43] <phillw> skaet: he was always my 'boss', but he's done it :D
[22:44] <stgraber> xnox: ;)
[22:45] <skaet> :)
[22:45]  * skaet --> EOD
[22:45] <phillw> skaet: may I ask what  http://status.ubuntu.com/ubuntu-quantal/group/topic-quantal-release-management.html
[22:45] <phillw> is before you run away?
[22:46] <xnox> phillw: it's meta blueprint that collects all some of the other blueprints as far as I know..... or something.
[22:46] <phillw> skaet: I thought i was doing that with -testing.....
[22:46] <skaet> they were blueprints that were of interest and would have helped manage the release.   Lots not done, and linkely not to, so will be working with individual mangers to get things marked postponed, as appropriate there.
[22:47] <phillw> skaet: is balloons aware of that area>