[00:30] <lifeless> fjlacoste: oh hai
[00:30] <lifeless> fjlacoste: if you want to catch up in the evening or whatever, just let me know
[00:30] <fjlacoste> lifeless: i think i'll pass today, sorry
[00:30] <lifeless> fjlacoste: is cool
[00:30] <lifeless> fjlacoste: hows the conf ?
[00:32] <fjlacoste> lifeless: pretty good
[01:03] <StevenK> wgrant: Can haz another look?
[01:09] <wgrant> StevenK: Done
[01:09]  * StevenK looks for "This is terrible."
[01:18] <StevenK> OMG, referencing a bug that *isn't* bug 933766.
[01:18] <_mup_> Bug #933766: Update bug to use information_visibility_policy <bad-commit-14986> <bugs> <disclosure> <qa-untestable> <Launchpad itself:In Progress by stevenk> < https://launchpad.net/bugs/933766 >
[01:34]  * wallyworld stabs thunderbird. using 3GB of memory and thrashing disk trying to get up to date with qastaging inbox. still waiting.....
[01:35] <StevenK> wallyworld: Using Thunderbird to read the staging inbox? Ha. Hahaha. HAHAHAHAHAHA
[01:36] <wallyworld> yeah, i know now it is a bad idea :-(
[01:36] <rick_h> lifeless: ping, if you have a sec can you peek at the MP for the email notice stuff. I've got two failing tests to fix, but shouldn't change much. https://code.launchpad.net/~rharding/launchpad/email_notice_959482
[01:36] <StevenK> wallyworld: Seriously, though, turn off the agressive caching, since Thunderbird loves to cache the entire message.
[01:36] <rick_h> lifeless: the gpg and oauth adjustments are in a follow up branch I'm still working on getting
[01:37] <wallyworld> StevenK: is there a better alternative like pine or something worth considering?
[01:37] <StevenK> Hahaha, pine.
[01:37] <rick_h> offlineimap + mutt ftw!
[01:37] <StevenK> Is your knowledge of MUAs like 10 years old?
[01:37] <wallyworld> never used those but perhaps i need to
[01:37] <rick_h> I'm a big mutt user
[01:37] <cjwatson> mutt's generally fine for large mailboxes but do enable its header cache.
[01:37] <rick_h> yea, definitely
[01:38] <rick_h> http://blog.mitechie.com/2011/11/20/an-updated-email-config-2-offlineimap-mutt-and-dovecot-ftw/
[01:38] <cjwatson> Exactly my combination
[01:38] <StevenK> wallyworld: I think the staging inbox howto thingy shows how to configure offlineimap
[01:39]  * StevenK tends to be evil, and just uses wgrant to look at the staging inbox for him ...
[01:39] <wallyworld> StevenK: yes, i think it does. i never figured it would be mandatory to use it :-)
[01:39] <rick_h> my license plate is 'cli4lif' :)
[01:39] <wallyworld> funny
[01:39] <StevenK> wallyworld: It depends if you have 48GiB of RAM available and 3 days to wait? :-P
[01:40] <wallyworld> StevenK: i only have 4GB :-(
[01:40] <StevenK> And a crappy i7 Atom that randomly reboots.
[01:41] <StevenK> But that's what you get for buying a laptop based on the fact that it has a numeric keypad. :-P
[01:41] <wallyworld> it hasn't done that the past couple of days, touch wood
[01:41] <wallyworld> i bought it because it has a decent screen resolution
[01:41] <wallyworld> 1600x900
[01:46] <StevenK> wallyworld: My X201 is 1280x800, but I spend my time working on a 24" 1080p LCD.
[01:47] <wallyworld> StevenK: my main monitor is a 23" display but i also like to have a decent laptop screen too
[01:47] <StevenK> Oh bugger, I put off voting in the DPL elections so long they elected zach without me.
[02:17] <wgrant> StevenK: That's Disclosure Supreme, Flawless, and Marvellous Plan to you.
[02:17] <StevenK> Haha
[02:17] <StevenK> Tempted to raise that on the call tomorrow. :-)
[02:23]  * StevenK stabs Banshee four or five times.
[02:24] <StevenK> I plug my mp3 player in, start Banshee, it spews 200 lines or so of Mono garbage tracebacks and then segfaults.
[02:25] <spm> "feature"
[02:25] <StevenK> And the Banshee devs complained when we switched the default away?
[02:25] <StevenK> There is a reason I use Quod Libet as my music player.
[02:26] <spm> exaile here. used to be a die hard amorak fanboi, but around a year or 3 ago they made me cry. so I gave up.
[02:27] <StevenK> I gave up on amorak when it caused my (at the time) dual Athlon to melt into a puddle.
[02:27] <spm> i think it was the crashing everytime I asked it to do something complex like "play this tune" that was the main kicker for me
[02:27] <StevenK> Haha
[02:28] <spm> much like how my previous smartphone would lock dead requiring a hard reset with complex tasks like receiving an SMS
[02:29]  * wgrant just uses Rhythmbox :)
[02:30] <StevenK> Rhythmbox started acting very strange for me last release so I went back to the loving Python embrace of Quod Libet.
[02:30] <spm> is that the current default? if Y, I'm sure I tried it, and gave up on it rather quickly
[02:31] <wgrant> I used Banshee while it was the default, since Rhythmbox was indeed pretty broken.
[02:31] <StevenK> I remember trying Exaile for a day (I think it was 0.22) and giving up in disgust, but I can't recall why.
[02:31] <lifeless> StevenK: just think, your vote would not have changed anything
[02:31] <wgrant> But switched back in early Precise.
[02:31] <StevenK> lifeless: Meh, thank you for making me feel SO much better.
[02:31] <spm> heh
[02:31] <lifeless> StevenK: I failed to vote too
[02:32]  * StevenK goes to buy lunch and probably drown.
[03:33]  * wgrant stabs GIST in the face
[03:33] <StevenK> wgrant: Oh?
[03:34] <wgrant> Everything goes fine on dogfood until I try to FTI
[03:34] <StevenK> I didn't drown, but it was a close run thing. Apparently, Sydney is going to get 140mm of rain over the next two days.
[03:34] <wgrant> Heh
[03:35] <wgrant> Ahaaa
[03:35] <wgrant> Once the index is hot, fti is fast
[03:43] <wgrant> StevenK: You probably have insane team memberships
[03:43] <wgrant> StevenK: How do https://bugs.dogfood.launchpad.net/ubuntu/+bugs?field.searchtext=kernel and https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=kernel compare for you?
[03:45] <lifeless> (Error ID: OOPS-71f5806d495ce2928a38ecae3e91b757)
[03:45] <lifeless> and
[03:45] <lifeless>     At least 47 queries/external actions issued in 2.00 seconds
[03:45] <wgrant> Erm
[03:45] <wgrant> 2s?
[03:45] <wgrant> Should be at least 6
[03:46] <wgrant> Oh, that's a prod oops
[03:46] <lifeless> 2s on dogfood
[03:46] <wgrant> Right, that makes more sense.
[03:46] <wgrant> So, success? :)
[03:47] <wgrant> (this early version of the feature flag has prejoining disabled, so there's a bit of death by a thousand queries still in play, so it will really be faster)
[03:48] <lifeless> wgrant: nice
[04:28] <StevenK> wgrant: I was lunching, do you still want me to check?
[04:29] <wgrant> StevenK: More data is always nice.
[04:30] <wgrant> Even though the data so far suggests that the Disclosure Supreme, Flawless, and Marvellous Plan lives up to its title.
[04:30] <StevenK> wgrant: Hah, so. Timeout on prod, and 29second on DF
[04:31] <wgrant> StevenK: What if you retry?
[04:31] <wgrant> The fti and most of the table had probably dropped out of DF's cache
[04:31] <wgrant> Given they're like 2GB all up, and DF has 4GB...
[04:31] <StevenK> wgrant: 9.01 seconds on prod and 2.76 seconds on DF.
[04:32] <wgrant> That's more like it.
[04:32] <StevenK> I thought 9.01 should have timed out.
[04:32] <wgrant> It must have ticked over 9 right after the timeout check.
[04:32] <wgrant> StevenK: What are the timings for the two BugTaskFlat queries?
[04:32] <wgrant> in the DF query log
[04:32] <StevenK> Sigh, mawson is all the way over there.
[04:32] <wgrant> No
[04:32]  * StevenK reaches for it.
[04:32] <wgrant> Click link at top of page
[04:33] <wgrant> "XX queries/external actions"
[04:33] <wgrant> it's a link
[04:33] <wgrant> expands query log
[04:33] <lifeless> only if you're logged in and in the lp dev group there
[04:33] <StevenK> 509ms and 1202ms.
[04:33] <wgrant> Which StevenK is
[04:33] <wgrant> Huh
[04:33] <wgrant> Slow
[04:33] <wgrant> k
[04:33] <StevenK> lifeless: Pft, I'm a duck on DF.
[04:34] <wgrant> Burn!
[04:34] <StevenK> Burn which bit?
[04:34] <wgrant> You
[04:34] <wgrant> You're a witch :)
[04:34] <StevenK> Really?
[04:35] <StevenK> wgrant: Looks like my team memberships and such are a bit more insane than lifeless'?
[04:36] <wgrant> Or lifeless may not have been logged in
[04:36] <wgrant> Although
[04:36] <wgrant> Yours should be faster...
[04:36] <lifeless> I wasn't logged in
[04:36] <wgrant> since you're a duck
[04:36] <wgrant> It will ship all the perm checks
[04:36] <wgrant> skip
[04:36] <wgrant> Sigh
[04:37] <wgrant> need more ram
[04:37] <wgrant> My desktop has 4x more than mawson :(
[04:37] <lifeless> hah, sso puts a spurious : after the fields in the what-fields-you-get confirmation form
[04:37] <wgrant> Yeah
[04:37] <wgrant> Has for ages
[04:37] <wgrant>  /ever
[04:38] <StevenK> wgrant: But your desktop was manufactured sometime this century. :-)
[04:38] <lifeless> wgrant: 143 queries/external actions issued in 11.12 seconds
[04:38] <lifeless> AJAX Log ↓
[04:38] <wgrant> Yeah, DF doesn't do so well with a cold cache
[04:38] <lifeless> 1895ms 	
[04:38] <lifeless> SQL-main-slave: SELECT * FROM ((SELECT Person.account
[04:38] <wgrant> I've just been browsing Launchpad's bugs, so Ubuntu will be long gone
[04:38] <wgrant> Heh
[04:38] <wgrant> So that's just listing your team administerships
[04:38] <lifeless> 2248ms 	
[04:38] <StevenK> I think mawson's disks have begun to fossilize
[04:38] <lifeless> SQL-main-slave: SELECT BugTaskFlat.bugtask FROM
[04:39] <wgrant> :(
[04:39] <lifeless> 4991ms 	
[04:39] <lifeless> SQL-main-slave: SELECT COUNT(*) FROM BugTaskFlat
[04:39] <lifeless> 143 queries/external actions issued in 5.14 seconds
[04:39] <lifeless> AJAX Log ↓
[04:39] <wgrant> I guess I should fix the last few tests failures and get this onto qas.
[04:40] <lifeless> lots of SQL-main-slave: SELECT TeamParticipation.id, TeamParticipation.person, TeamParticipation.team FROM TeamParticipation WHERE TeamParticipation.person = 2980965 AND TeamParticipation.team = 430914
[04:40] <lifeless> 1606ms 	
[04:40] <lifeless> SQL-main-slave: SELECT BugTaskFlat.bugtask
[04:40] <wgrant> Yeah, those aren't even my fault :/
[04:40] <lifeless> 1764ms 	
[04:40] <lifeless> SQL-main-slave: SELECT COUNT(*) FROM BugTaskFlat WHERE BugTaskFlat
[04:40] <lifeless> 60ms 	
[04:40] <lifeless> SQL-main-slave: WITH teams AS (SELECT team from TeamParticipation WHERE person=2)SELECT combinedbugsummary.distroseries
[04:40] <lifeless>  :)
[04:40] <wgrant> lifeless: I think those TP checks might be subscriptions
[04:41] <wgrant> Deciding whether you're subscribed or not
[04:41] <wgrant> Pretty hilarious way to go about it, which is why it's completely plausible.
[04:41] <lifeless> why would that page care ?
[04:47] <wgrant> lifeless: It has the new bug subscriptions stuff on it.
[04:47] <wgrant> Anything touched by that is cursed forever.
[04:48] <wgrant> To be 500ms slower than it would otherwise be.
[04:54] <StevenK> wallyworld: Can haz QA for r15100?
[04:54] <wallyworld> StevenK: still waiting for my qas inbox to finish syncing
[04:54]  * StevenK grumbles about having to feature flag the UI changes.
[04:57]  * wallyworld grumbles about yui tests in lxc core dumping :-(
[05:00] <wgrant> wallyworld: You've enabled X forwarding in SSH?
[06:20] <wgrant> Down to 92000 messages in the staging inbox...
[06:20] <wgrant> Nearly there
[06:39] <wallyworld> wgrant: i don't use ssh with the lxc setup is use, i just sudo lxc-start -n lpdev and get a login prompt directly
[06:42] <wgrant> wallyworld: Ah, that would do it.
[06:42] <wgrant> wallyworld: No X server
[06:43] <wgrant> wallyworld: Perhaps try xvfb-run
[06:43] <wallyworld> ah right. will do thanks.
[06:43] <wgrant> wallyworld: Did you make any progress on QAing poolie's size limit?
[06:43] <wallyworld> wgrant: *still* waiting for fucking qas inbox to download everything
[06:43] <wgrant> wallyworld: I just deleted 430000 mails from it
[06:43] <wgrant> You might want to restart thunderbird
[06:43] <wgrant> It's got like 4000 now.
[06:44] <wallyworld> already have. i can delete about 50000 at once. it's been swapping all day :-(
[06:44] <wgrant> I did 100000 at a time. Just had to click Continue about 100 times.
[06:44] <wgrant> Make sure you disable the message pane when doing bulk operations.
[06:45] <wgrant> Otherwise it will try to render a list of threads.
[06:45] <wallyworld> that would help
[06:45] <wallyworld> i've lost count of the number of "script has stopped" dialogs i've clicked on
[06:46] <wallyworld> plus when the disk thrashes, the desktop stops accepting mouse clicks :-( not sure whether to blame unity or X or compiz
[06:46] <wgrant> Sounds like you're swapping heavily :)
[06:46] <wgrant> Need moar rams
[06:47] <wallyworld> yeah. normally get by fine with what i have
[06:47] <wgrant> 4GiB?
[06:47] <wallyworld> yep
[07:18] <wallyworld> wgrant: i see you sent a large email to qas.
[07:18] <wallyworld> my qas inbox finally cuaght up
[07:18] <StevenK> It only took all day.
[07:18] <StevenK> Is your laptop still thrashing?
[07:18] <wallyworld> yeah :-(
[07:18] <wallyworld> no
[07:18] <wallyworld> just finished
[07:19] <wallyworld> after 1000000 thunderbird restarts and clicking on Continue dialogs
[07:20] <StevenK> Maybe you'll use offlineimap next time. :-P
[07:21] <lifeless> I've just purged it
[07:21] <lifeless> 42K messages, 0 need for them
[07:21] <wallyworld> StevenK: well, i didn't think i needed to :-)
[07:21] <lifeless> you don't
[07:21] <lifeless> if folk delete as they qa
[07:21] <wallyworld> too bad we don't clear qas inbox more often
[07:21] <StevenK> lifeless: You tell funny jokes.
[07:22] <lifeless> StevenK: apparently so
[07:22] <wallyworld> why don't we automatically purge once every couple of days?
[07:22] <wgrant> lifeless: Did you just delete *everything*?
[07:22] <StevenK> lifeless: Suprised you didn't make a ruling in terms of non-LP members doing QA.
[07:22] <wgrant> I'd already deleted most of them.
[07:22] <lifeless> noone has gotten theactivation energy up to do it
[07:22] <wgrant> And I think you nuked my test mail :(
[07:22] <wallyworld> wgrant: i read it, looked ok
[07:22] <lifeless> wgrant: there were 42K messages there, I wasn't selective
[07:23] <wgrant> wallyworld: Ah, thanks.
[07:23] <wallyworld> wgrant: i marked the bug as qaok
[07:23] <wgrant> lifeless: I usually leave everything from the last 24 hours
[07:23] <wgrant> wallyworld: Even better.
[07:27] <wgrant> wallyworld: I get "NotFound: Object: None, name: u'index.html'"
[07:27] <wgrant> wallyworld: Nothing about a default view
[07:28] <wallyworld> wgrant: i was going by the string handed to the exception constructor in the base class. but anyway, it still refers to index.html which implies a page is expected
[07:28] <wgrant> wallyworld: That's correct.
[07:28] <wgrant> When browsing to an object in a browser, it will try to render the default view.
[07:28] <wgrant> The default view is index.html unless overriden.
[07:28] <wgrant> This is normal.
[07:29] <wgrant> Eg https://launchpad.net/package-sets
[07:29] <wgrant> Same for any object that doesn't have views
[07:29] <wallyworld> in this case i don't think it is because i see it as a case on an incomplete url
[07:29] <wallyworld> like lp/net/launchpa
[07:29] <wallyworld> typo
[07:29] <wallyworld> . not /
[07:29] <wgrant> Structurally it is a complete URL.
[07:30] <wgrant> Overriding as you've done is of minimal utility and breaks the convention around the rest of the codebase and every other ZTK app.
[07:30] <wallyworld> oh alright. not worth arguing about. i'll change it
[07:31] <wgrant> To a user the difference is 0
[07:31] <wgrant> They don't see the traceback.
[07:34] <wgrant> Hah
[07:34] <wgrant> I'm going to accidentally fix the bug where milestones are duplicated on the advanced search page.
[07:34] <wgrant> How convenient.
[07:55] <lifeless> oh noes
[07:55] <lifeless> we can't have less bugs
[07:55] <lifeless> bugs are currency
[07:55] <StevenK> You would say that.
[07:56] <lifeless> YHBT HAND HTH
[07:57] <bigjools>  
[07:58] <bigjools> bwaha
[07:58] <czajkowski> I need a dictionary for lifeless
[07:58] <bigjools> it's funny because that's what StevenK trots out
[08:02] <lifeless> czajkowski: urban dict probably has them all
[08:02] <lifeless> czajkowski: or perhaps the new new hackers dict
[08:03] <czajkowski> lifeless: would you mind haveing a look at juju bug against lp please. https://bugs.launchpad.net/launchpad/+bug/983530
[08:03] <_mup_> Bug #983530: "charms" needs branch name consistency <juju:Invalid> <Launchpad itself:New> < https://launchpad.net/bugs/983530 >
[08:03] <czajkowski> lifeless: a swift google was helpful
[08:03] <lifeless> SpamapS: hey ^
[08:03] <czajkowski> my brain doesnt seem to want to fucntion at this hour of the morning
[08:03] <lifeless> SpamapS: what is the problem ?
[08:03] <wgrant> lifeless: See backscroll
[08:03] <adeuring> good morning
[08:04] <wgrant> From about 8 hours ago
[08:24] <SpamapS> lifeless: in charms, we often use 'bzr push lp:charms/foo' to create new charms.
[08:25] <SpamapS> lifeless: this creates lp:~yourname/charms/series/foo/trunk
[08:25] <SpamapS> lifeless: however, when branch-distro is run to copy forward and do the stacking jitterbug, it uses lp:~yourname/charms/series/foo/series
[08:26] <SpamapS> lifeless: the charm store code specifically targets 'trunk' because we need users to be able to have a way to say "this is my personal published version of foo"
[08:26] <lifeless> wait, what ?
[08:26] <SpamapS> lifeless: so we can't really use branch metadata becaus we can't have two foo's for any one user
[08:27] <SpamapS> or rather we can't have two foo's for any one user+series
[08:27] <lifeless> how does that impact the blessed charms ?
[08:28] <SpamapS> lifeless: the charmstore maps lp:~auser/charms/precise/foo/trunk to 'juju deploy cs:~auser/precise/foo'
[08:28] <SpamapS> lifeless: the blessed charms do have a 1:1 series<->charmname mapping, so I did suggest that we should just use that to workaround this. But it stands to reason that branch-distro should probably agree with push-to-create
[08:29] <lifeless> SpamapS: are they able to say cs:~auser/precise/foo/trunk, if they want to ?
[08:29] <SpamapS> lifeless: no
[08:29] <SpamapS> lifeless: though I believe that is desired
[08:29] <SpamapS> its not part of the store *now*
[08:30] <lifeless> so for users, this is irrelevant, because its only the blessed charms that are branched
[08:30] <SpamapS> right
[08:30] <lifeless> the blessed charms should be listed as the development focus branch, in LP's package metadata
[08:31] <lifeless> so they shouldn't be affected either
[08:31] <lifeless> unless the charm store isn't using that pointer (which it should)
[08:31] <SpamapS> it is to map lp:charms/foo -> cs:foo
[08:31] <SpamapS> (which is the default, so 'juju deploy foo'
[08:32] <SpamapS> lifeless: the troubling part is the inconsistency
[08:32] <SpamapS> lifeless: I know we can mold the charm store loader to just load the dev focus branches as blessed regardless of their name. but they'll still have weird names
[08:33] <SpamapS> lifeless: also when copying forward, one thing that happened was any charms that were manually ported forward to precise were named 'trunk', and so were not detected as already existing.
[08:35] <wallyworld> wgrant: can haz +1 on that review?
[08:45] <wgrant> wallyworld: Ah, sure. Was just waiting for the diff to update, then forgot.
[08:58] <wallyworld> wgrant: np. thanks. i am trying to make the next bb run :-)
[09:37] <StevenK> cjwatson: It matters little, but spot the duplication in your most recent landing:
[09:37] <StevenK> 120	+ distro = bpph.distroseries.distribution
[09:37] <StevenK> 121	+ script = self.makeScript(bpph.distroseries.distribution)
[09:45] <cjwatson> StevenK: reasonable point; I was copying from test_getDirtySuites_returns_suite_with_pending_publication and test_getDirtySuites_ignores_suites_without_pending_publications and didn't notice
[09:46] <cjwatson> doesn't seem worth another landing to fix though, really?
[11:00] <lifeless> SpamapS: ok, so I think that the bug may need some fine tunuing ;)
[11:00] <lifeless> gnight
[11:09] <StevenK> cjwatson: Nah. Like I said, it matters very little. If you care, you can do a drive-by in your next branch. Or you don't care, either is fine.
[11:25] <StevenK> czajkowski: :-(
[11:25] <czajkowski> StevenK: now what have I done.
[11:25] <StevenK> czajkowski: Your G+ reply, you bad person.
[11:26] <czajkowski> StevenK: hi we've clearly never met if you're only realising that now :)
[11:26] <czajkowski> I blame the blessed charms for todays corruption!
[11:26] <StevenK> Hah
[11:27] <StevenK> Which makes it SpamapS fault.
[11:27] <StevenK> And the universe makes sense again.
[13:08] <dpm> hi all, could someone help me with an issue with translations? We've got the calligra source package in Ubuntu and its translations do not seem to get imported. Here are the details:
[13:08] <dpm> The imports queue is empty save for some manual uploads:
[13:08] <dpm> https://translations.launchpad.net/ubuntu/precise/+source/calligra/+imports
[13:09] <dpm> The po files were uploaded separately with the calligra-l10n package:
[13:10] <dpm> https://translations.launchpad.net/ubuntu/precise/+source/calligra-l10n/+imports
[13:11] <dpm> It's a KDE translation, which makes it a bit special and means the PO files will not be imported into any calligra-l10n template, but rather on the corresponding template in the calligra source packad
[13:11] <dpm> *package
[13:12] <dpm> So my question is whether someone could help me determine whether the PO files will end up in the right package or whether I should start to worry
[13:13] <dpm> I know there is a check somewhere in the LP code to determine if an upload corresponds to a KDE package and then takes care of all this, but I'm not familiar with the code other than knowing that this function exists
[13:13] <dpm> I just want to ensure the calligra translations end up in the right place and can be shipped in the language packs
[13:32] <adeuring> abentley: standup?
[13:55] <rick_h> dpm: hmmm, so there are imports on that l10n going back to Jan it looks like, 4k of them?
[13:56] <rick_h> jtv: ping, I'm told you might be a translations master and know something about how this works?
[13:58] <dpm> rick_h, yeah (not sure about the translations part, though :). Back then the calligra package did not have any templates, so the translations were uploaded but had nowhere to go, as PO files only get imported if there is a corresponding template. Last week the templates were created and a new upload was made, which should in theory solve the issue. The way LP works, the 4k old translations will remain there, I believe, as there is no template associate
[13:58] <dpm> d with them.
[13:59] <rick_h> dpm: ok, so there were some imports done after the 4/11 imports that didn't have a template?
[14:02] <dpm> rick_h, the templates were created last week (on the 10th or 12th, I think). All of the uploaded PO files before that date will remain in Needs Review (forever, I believe), whereas the PO files uploaded after should in theory get associated with a template and should be imported. And the "should get imported" part is what I'm trying to figure out :)
[14:04] <rick_h> dpm: ok, I've ping'd jtv, I'm not sure atm how the imports work like this and asking in our stand up didn't get me much further. Let's see if he gets back to us and if not I'll try to find more help/guidance.
[14:06] <dpm> rick_h, ok, thanks for your help. jtv is on his day off, I think
[14:12] <gary_poster> jml, are you still hoping to merge your three testtools branches today?  We're already making our own rollup branch, but we'd still love to have an official merge, let alone an official release.
[14:13] <gary_poster> We'll need to do similar dances for testrepository (we have one MP with no reply, with another on its way) and subunit (we need a release of the trunk in order to get some tag support changes that Robert added recently).
[14:16] <jml> gary_poster: yes. about to do so now.
[14:16] <jml> gary_poster: sorry about the muck-around
[14:16] <gary_poster> awesome thanks jml.
[14:16] <jml> gary_poster: I'm going to apply lifeless's suggestion from the yellow testr review
[14:16] <jml> gary_poster: and parametrize wrap_result
[14:16] <gary_poster> cool jml, thanks
[14:16] <gary_poster> benji ^^
[14:17] <jml> gary_poster: that will cause a conflict for you when you merge, but hopefully nothing too tough
[14:17] <jml> fwiw, my excuse is that I moved house yesterday (taking the day off) and still don't have home internet today.
[14:18] <gary_poster> jml, ugh!  moving house is never easy, and sometimes difficult for months or years later. :-) thank you very much for getting this through
[14:25] <jml> having fast Internet changes *everything*
[14:27] <gary_poster> :-)
[14:36] <jml> gary_poster, benji: tagger, tsfr-fixup and wrap-result-in-concurrent-suite all merged & pushed (lp:testtools r253). Let me know if there are problems.
[14:36] <gary_poster> thank you very much jml
[15:02] <jtv> rick_h: sorry, I'm not doing any more work tonight!
[15:02] <salgado> jamestunnicliffe, you'll need to ask one of the LP tech leads to approve a feature flag change to enable the view to members of Linaro
[15:03] <salgado> the feature flag will be something like "team:linaro registry.upcoming_work_view.enabled 1" (need to check the correct syntax/order)
[15:04] <sinzui> jcsackett, how goes the bug subscriber branch?
[15:06] <salgado> sinzui, maybe you can approve that feature flag (^) change?
[15:11] <jcsackett> sinzui: i spent some time reading through the whole of the various subscription code last night, so i've been able to iron out those inconsistencies and am making progress.
[15:12] <jcsackett> there are some tests regarding the DB triggers i haven't gotten to looking at yet--there's a very good chance i'll be pinging you when i hit those. i expect they're going to be complicated.
[15:12] <sinzui> salgado, sure, is the entry on the osa page?
[15:12] <salgado> sinzui, not yet. should I add it?
[15:12] <jcsackett> sinzui: would've pinged you earlier, but i was excited once i had things sorted out and just sort lost myself in fixing things.
[15:13] <sinzui> jcsackett, okay, please ping me to talk if you are getting frustrated. I can listen and sympathise, and sometimes help fix
[15:14] <jcsackett> sinzui: will do, and thanks. :-)
[15:14] <sinzui> salgado, add it the the ff section on https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus
[15:14] <sinzui> you can add me as the approver now since I agree that linaro needs to see the feature work
[15:15] <salgado> jamestunnicliffe, so, that (^) is what needs to be done, but the wiki page is internal-only so the next time you need to do it you'll just need to ask whoever approves the feature flag to add it to the wiki page as well
[15:15] <salgado> thanks sinzui!
[15:16] <jamestunnicliffe> thanks salgado!
[15:17] <jamestunnicliffe> (and sinzui)
[15:23] <czajkowski> sinzui: oh wise one, should a bugs description be editabled after a fix released so in theory it's closed be allowed to happen ?
[15:23] <jml> bac: hi
[15:24] <jml> bac: I've had a bit of a look at https://code.launchpad.net/~bac/testrepository/bug-949950/+merge/102317. Do you want to discuss it here, or would you rather a put some notes on the MP?
[15:24] <bac> hi jml
[15:24] <bac> jml: here is fine, as long as it is summarized on the MP
[15:24] <sinzui> czajkowski, yes it should be editable so that confusing text is removed
[15:24] <jml> bac: can do.
[15:25] <jml> bac: I downloaded it and gave it a try. It looks like you'll only get test failures and start & end timestamps in the subunit stream.
[15:26] <bac> jml: oh, really
[15:26] <jml> bac: yeah
[15:26] <bac> that isn't great
[15:27] <jml> bac: I didn't think it was what you wanted.
[15:27] <bac> jml: any thoughts on why that happens?
[15:27] <jml> bac: it's not very obvious, but 'run' delegates to 'load'
[15:28] <jml> bac: and 'load' uses the make_result() that your patch changes
[15:28] <jml> to make something called 'output_result', which is the result responsible for UI output (which makes sense, I hope)
[15:28] <bac> yes
[15:29] <jml> immediately below that, is this:
[15:29] <jml>         filtered = TestResultFilter(output_result, filter_skip=False)
[15:29] <jml> and it's that 'filtered' result that gets used from then on
[15:29] <jml> so output_result never even gets the events for successful tests
[15:29] <jml> (sorry for dragging this out, I'm figuring it out as I go along)
[15:30] <bac> jml, np
[15:31] <jml> I think the right thing to do is to push that TestResultFilter call down into the UI make_result
[15:31] <jml> because, really, choosing which results to display is a UI decision.
[15:32] <bac> jml: makes sense
[15:32] <jml> bac: there'll probably be a bunch of annoying test fallout from that.
[15:32] <jml> bac: sorry.
[15:32] <bac> jml: and you're suggesting not applying the filter when we select --subunit?
[15:32] <jml> bac: uhh, yes, I think so.
[15:32] <jml> umm sort of
[15:33] <jml> bac: there's a part of me that thinks there should be another option that controls whether only failures are shown vs full results
[15:33] <jml> bac: and that the default should stay as is regardless of whether the output is the pretty text output or a subunit stream.
[15:34] <czajkowski> sinzui: even after the bug has been fixed released?  surely editing the description then is confusing
[15:35] <bac> jml: so grow a '--full-results' (modulo spelling).  would that be only for the run command?
[15:35] <czajkowski> sinzui: an example is https://bugs.launchpad.net/launchpad/+bug/272826  which was edited today
[15:35] <_mup_> Bug #272826: "Ubuntero" inappropriate for female contributors <lp-registry> <Launchpad itself:Fix Released by barry> <Ubuntu Website:Fix Released by newz> <Ubuntu:Fix Released by communitycouncil> < https://launchpad.net/bugs/272826 >
[15:35] <jml> bac: run & load yes.
[15:36] <bac> jml: ok.  so if you'll disapprove that MP i'll look at doing that this afternoon
[15:36] <jml> bac: the other point of my feedback was going to be that load should have the option too. I think that's pretty trivial to code up.
[15:36] <jml> bac: will do that, and put my notes there now.
[15:36] <bac> jml: cool, thanks
[15:36] <jml> bac: thank you!
[15:37] <sinzui> czajkowski, it is not a bug. Bug descriptions often need to be updated to distinguish past behaviours from modern ones, or provide proper urls, tests, or work arounds so that users do not report a new bug or reopen the existing one
[15:39] <czajkowski> sinzui: I suppose if it were called a bug summary it wouldb't be as bad, I guess calling it a descrption is just rather misleading in this case.
[15:39] <sinzui> czajkowski, that is different issue. The bug title is not a title either
[15:40] <czajkowski> indeed
[16:09] <maxb> Is there any known breakage with package copies at the moment? I'm trying to copy reusing binaries from natty to oneiric within a single PPA, and I'm getting a spurious binary conflict
[16:13] <czajkowski> maxb: there was lp servers rebooted there at 16:00 UTC
[16:13] <czajkowski> for about 10 mins
[16:13] <maxb> I'm getting a specific logic error, rather than a downtime-related issue
[16:24] <rick_h> abentley: ping do you have time for a quick review? https://code.launchpad.net/~rharding/launchpad/email_notice_extras_959482/+merge/102341
[16:24] <rick_h> abentley: some drive by linting at the top makes it look bigger than it is
[16:38] <jml> Can someone please land https://code.launchpad.net/~jml/launchpad/expose-commercial-on-create-ppa/+merge/101907
[16:38] <rick_h> jml: sure thing, will pull that down
[16:39] <jml> rick_h: thank you
[16:51] <rick_h> jml: onto ec2 ok
[16:51] <jml> rick_h: \o/
[17:24] <abentley> rick_h: Sorry, was lunching.
[17:25] <rick_h> abentley: np, no hury
[17:26] <abentley> rick_h: LOC rationale?
[17:27] <rick_h> abentley: sorry, it's been ok'd in the dep branch by lifeless as small hit to fix security issue
[17:29] <abentley> rick_h: r=me
[17:29] <rick_h> abentley: ty
[18:24] <sinzui> jcsackett, r=me
[18:42] <jcsackett> sinzui: thanks.
[19:25] <dobey> can i beg someone to make a +downlaod page work for each series, and not have only the generic one for a project?
[19:44] <sinzui> dobey, We don't have any requirements for what +download should do anymore. It is truly fucked. I will not make anymore changes until someone provides the use case for it. It was once about packagers...and it certainly is not now
[19:46] <sinzui> dobey, Why does a series need +downloads?
[19:46] <dobey> sinzui: for packagers :)
[19:47] <sinzui> dobey, shouldn't the series page show the current release tarball then?
[19:47] <sinzui> does it need to show anything more?
[19:47] <dobey> i suppose it could just be on the series page if uscan can handle that
[19:48] <sinzui> ah
[19:48] <dobey> http://launchpad.net/ubuntuone-storage-protocol/+download .*/ubuntuone-storage-protocol-([0-9.]+)\.tar\.gz
[19:48] <dobey> that's what is in debian/watch for example
[19:48] <sinzui> I already reported a bug specifically for that situation, but some how it became unimporant and I stopped trying to please everyone
[19:48] <dobey> but it wants to grab 3.0.0 which is for precise, even though i'm doing an SRU for oneiric, for example :)
[19:49] <sinzui> https://bugs.launchpad.net/launchpad/+bug/231797
[19:49] <_mup_> Bug #231797: no sensible way to use debian/watch files with launchpad hosted tarballs (no simple url-and-link list of all downloads) <lp-registry> <packaging> <releases> <Launchpad itself:Triaged> <devscripts (Ubuntu):Invalid> < https://launchpad.net/bugs/231797 >
[19:50] <dobey> being able to specify the series would be brilliant, but there's no way to do that right now
[19:51] <dobey> you can specify a link to a specific milestone, which isn't the same
[19:51] <sinzui> I think we just want a permalink that is obvious from the url structure to support it. It is only for debian/watch case, so no one can screw it up again
[19:51] <dobey> or can i use the series page perhaps?
[19:52] <dobey> i guess i should try that
[19:52] <sinzui> dobey, https://launchpad.net/gdp/0.5.x shows the current release
[19:52] <sinzui> eg a real url with a tarball in it
[19:53] <dobey> right
[19:53] <sinzui> but I personally would not trust it since it is not designed for uscan
[19:53] <dobey> and +download is?
[19:54] <dobey> it has the exact same links on it, but it's paginated and has everything ever released
[19:55] <sinzui> +downloads is a semi0orderd list of all releases from all series. It is not clear who needs it since obsolete series are listed and it seams to encourage end-users to download and compile lots of tarballs
[19:55] <sinzui> The pagination was added to support some odd case were someone want to get old data, possibly because someone uploaded a .exe
[19:57] <sinzui> Once end-users were using that page and it was paginated to do fuck-knows-what, the people who needed it most were cut out. The whole mess it the result of a handful of well-meaning developers adding features without really verifying why if they accomplished something meaningful
[19:58] <lifeless> wouldn't it be nice if we could test for that
[19:59] <sinzui> dobey, do not trust anything in a "downloads" portlet it shows the latest uploaded thing, not the tarball, and not the actual version...again, there is not clear use-case for it. I think the intent was to encourage end-users to learn how gcc works
[19:59] <lifeless> sinzui: how are things; is there anything you want to catch up on - its been a few weeks since we last spoke
[20:00] <dobey> sinzui: well it it shows the latest uploaded thing for the series. i presume i can halfway trust it if i control what gets uploaded and when :)
[20:00] <sinzui> lifeless, we are not facing any technical issues, we are just struggling to to step on each other to get the UI ready for beta
[20:01] <dobey> sinzui: so probably safe enough to use for packages for projects i maintain? or should we get some more reasonable thing set up like a +download page for series?
[20:02] <sinzui> dobey, you can trust it if you trust the maintain who uploads. The portlet is correct for my work because I really do want packagers to the right thing..but I have the advantage oh having read the code and bug reports. I am still bitter as you can tell
[20:02] <dobey> heh
[20:03] <sinzui> I propose something special and testible for bots so that it is clear the feature is not to address someone's feelings...bot just need the correct data and nothing more
[20:04] <dobey> sure. sounds good
[20:10] <lifeless> sinzui: ok cool
[20:41] <lifeless> wgrant: you were asking about job clearing on restores...
[20:41] <lifeless> wgrant: I suspect we don't, systematically - [STAGING] Cron <launchpad@gandwana> $LP_PY /srv/staging.launchpad.net/staging/launchpad/cronscripts/process-job-source.py IPlainPackageCopyJobSource -q --log-file=INFO:/srv/staging.launchpad.net/staging-logs/process-job-source.IPlainPackageCopyJobSource.log
[20:41] <lifeless> 2012-04-17 20:39:30 ERROR   Unhandled exception
[20:41] <lifeless>  -> http://staging.launchpadlibrarian.net/99588237/gYMKrWK5lzGeNC4Db0iVcuSdQWW.txt (ERROR:  No such user
[20:41] <lifeless> )
[21:59] <wgrant> lifeless: Was I?
[22:07] <lifeless> wgrant: s/asking/speculating/ yesterday
[22:08] <[reed]> hey, I'm not sure where exactly I should be filing this... https://bugs.launchpad.net/launchpad/+bug/984415
[22:08] <_mup_> Bug #984415: Launchpad bugzilla integration causes Bugzilla-side warnings <Launchpad itself:New> < https://launchpad.net/bugs/984415 >
[22:08] <[reed]> is that the right place?
[22:09] <lifeless> thats fine yes.
[22:09] <lifeless> whats happening ?
[22:29] <[reed]> lifeless: getting errors on Bugzilla's side every 10 min. when launchpad hits it :)
[22:29] <[reed]> trying to track down what's causing them
[23:32] <wgrant> rick_h: Did you get a text review of your new email template this time? Also, "security_field_changed" isn't a valid method name.
[23:33] <wgrant> There are also various text issues in the notification strings in the code.
[23:53] <lifeless> wgrant: whats invalida bout it ?
[23:53] <lifeless> wgrant: being pep8?
[23:54] <wgrant> lifeless: Yes
[23:54] <wgrant> That bit of PEP 8 illegal in Launchpad.
[23:54] <wgrant> +is
[23:56] <lifeless> ahh well, life is too short
[23:56] <lifeless> I wrote that method