[00:55] <lifeless> wgrant: will look for you in a minute
[00:56] <lifeless> mars: oh, you're gone.
[01:19] <lifeless> wgrant: cp has been done
[01:19] <lifeless> "Julians: Fixes critical bug where arch-independent files are
[01:19] <lifeless> getting erroneously superseded across series boundaries, resulting in
[01:19] <lifeless> loss of data for PPA users and incorrect package status in Ubuntu
[01:19] <lifeless> SteveKs: Don't copy disabled DASes to the child distroseries during
[01:19] <lifeless> InitialiseDistroSeries."
[01:19] <wgrant> lifeless: They're both on cocoplum and germanium?
[01:21] <lifeless> dunno
[04:12] <Hudson> Project devel build (95): STILL FAILING in 4 hr 1 min: https://hudson.wedontsleep.org/job/devel/95/
[04:15] <wgrant> !!
[04:15] <StevenK> \o/
[04:16] <mwhudson> me likey the shouting
[04:17] <StevenK> It can also do e-mail, a'la buildbot, I've just not configured it
[04:17] <lifeless> .oO a hudson
[04:17] <lifeless> StevenK: I like twitter myself
[04:17]  * StevenK is ignoring twitter in the hopes it all just goes away
[04:17] <lifeless> StevenK: we're organising openid
[04:18] <StevenK> lifeless: For 1.378 or 'soon'?
[04:18] <lifeless> soon
[04:18] <wgrant> OpenID for what?
[04:18] <lifeless> hudson
[04:19] <lifeless> StevenK: please pick a different irc nick for our hudson
[04:19] <wgrant> It doesn't support it? That's a bit odd.
[04:19] <StevenK> lifeless: Suggestions?
[04:19] <lifeless> lpci ?
[04:19] <lifeless> 42?
[04:19] <lifeless> 101010?
[04:19] <lifeless> back soon
[04:26] <LPCIBot> Project db-devel build (53): STILL FAILING in 15 min: https://hudson.wedontsleep.org/job/db-devel/53/
[04:27] <StevenK> Oh, damn, I know why
[04:29] <LPCIBot> Project db-devel build (54): STILL FAILING in 32 sec: https://hudson.wedontsleep.org/job/db-devel/54/
[04:40] <wallyworld> StevenK: you are going to install the Chuck Norris plugin for the Hudson instance aren't you? :-)
[04:41] <wallyworld> http://wiki.hudson-ci.org/display/HUDSON/ChuckNorris+Plugin
[04:43] <StevenK> I wasn't planning on :-)
[04:47] <wallyworld> but it's soooo cool
[04:49] <wallyworld> that default butler guy is too boring. chuck makes it a lot more interesting
[05:22] <lifeless> brucie!
[05:24]  * StevenK blinks at subunit
[05:31] <lifeless> StevenK: the bruce schnier plugin ftw
[05:32] <StevenK> Both of which are completly pointless? :-)
[06:20] <lifeless> wallyworld: you have mail
[06:24] <wallyworld> lifeless: thanks
[06:26] <poolie> lifeless: thanks for your post about a flags remote api; but let's put it on that bug?
[06:26] <poolie> that mp is big enough already
[06:28] <lifeless> poolie: sorry :)
[06:28] <poolie> np :)
[06:28] <poolie> it's an interesting point
[06:28] <poolie> i just don't want it lost
[06:28] <lifeless> poolie: perhaps you could copy it across?
[06:28] <poolie> sure :)
[06:28] <lifeless> thank you
[06:33] <poolie> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/656031 in case you think of anything else or want to prioritize it
[06:33] <_mup_> Bug #656031: want non-storm way to get feature rules <feature-flags> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/656031>
[06:39] <StevenK> lifeless: Are you up for a quick testfix review for db-devel?
[06:41] <wgrant> StevenK: You wouldn't happen to know the publisher code, would you?
[06:42] <StevenK> wgrant: What about it?
[06:43] <wgrant> StevenK: I think the way that it determines which pockets and archs to generate a Release file for is far more complicated than it needs to be.
[06:43] <wgrant> And I'm hoping that someone who still exists has dealt with it before.
[06:43] <wgrant> But I doubt it :(
[06:43] <StevenK> I suspect Julian, maybe al-maisan
[06:44] <wallyworld> lifeless: well, 5th time lucky on that sql logging branch. it's in the hands of the ec2 gods again. i've made a sacrifice on an old windows pc to appease them
[06:45] <wgrant> Speaking of landing... I have a branch that ec2 has thrown a fit at three times. Could someone try it again?
[06:45] <wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/bug-629921-packages-empty-filter/+merge/37339
[06:47] <StevenK> wgrant: Doing so
[06:47] <wgrant> StevenK: Thanks.
[06:56] <lifeless> StevenK: url
[06:57] <StevenK> lifeless: https://code.edge.launchpad.net/~stevenk/launchpad/db-fix-disabled-dases-test/+merge/37819
[06:57] <lifeless> doesn't edwin have the same thing up for review?
[06:58] <StevenK> His doesn't do the clean-up that mine does
[06:58] <StevenK> (And I'm all for making tests shorter)
[07:01] <StevenK> lifeless: And I already spoke to Edwin about it in -reviews
[07:04] <lifeless> so InitialiseDistroSeries was the helper?
[07:05] <StevenK> lifeless: The helper removed was _create_distroseries()
[07:05] <lifeless> StevenK: does it work?
[07:06] <StevenK> lifeless: Yes, I verified the test failed before fixing it, and that it passed after fixing it.
[07:38] <LPCIBot> Project devel build (96): STILL FAILING in 3 hr 25 min: https://hudson.wedontsleep.org/job/devel/96/
[07:38] <LPCIBot> * Launchpad Patch Queue Manager: [r=EdwinGrubbs][ui=none][bug 645702] Forward small messages to the
[07:38] <LPCIBot> moderation queue.
[07:38] <_mup_> Bug #645702: oops in holdMessage storing large message  <mailing-lists> <oops> <Launchpad Registry:Fix Committed by sinzui> <https://launchpad.net/bugs/645702>
[07:38] <LPCIBot> * Launchpad Patch Queue Manager: [r=thumper][ui=none][bug=652626] Upgrade windmill from r1440 to r1544
[07:38] <LPCIBot> to fix an issue preventing some new launchpad tests from running
[07:38] <wgrant> Botwar!
[07:38] <StevenK> Haha
[07:38] <spm> don't encourage them!
[07:39] <wgrant> What's with those utf8 failures?
[07:39] <StevenK> Mmmm. The SCM messages are not so handy
[07:42] <poolie> do i need to mark a bug fixreleased after qa, or just qa-ok?
[07:42] <poolie> does a bot do the former?
[07:42] <wgrant> poolie: Just qa-ok
[07:43] <poolie> great, bug
[07:43] <wgrant> Fix Released should only happen once it's on prod.
[07:43] <poolie> bug 615740 is done then
[07:43] <_mup_> Bug #615740: test_on_merge.py doesn't handle eintr <qa-ok> <Launchpad Foundations:Fix Committed by mbp> <https://launchpad.net/bugs/615740>
[07:44] <wgrant> Parts of NMAF look far too much like are an initial hacked-together implementation that was meant to be immediately followed by a proper one.
[07:44] <wgrant> Hacks hacks hacks.
[07:44] <wgrant> EVERYWHERE.
[08:24] <LPCIBot> Project db-devel build (55): STILL FAILING in 3 hr 53 min: https://hudson.wedontsleep.org/job/db-devel/55/
[08:53] <adeuring> good morning
[09:01] <mrevell> Hallo
[09:01] <wgrant> Hullo.
[09:01] <poolie> lp is readonly? no warning? ffs.
[09:02] <wgrant> It was on identi.ca.
[09:02] <wgrant> And the blog.
[09:02] <wgrant> But no in-app warning that I saw.
[09:02] <poolie> tweeting 17h in advance is kind of missing the point of the medium
[09:02] <wgrant> Heh.
[09:03] <poolie> i'll do it now
[09:16] <wgrant> bigjools: Sorry I missed your ping last night; I'd left about three minutes earlier.
[09:18] <bigjools> nae bother
[09:19] <wgrant> I believe the CPs are done?
[09:19] <bigjools> yes
[09:19] <wgrant> Phew.
[09:19] <bigjools> although my fixit query didn't work, I need to look at it again
[09:19] <wgrant> What was the query?
[09:20] <bigjools> http://pastebin.ubuntu.com/507347/
[09:20] <bigjools> we cancelled it after a couple of hours :/
[09:20] <wgrant> Ah, that kind of not working.
[09:21] <wgrant> What if you just do the usual 2.5-minute SELECT into a temp table, then UPDATE from that?
[09:22] <wgrant> Also, dateesuperseded.
[09:22] <wgrant> You're not unsetting that.
[09:22] <bigjools> ah true
[09:22] <bigjools> yeah I'll do the extra temp table
[09:23] <wgrant> You might also want to check datepublished IS NOT NULL
[09:23] <wgrant> (since it's possible that it superseded a Pending pub)
[09:24] <wgrant> Setting that to Published would be confusing, since it would leave a file missing from disk, but it wouldn't really break anything.
[09:24] <bigjools> hmmm yes
[09:24] <allenap> Staging was timing out on pillar pages yesterday, same today. Is this a known problem, or is there some nastiness in db-stable?
[09:24] <bigjools> I hate our model
[09:24] <wgrant> I mean, it's unlikely, but possible.
[09:25] <wgrant> bigjools: Sometimes I wonder why status is explicit.
[09:25] <bigjools> wgrant: to help query performance I would guess
[09:25] <bigjools> I'd rather have more states
[09:25] <wgrant> More!?
[09:25] <bigjools> yes
[09:26] <bigjools> it's a farce at the moment - superseded, but then you also have to look at dateremoved to see if it's really gone, for example
[09:26] <wgrant> Was ArchiveRemovalRedesign before your time?
[09:27] <wgrant> I think it might have been.
[09:27] <bigjools> yes
[09:27] <wgrant> Back in the good old days we had Pending, Published, PendingRemoval, Removed.
[09:27] <wgrant> Then ArchiveRemovalRedesign introduced the three removal candidate states, and removed the explicit on-disk state.
[09:28] <wgrant> So we are now stuck half-way between having an explicit status field, and implying status from dates.
[09:28] <wgrant> I'm not sure if that was always the plan.
[09:28] <wgrant> Or if it only got taken half-way.
[09:28] <bigjools> exactly
[09:29] <wgrant> I guess removing Pending would make it pretty much sensible.
[09:31] <wgrant> Having Pending but not Removed is stupid.
[09:31] <wgrant> But having Published/Superseded/Deleted/Obsolete makes sense.
[10:03] <jml> hello...
[10:06] <bigjools> wgrant: ok I've fixed staging, let's check it out
[10:07] <wgrant> The publication which alerted me to everything is fixed.
[10:07] <wgrant> That is encouraging.
[10:08] <bigjools> hurray
[10:08] <wgrant> That leaves no borked pubs in the primary archive?
[10:08] <bigjools> I hope so
[10:11] <bigjools> we're down to 20k rows that match the first query
[10:12] <wgrant> ie. the first temporary table containing all supersed arch-indep pubs since 2010-08-09?
[10:13] <bigjools> yes
[10:14] <bigjools> shockingly the 2nd query now returns zero :)
[10:14] <wgrant> I hope that's the one with dateremoved IS NULL
[10:15] <bigjools> yes
[10:24] <jml> anyone fixing the test failure in devel?
[10:25] <jml> or the one in db-devel, for that matter.
[10:25] <wgrant> StevenK had a branch for the IDS db-devel failure.
[10:25] <wgrant> Not sure about devel.
[10:25] <jml> wgrant: thanks.
[10:26] <jml> I've forced a rebuild of both db-lp buildslaves
[10:26] <jml> I guess I'll fix devel
[10:27] <StevenK> jml: I have a branch for devel, I was waiting for codehosting
[10:27] <StevenK> db-devel is in buildbot now
[10:27] <jml> StevenK: oh cool. the test_remote failures?
[10:27] <StevenK> jml: Yes
[10:27] <jml> StevenK: yeah, but buildbot died :\
[10:27] <jml> StevenK: sweet. may I see the merge?
[10:27] <StevenK> jml: Pushing it now
[10:28] <jml> StevenK: thanks.
[10:28] <wgrant> Oh, so Hudson wasn't on crack? Those were real failures?
[10:28] <jml> that reminds me.
[10:28] <jml> time to run the full test suite against stable & db-stable to see if there's anything else to be done
[10:31] <StevenK> jml: https://code.edge.launchpad.net/~stevenk/launchpad/fix-ec2test-utf8/+merge/37831
[10:32] <jml> looking
[10:32] <StevenK> jml: But that looks a lot bigger than what I had locally ..
[10:32] <jml> yeah.
[10:32] <jml> StevenK: it also looks suspiciously like mars's branch.
[10:32] <StevenK> jml: Yes ...
[10:33] <jml> StevenK: why is that? I thought that mars's fix had already landed...
[10:33] <wgrant> Wrong target...
[10:33] <StevenK> So did I
[10:33] <jml> wgrant: ta
[10:34] <jml> StevenK: ok. get the right diff & we'll figure out what's making this more interesting than it needs to be.
[10:40] <wgrant> Hm.
[10:40] <wgrant> We can now kill 2.5 off, can't we?
[10:40] <wgrant> Since wildcherry no longer fails.
[10:44] <wgrant> !@!!@!
[10:44] <wgrant> I just had a branch fail EC2 for the fifth time.
[10:44] <wgrant> Each time with a different error.
[10:44] <wgrant> Grrr.
[10:45] <jml> wgrant: I'm sorry.
[10:46] <jml> wgrant: lifeless is going to make it better.
[10:46] <wgrant> Heh.
[10:46] <jml> wgrant: until then, can I retry your branch for you.
[10:46] <wgrant> jml: devel's still broken, isn't it?
[10:46] <jml> (also, what's the deal with this paramiko error)
[10:46] <jml> wgrant: I'll run it against stable
[10:46] <jml> of course
[10:47] <jml> stable might be broken
[10:47] <wgrant> Heh.
[10:47] <wgrant> Yes...
[10:47] <wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/bug-629921-packages-empty-filter/+merge/37339
[10:48] <StevenK> jml: I'm not sure why that diff is so wrong
[10:48] <wgrant> StevenK: Targetted at lp:launchpad.
[10:48] <wgrant> And db-devel is missing three devel revs.
[10:48] <jml> StevenK: it's targeted to db-devel rather than devel.
[10:48] <StevenK> Oh, ...
[10:50] <StevenK> jml: https://code.edge.launchpad.net/~stevenk/launchpad/fix-ec2test-utf8/+merge/37832
[10:50] <StevenK> (That's what I get for filing MPs while on the phone to bigjools)
[10:50] <jml> StevenK: uhh ok.
[10:51] <jml> StevenK: do those tests pass locally for you?
[10:51] <StevenK> jml: Yup
[10:51] <jml> hmm.
[10:51] <jml> I suspect platform variation. mars changed the 'utf-8' to 'utf8' to fix a test failure
[10:51]  * jml tries
[10:52] <jml> anyone getting paramiko errors? http://paste.ubuntu.com/507903/
[10:52] <StevenK> Oh, are you kidding me? Now it wants utf8, rather than utf-8
[10:53] <jml> yeah. let me look at the tests.
[10:53] <bigjools> wgrant: I'm going to run that fixit query in an hour or so, I think it's ok unless you have any further misgivings?
[10:53] <jml> I reckon we should relax the constraint somehow.
[10:53] <wgrant> bigjools: pastebin pls.
[10:53] <wgrant> Just to be safe.
[10:54] <jml> StevenK: ok. here's what we should do.
[10:54] <wgrant> "charset=utf8" is wrong, though.
[10:54] <wgrant> Anything that wants that is broken.
[10:55] <jml> StevenK: split body['Content-Type'] by ';', assert that the first part is 'text/plain'
[10:55] <jml> StevenK: don't care about the second part.
[10:56] <bigjools> wgrant: http://pastebin.ubuntu.com/507877/
[10:56]  * wgrant WTFs at the differing theme between paste.ubuntu.com and pastebin.ubuntu.com
[10:56] <jml> wgrant: for this, we just don't care. if people start having encoding issues with their ec2 mail then we'll worry then.
[10:58] <wgrant> bigjools: +1 doit.
[11:00] <StevenK> jml: MP updated
[11:00] <jml> StevenK: thanks.
[11:00] <jml> StevenK: have you run the tests locally?
[11:00] <StevenK> Yes
[11:01] <StevenK> bin/test -vv -m devscripts -t test_remote is happy
[11:02] <jml> StevenK: humour an old man, run bin/test -vv devscripts
[11:02] <StevenK> ... Aren't you younger than me?
[11:02] <StevenK> jml: Ran 146 tests with 0 failures and 0 errors in 15.604 seconds.
[11:03] <wgrant> Almost 10 tests a second? What sorcery is this?
[11:03] <StevenK> ... A fast machine?
[11:03] <StevenK> You should try it
[11:03] <wgrant> Ah, and no DB too, I guess.
[11:04] <jml> yeah. they are tests for the devscripts stuff
[11:04] <StevenK> wgrant: Only unittest layer, so quick
[11:04] <jml> actually the test_remote tests are quite slow because they make real branches
[11:08] <StevenK> jml: Should I land that as a testfix?
[11:08] <jml> StevenK: yes please
[11:08] <jml> StevenK: sorry for the delay
[11:08] <StevenK> jml: Do you want to stamp it?
[11:08] <jml> StevenK: sure.
[11:09] <jml> StevenK: done
[11:09] <jml> sorry about the delay. multitasking way too much.
[11:11] <StevenK> jml: Tis cool. I've tossed it at PQM
[11:27] <jml> no one knows anything about that paramiko failure
[11:28] <wgrant> Hm, that's an odd one.
[11:29] <jml> yeah. I haven't sat down to serious debugging yet. Want to flush out my mail queue first.
[11:54] <bigjools> wgrant: production fixed
[11:55] <wgrant> bigjools: Looks good, thanks.
[11:55] <wgrant> can you grab counts of remaining broken publications?
[11:56] <bigjools> yeah already done a while ago
[11:59] <deryck> Morning, all.
[12:06] <LPCIBot> Project db-devel build (56): STILL FAILING in 3 hr 42 min: https://hudson.wedontsleep.org/job/db-devel/56/
[12:06] <LPCIBot> Launchpad Patch Queue Manager: [testfix][r=lifeless][ui=none][no-qa] Fix the InitialiseDistroSeries
[12:06] <LPCIBot> test for disabled DASes.
[12:08] <bigjools> funk6
[12:08] <bigjools> err funky, even
[12:12] <wgrant> jml: Did you end up sending my branch off?
[12:12] <wgrant> It may have some hope..
[12:13] <bigjools> wgrant: can we talk about your bug-655614-disabled-arch-indices branch
[12:13] <wgrant> bigjools: I opened that 30 seconds ago and was about to ask you the same thing.
[12:14] <bigjools> :)
[12:14] <wgrant> It's not so much a branch as a set of a few patches that we might want bits of.
[12:14] <bigjools> r9787 is confusing me
[12:14] <wgrant> It's probably too revolting to land (but no worse than parts of the existing code :/)
[12:15] <wgrant> Hm?
[12:15] <danilos> henninge, so, in what sense does +translations on a distroseries fail?
[12:16] <wgrant> bigjools: I removed a duplicate loop and added an arch.enabled guard. Previously it was looping across the archs once to publish indices, and again to request Release files.
[12:16] <bigjools> wgrant: why the changes other than the .enabled check?
[12:16] <bigjools> ah
[12:16] <wgrant> It was that or add the check twice.
[12:17] <bigjools> got it
[12:17] <bigjools> is it all tested?
[12:18] <wgrant> 9788 has some quick partial tests, but they're not thorough or pretty.
[12:18] <bigjools> not series.getDistroArchSeries(architecture[7:]).enabled):
[12:18] <bigjools> eeeurrrrghh
[12:18] <wgrant> bigjools: I stole the architecture[7:] from existing code!
[12:18] <bigjools> I know :(
[12:18] <wgrant> I originally did .split('-')[0], but decided to go with the... preferred method.
[12:19] <henninge> danilos: on <a tal:attributes="href context/menu:navigation/templates/url">
[12:19]  * bigjools puts fingers in ears and goes blahblahblah
[12:19] <henninge> danilos: 'templates' does not exist
[12:20] <wgrant> bigjools: I have formulated a plan to remove all that stupidity, but it will require a bit of a-f disentanglement.
[12:20] <wgrant> So it can't be done quickly.
[12:20] <jml> wgrant: yes
[12:20] <wgrant> jml: Great, thanks.
[12:20] <henninge> danilos: that's when rendering DistroSeriesView.
[12:21] <jml> StevenK: build failure just sent to the list
[12:21] <bigjools> wgrant: if you get this branch finished I will run it on dogfood while you get it reviewed
[12:21] <henninge> danilos: that's the test that's failing, actually the last "test_" method im the file.
[12:21] <henninge> danilos: http://pastebin.ubuntu.com/507871/
[12:21] <wgrant> bigjools: I'll write the tests properly now it's no longer 3am.
[12:22] <StevenK> jml: That's lp, not lucid_lp
[12:22] <wgrant> But I think it's good, so please try on DF, yes.
[12:22] <jml> StevenK: I'm a little bit behind ... does lp build slave still matter?
[12:23] <wgrant> wildcherry was the end of 2.5, I believe.
[12:23] <wgrant> So we may be safe.
[12:23] <henninge> danilos: read the backscroll on #lp-reviews for more detail ;-)
[12:23] <StevenK> We're all on lucid now, I think
[12:24] <bigjools> wgrant: :)
[12:24] <henninge> danilos: bac has ended his day in defeat, so it is not super-urgent atm.
[12:25] <danilos> henninge, fwiw, I can simply create a distribution and distroseries using factory methods and browse to +translations on it
[12:25] <henninge> danilos: that's odd. How do you do that exactly?
[12:26] <henninge> (I know how to use the factory methods)
[12:26] <wgrant> bigjools: I'd test PPA and primary archives both with and without active publications in the disabled DASes. Check that the DAS' directories aren't recreated, and confirm that the series' Release doesn't include those arches.
[12:26] <wgrant> I will return in 20.
[12:27] <danilos> henninge, in 'make harness' using http://paste.ubuntu.com/507948/
[12:27] <bigjools> wgrant: yup
[12:27] <danilos> henninge, oh, if you know how to use factory methods, perhaps you were asking how do I browse to it? :P
[12:27] <henninge> danilos: exactly ;)
[12:28] <danilos> henninge, well, I open a web browser and go and look at it :)
[12:28] <henninge> danilos: I was not sure which changs to the db are presereved after make harness.
[12:28] <henninge> danilos: ok, simply 'make run'
[12:28] <danilos> henninge, all changes that you've committed are preserved
[12:28] <danilos> henninge, right, but I do that even before 'make harness': it's basically like two appservers talking to the same DB
[12:29] <henninge> I see
[12:29] <danilos> henninge, I've already looked at that test for bac, but now that I think about it, it's probably a missing commit somewhere
[12:29] <danilos> or at least a .sync()
[12:31] <henninge> danilos: we were also wondering why DistroSeriesTranslationsMenu.templates is @enabled_with_permission('launchpad.Edit') when still it is shown to everybody.
[12:32] <danilos> henninge, probably because it's not useful to anybody else all that much
[12:32] <danilos> henninge, i.e. perhaps shouldn't be like that
[12:32] <henninge> danilos: no, I am saying that the link (and the page) is shown to unauthorized users, too.
[12:33] <henninge> danilos: *although* it is @enabled_with_permission('launchpad.Edit') ...
[12:33] <danilos> henninge, oh, then the decorator needs to go
[12:33] <henninge> danilos: you mean it has no function any more?
[12:33] <henninge> danilos: btw, a commit makes the test pass.
[12:33] <henninge> ;-)
[12:34] <henninge> danilos: where would the sync() go?
[12:34] <danilos> henninge, where the commit is, on the object that needs syncing (sometimes a sync() is not enough, but you could try self.distroseries.sync())
[12:35] <danilos> henninge, that also means that all the other tests (for non-LAUNCHPAD usage values) pass by accident :)
[12:35] <bigjools> sync() is useless now I thought?
[12:36] <jml> indeed
[12:36] <bigjools> store.flush() FTW
[12:36] <henninge> good to know ;)
[12:36] <henninge> danilos: A commit does *not* help. btw. I had forgotten that I had commented out the failing parts of the template ...
[12:36] <henninge> :(
[12:37] <danilos> bigjools, ah, right, thanks :)
[12:37] <danilos> henninge, sorry to hear that
[12:37] <danilos> henninge, does removing the permissions decorator on the property help?
[12:37] <henninge> nope
[12:38] <henninge> danilos: if I comment out the context/menu:navigation/templates line in the tmplate
[12:38] <henninge> danilos: it fails on context/menu:navigation/langpacks
[12:38] <henninge> ...
[12:38] <henninge> danilos: My suspicion is it has the wrong menu. But why and how do I prove that?
[12:39] <danilos> henninge, right, we should just get rid of the context/menu:navigation use anyway, but... that doesn't help with this branch
[12:39] <danilos> henninge, hum, "wrong" menu is a potential issue if the entire page is included into distribution:+translations, but I am pretty sure it isn't
[12:43] <danilos> henninge, fwiw, I'd suggest trying setting a breakpoint and going through the test with pdb (or trying it manually in 'make harness')
[12:45] <jml> bigjools: so you've got the buildd-slavescanner work now?
[12:45] <jml> bigjools: I can remove it from my todo?
[12:45] <bigjools> jml: I'll sort it, yes
[12:45] <jml> bigjools: ta
[12:46] <bigjools> jml: btw have you been playing Uncharted2 then? :-)
[12:46]  * wgrant returns.
[12:47] <jml> bigjools: not recently. and actually it was mostly watching two of my flatmates play it
[12:48] <bigjools> F1 2010 is keeping me up way too late
[13:09] <wgrant> bigjools: Hm, the Release update didn't work?
[13:09] <wgrant> Or have you just deleted but not republished yet?
[13:10] <bigjools> wgrant: still trying to get the f***ing publisher to do something
[13:10] <wgrant> Heh.
[13:10] <wgrant> ♥ dogfood
[13:11] <bigjools> I've got a pending publication but p-d ignores it
[13:11] <wgrant> Pending publications, or pending uploads?
[13:12] <wgrant> It's easy to forget p-a...
[13:12] <bigjools> already ran p-a
[13:12] <bigjools> there's a pending source and binary now
[13:12] <wgrant> So even phase A doesn't see them?
[13:13] <bigjools> nup
[13:13] <bigjools> this is w/o your patch too
[13:13] <wgrant> Yeah. I didn't touch phase A.
[13:13] <wgrant> Come on DF... show me your queue.
[13:14] <wgrant> Uh, is DF's appserver hung?
[13:14] <wgrant> There is little response.
[13:15] <bigjools> +queue?
[13:15] <wgrant> Ah, there we go.
[13:15]  * bigjools restarts DF
[13:15] <wgrant> Yeah, that.
[13:15] <wgrant> It's alive now.
[13:15] <bigjools> +queue is slow slow slow
[13:15] <wgrant> It was going for well over a minute.
[13:15] <wgrant> Which should have timed out.
[13:15] <wgrant> But it's rendered now.
[13:16] <bigjools> bizarrely your branch conflicts in lib/canonical/launchpad/browser/launchpad.py
[13:16] <wgrant> Mine is based on production-devel.
[13:16] <wgrant> So that's possible, I suppose.
[13:17] <bigjools> don't do that
[13:17] <bigjools> not yet anyway
[13:17] <bigjools> where did you branch from?
[13:18] <wgrant> A production-devel branch. I'll rebase on devel. Gimme a sec.
[13:19] <bigjools> ok now I'm getting hacked off, why is it not publishing
[13:19] <wgrant> Well, there is no appserver running. Is there a librarian? p-d needs one...
[13:24] <wgrant> bigjools: That branch is now based on devel.
[13:24] <bigjools> I have to run a db patch on DF
[13:25] <wgrant> Yay.
[13:25] <bigjools> which is always painful
[13:25] <wgrant> It's not the branchrevision one, I hope.
[13:25] <bigjools> HWSubmissionDevice getting a new index - ffs
[13:25]  * bigjools kills it
[13:27] <bigjools> and 2 others
[13:28] <jml> wgrant: btw, I've seen a thread isolation error in the layers tests in your branch.
[13:28] <wgrant> .... #6.
[13:31] <jml> wgrant: it might not fail
[13:32] <jml> layer tests are hella weird
[13:32] <wgrant> Hm, Ok.
[13:33] <bigjools> wgrant: of course it would have helped to have publish=True for the main archive
[13:33] <wgrant> bigjools: Uh, DAS.enabled is in production-devel but not devel?
[13:33] <wgrant> bigjools: Haha.
[13:33] <bigjools> wgrant: yes, use db-devel
[13:34] <wgrant> Well, that's a bit special.
[13:34] <bigjools> it's because of the late branch for the last rollout
[13:34] <bigjools> the DB is patched in prod without a patch file in devel
[13:34] <wgrant> Ah, I thought that did make it into devel anyway.
[13:34] <wgrant> I recall the late patch.
[13:35] <bigjools> and now I am going to get some food while the publisher runs
[13:35] <bigjools> we could do with using your domination speedup thing
[13:35] <bigjools> back in 30 mins
[13:36] <wgrant> I'm going to see if I can remove the temp table first.
[13:36] <wgrant> The whole going behind Storm's back thing makes me a bit wary of duplicating it.
[14:03] <jcsackett> henninge, danilos: hi.
[14:03] <danilos> jcsackett, hi
[14:04] <jcsackett> danilos: i have two more bugs in translations (filed by registry) that i would like input on, if you have time.
[14:04] <jcsackett> bug 652296 and bug 652301
[14:04] <_mup_> Bug #652296: distribution translations front page contradicts itself for owner <bridging-the-gap> <confusing-ui> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/652296>
[14:04] <_mup_> Bug #652301: non-soyuz distro has contradictory involvement portlet <bridging-the-gap> <confusing-ui> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/652301>
[14:04] <jcsackett> i think the one about distribution contradicting itself falls into the category of things you guys are working on as part of other bugs, and the bug can be discarded. danilos, do you agree?
[14:08] <rockstar> abentley, hi
[14:08] <abentley> rockstar: hi.
[14:09] <rockstar> abentley, so, in my merge-queues-db branch, I deleted the tests because I needed the tests to run.  thumper and I had come to the conclusion that making the db patch as small as possible was a good idea.  The actual model code gets deleted in the next pipe.
[14:10] <abentley> rockstar: does the model code work?
[14:10] <rockstar> abentley, not without the tables underneath it, no.
[14:11] <rockstar> abentley, but there are imports and such that I didn't want to also have to go chase just to get the db-patch in.
[14:11] <rockstar> (although I have some failing tests which may force me to do that)
[14:12] <abentley> rockstar: so you're reducing the test coverage in order to allow some code to be broken?
[14:12] <rockstar> abentley, no, just trying to keep the diff manageable.
[14:13] <abentley> rockstar: you're reducing the test coverage in order to allow some code to be broken so that the diff is manageable?
[14:13] <rockstar> abentley, yes.  Code that isn't used (and never was) is now broken in this branch.  It is fixed in the next one.
[14:14] <abentley> rockstar: while there may be some exceptions, I don't think this is a good general policy.
[14:15] <abentley> rockstar: would it have been possible to remove the model code and tests first, then do the db patch?
[14:15] <rockstar> abentley, no, not at all.  I am contending though, that this is probably an okay exception.  As far as I'm concerned, the current merge queue code is nothing but technical debt.
[14:15] <rockstar> abentley, I guess, but in this next branch, I'm replacing the model code with the correct code.
[14:18] <rockstar> abentley, this is really not ideal.  Instead of creating new functionality, I get to remove old, half-baked functionality first.  By today's policy, the current branch merge queue code never would have been landed.
[14:18] <abentley> rockstar: all of this doesn't actually matter because you won't be landing this branch by itself, right?
[14:19] <rockstar> abentley, well, it's getting to the point that I need to land it by itself, because PQM is closing.
[14:20] <rockstar> abentley, but there are still broken tests, so I may need to delete it anyway.
[14:21] <abentley> rockstar: I understand that you're frustrated.  I'm sorry to be sticky about this.
[14:21] <rockstar> abentley, no, I'm not frustrated, just explaining.
[14:22] <rockstar> abentley, or rather, I'm frustrated that we have old stale code just festering in Launchpad.
[14:23] <abentley> rockstar: I'll approve this, but please try to avoid reducing test coverage in the future.
[14:23] <rockstar> abentley, yeah, that's the last thing I want to do.
[14:23]  * rockstar likes tests.
[14:24] <rockstar> abentley, it's still quite possible that I'll need to delete the models in this pipe, but I can't get the Librarian to run anymore to find out.
[14:29] <allenap> adeuring, gmb: Do either of you have time to review a branch? It's mostly a search-n-replace job. https://code.edge.launchpad.net/~allenap/launchpad/subs-for-bugtask-bug-656194/+merge/37835
[14:29] <adeuring> allenap: I'll do it
[14:29] <allenap> adeuring: Thanks.
[14:33] <wgrant> bigjools: The publisher is *still* not done?
[14:33] <wgrant> Or did I explode it?
[14:33] <bigjools> wgrant: dogfood is slow at publishing
[14:33] <wgrant> .... apparently.
[14:33] <bigjools> the "Calculating binary filelist." part is REALLY slow
[14:33] <wgrant> Anyway, I have some nonawful tests now.
[14:34] <bigjools> I expect it'll be another hour yet
[14:38]  * rockstar reboots
[14:46] <wgrant> bigjools: I wonder how it can be so bad. Maverick should have fewer than 10000 binary lines.
[14:46] <wgrant> Er, 100000.
[14:46] <wgrant> Still not many.
[14:49] <wgrant> bigjools: https://code.edge.launchpad.net/~wgrant/launchpad/bug-655614-disabled-arch-indices/+merge/37849 <-- besides the greasy stolen hack, does it look OK?
[14:49] <wgrant> I will throw it at a reviewer if you have no immediate objection.
[14:50] <wgrant> The tests now verify that the indices aren't created by either publisher, that the arch directory isn't created, and that it's not in the serise' Release.
[14:50] <wgrant> That should be everything.
[14:51] <bigjools> wgrant: can you put the enabled flag as a param to makeDistroArchSeries
[14:52] <wgrant> bigjools: Good point.
[15:08] <wgrant> jml: Failure #6!
[15:08] <wgrant> Awesome.
[15:08] <wgrant> This is a record for me.
[15:09] <jml> wgrant: yeah.  :(
[15:09] <jml> wgrant: and that was against stable too.
[15:09] <wgrant> …..
[15:09] <wgrant> Well then.
[15:09] <jml> wgrant: which is no longer a known good branch :(
[15:10] <jml> wgrant: my run against stable didn't seem to work in the way I expected.
[15:10] <jml> as in, my test run of just stable nothing merged in.
[15:10] <wgrant> How do you mean?
[15:12] <jml> well, it only ran devel
[15:12] <wgrant> Hm, convenient.
[15:13] <jml> so, going to try again
[15:13] <jml> also, running those failing tests on my stable branch
[15:15] <jml> ffs.
[15:15] <jml> make schema :(
[15:22] <jcsackett> danilos: any thoughts regarding those bugs?
[15:25] <flacoste> mars: what's the status of the failing tests on the stable branch?
[15:25] <mars> flacoste, jml would know.  StevenK had a fix that was in buildbot
[15:26] <danilos> jcsackett, sorry, it usually useful to ping me every time or I can easily miss out on a followup to a discussion (IRC is famous for having multiple conversations over multiple channels all happening at the same time :)
[15:26] <flacoste> mars: do we know why that happened?
[15:26] <danilos> jcsackett, I am taking a look now
[15:26] <tyarusso> wgrant: Maybe.  I appear to have gotten both c-i-p and lp to run without errors.  Still no idea how to actually connect them to each other such that a "Register" link appears on LP.
[15:26] <jcsackett> danilos: ah dig, sorry for not pinging you on all that. :-)
[15:27] <flacoste> mars: and the fact that it landed in buildbot doesn't mean it's fixed, given that the failures weren't noticed by the builder in the first place
[15:27] <mars> flacoste, the accute symptom appears to be a difference between how platforms handle charset encodings: some say the mail was written as 'utf8', other say 'utf-8', and others say 'quote-printable'
[15:27] <jml> flacoste, mars: see the mail I just sent
[15:27] <wgrant> tyarusso: Grep around in the LP configs for 'testopenid.launchpad.dev', and change it to your c-i-p domain.
[15:27] <jml> mars: it's deeper than that
[15:27] <wgrant> tyarusso: But I am asleep.
[15:28] <mars> jml, yep, hence the 'accute symptom' - stating that "This man died from blood loss!" while ignoring the stab wounds
[15:29] <danilos> jcsackett, I agree about bug 652296, we can probably wontfix it
[15:29] <_mup_> Bug #652296: distribution translations front page contradicts itself for owner <bridging-the-gap> <confusing-ui> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/652296>
[15:29] <jml> mars: uhh, to stretch the analogy, blood loss, internal bruising and liver collapse
[15:29] <jml> mars: there are two other failures that have nothing to do with encoding
[15:29] <jcsackett> danilos: i cannot express how much i wanted to hear that. :-)
[15:29] <mars> jml, great :(
[15:30] <jcsackett> danilos: the other one is less a "can we wontfix this" and more a "there are plans for dealing with distros like this in the future, what do you want to do now?" sort of thing.
[15:30] <jcsackett> which is a far more complicated question.
[15:30] <flacoste> mars,jml: can't these failures be not noticed because of the subunit format failure we saw earlier?
[15:31] <jml> flacoste: that would be my best guess. I haven't done *any* analysis though. my first step was trying to measure the extent of the problem...
[15:31] <flacoste> mars: given that these failures are reproducible locally, can we do a binary search to find the revision at which point they started failing and went unnoticed in buildbot?
[15:31] <jml> flacoste: still waiting on db-stable results
[15:31] <danilos> jcsackett, yeah, the other one (bug 652301) is useful in itself and should probably stay... I'd say leave it open and we'll worry about it (i.e. I don't think it's got anything to do with the bridging the gap theme)
[15:31] <_mup_> Bug #652301: non-soyuz distro has contradictory involvement portlet <bridging-the-gap> <confusing-ui> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/652301>
[15:32] <mars> flacoste, yes, that would work
[15:32] <jcsackett> danilos: okay, thanks. i'll remove the briding-the-gap tag and take it out of registry's backlog.
[15:32] <sinzui> \o/
[15:32] <flacoste> mars: can you take care of that analysis, pretty please?
[15:32] <danilos> jcsackett, thanks
[15:33] <mars> flacoste, sure :)
[15:35] <flacoste> thanks mars
[15:36] <EdwinGrubbs> rockstar: ping
[15:37] <rockstar> EdwinGrubbs, hi.
[15:38] <EdwinGrubbs> rockstar: On the off chance that you aren't busy, can you look at the launchpad-code bugs that are still in qa-needstesting?
[15:39] <rockstar> EdwinGrubbs, I can.  I'm about to head out for a second.
[15:48] <LPCIBot> Project devel build (97): STILL FAILING in 3 hr 52 min: https://hudson.wedontsleep.org/job/devel/97/
[15:56]  * rockstar afks
[15:56] <gmb> jml: I cannot get xx-person-subscriptions to fail locally in stable. Neither can jcsackett, from what I understand.
[15:56] <gmb> So why it's failing in buildbot I don't know.
[15:56] <jml> gmb: interesting.
[15:57] <jml> gmb: it fails for me.
[15:57] <jcsackett> gmb: that's right. i run xx-person-subscriptions on ec2, it fails as you demonstrated. i run it locally, it works (as the code currently is).
[15:57] <stub> xx-person-subscriptions.txt looks like a data ordering issue - the sort that occasionally pops up with sampledata and PG updates.
[15:57]  * gmb `make schema`s
[15:57]  * jcsackett groans and also makes schema.
[15:58] <stub> I've just emailed, but summary is I think +subscriptions displays whichever bugtask it finds 'first', but doesn't tell the database what 'first' means and we get an arbitrary bugtask.
[15:58] <gmb> ARGH.
[15:58] <jml> actually, a thing we should do is look at the buildbot logs, see if the failures are in the output but not detected...
[15:58] <gmb> stub: So it doesn't use bug.default_bugtask.
[15:58] <gmb> And I'd just assumed it did.
[15:58] <gmb> Arseholes.
[15:59]  * stub bets switching to default_bugtask causes a performance problem ;)
[15:59] <gmb> bdmurray: So, re: your email is it actually an ordering issue as you suggest or is it the issue that stub suggested above.
[16:00] <gmb> stub: Shouldn't any more.
[16:00] <gmb> I fixed that.
[16:00] <gmb>     def default_bugtask(self):
[16:00] <gmb>         """See `IBug`."""
[16:00] <gmb>         return Store.of(self).find(
[16:00] <gmb>             BugTask, bug=self).order_by(BugTask.id).first()
[16:00] <stub> This is just my guess btw. I haven't looked at the code.
[16:01] <bdmurray> gmb: well the bugtasks could have different date_last_updated fields but I don't think the sample data should be changing ... right?
[16:02] <gmb> bdmurray: Well, no, but if we're just describing the subscriptions a user has why not just use default_bug_task?
[16:02] <bdmurray> gmb: that seems like a fine solution to me
[16:03] <gmb> bdmurray: Cool. Are you working on it now or should I put a branch together?
[16:03] <bdmurray> gmb: No, I'm not working on it now but I could be.
[16:04] <gmb> bdmurray: I'll take care of it since I'm in the code already.
[16:04] <bdmurray> gmb: okay, thanks!
[16:04] <gmb> np
[16:15] <stub> sorting by date_last_updated can be dangerous, as if you modify two bugtasks in the same transaction you get identical timestamps and the ordering is undetermined.
[16:44] <bigjools> yay postgres vuln
[16:47] <dobey> is lp taking a horrendously long time to rescan branches for anyone else?
[17:01] <maxb> The branch scanner was broken yesterday. Has it been fixed?
[17:02] <mars> abentley or rockstar, ^ ?
[17:03] <mars> if there is a problem, should it be listed in the channel topic?
[17:03] <abentley> maxb: I didn't hear there was a problem.
[17:04] <mars> dobey was asking too
[17:04] <maxb> The branch scanner was throwing SQL permission errors.
[17:05] <abentley> maxb: any oops ids?
[17:05]  * maxb hunts irclogs
[17:05] <mars> flacoste, jml, you are going to love this: revision 11634 is the culprit
[17:05] <jml> A wise man once said, All you need is love.
[17:05] <flacoste> mars: and what did this revision introduced?
[17:05] <mars> "Move read_transaction & write_transaction to lp.services."
[17:06]  * jml looks at the revision
[17:06] <flacoste> really!?!
[17:06] <mars> flacoste, jml, just to be clear, that is devel r11634
[17:07] <abentley> mars: (and also stable r11634)
[17:09] <maxb> the branch scanner issue was http://launchpadlibrarian.net/57189808/jR3X1uFDWYhXPet14K6N1hWzrkG.txt
[17:09] <flacoste> mars: that's the revision where the tests started failing? does it give also the explanation why buildbot didn't spot the failures?
[17:09] <jml> mars: test_remote passes on r11634 for me
[17:09] <mars> fails here
[17:09] <jml> interesting
[17:09] <maxb> http://irclogs.ubuntu.com/2010/10/06/%23launchpad.html#t22:27
[17:10] <jml> are we looking at a config issue or a timing issue or what
[17:10] <mars> jml, well, I figured it must have passed for you - how else would you have done your TDD loop?
[17:10] <jml> mars: to be clear, test_remote does not work for me with tip of stable
[17:11] <jml> mars: and that revision doesn't do anything with devscripts
[17:11] <mars> ... jml, does that include StevenK's fix?
[17:11] <abentley> maxb: ack
[17:11] <jml> mars: no, not including StevenK's fix
[17:12] <mars> jml, I did this (sandboxed devel setup): $ bzr branch -r 11634 devel test && cd test && bzr checkout && utilities/link-external-sourcecode ../devel && make && bin/test -cv devscripts.ec2test.tests.test_remote
[17:12] <mars> jml, are you running Maverick or Lucid?
[17:13] <abentley> maxb: AFAICT, the scanner is running normally on most branches.  It appears to be a problem for this particular branch.
[17:14] <jml> mars: Maverick
[17:14] <mars> same
[17:14] <jml> hmm.
[17:14] <mars> flacoste, does it fail for you?
[17:14] <mars> a larger sample would really help here
[17:16] <mars> I'll run it on my Lucid laptop
[17:16] <jml> mars: I did bzr revert -r 11634... I'll try a fresh branch just in case
[17:16] <allenap> bdmurray: Btw, I also tried to investigate bug 654585, but was prevented by staging timing-out all the time.
[17:16] <_mup_> Bug #654585: Line break stripped from bug reported acknowledgement <Launchpad Bugs:Incomplete> <https://launchpad.net/bugs/654585>
[17:18] <jml> mars: yeah. fails for me.
[17:18] <jml> mars: trying again, and then with previous revision
[17:21] <abentley> maxb: this is bug 634451 and a fix was applied to production around 2010-09-12.  Apparently, it didn't stick.
[17:22] <_mup_> Bug #634451: launchpad code rescans failing <branch-scanner> <oops> <qa-ok> <Launchpad Bazaar Integration:Fix Released by thumper> <https://launchpad.net/bugs/634451>
[17:22] <flacoste> mars: what's the test i should run?
[17:22] <mars> flacoste, bin/test -cv devscripts.ec2test.tests.test_remote
[17:23] <bdmurray> allenap: you must have some ubuntu bug you could report ;-)
[17:23] <allenap> bdmurray: No, it's perfect :)
[17:24] <flacoste> mars: i cannot make that revision at all :-/
[17:24] <flacoste> mars: compile_templates fails
[17:24] <flacoste> ImportError: cannot import name SAFE_INSTRUCTIONS
[17:25] <mars> flacoste, on Lucid - strange.  Have you run 'apt-get update && apt-get install' recently?
[17:25] <mars> flacoste, and I assume you ran 'rocketfuel-get' to ensure sourcecode is up to date?
[17:25] <mars> flacoste, and this is in a fresh branch?
[17:26] <flacoste> it's a fresh branch
[17:26] <flacoste> i did update this week
[17:26] <flacoste> but i didn't run rocketfuel-get
[17:26] <flacoste> only updated the download cache
[17:26] <mars> ok, it is building on Lucid here
[17:26] <mars> but is is not finished yet
[17:29] <mars> flacoste, builds for me on Lucid
[17:29] <mars> and the tests fail
[17:29] <jml> mars: I can confirm tat revision introduces the bug
[17:30] <jml> that*
[17:30] <mars> ok, so we still have a "wtf" moment here though
[17:30] <mars> :)
[17:31] <mars> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/11634
[17:32] <dobey> hrmm
[17:32] <jml> mars: have you tried with the other tests?
[17:33] <mars> jml, no, I shall do so - they involved database stuff too?
[17:33] <jml> mars: umm... the xx-person-whatever thing?
[17:34] <flacoste> mars: still fails
[17:36] <mars> flacoste, you may want to talk to bigjools about using the vm builder to get a Maverick instance then
[17:36] <jml> mars: http://paste.ubuntu.com/508043/
[17:36] <flacoste> mars: so i cannot that revision
[17:37]  * flacoste needs to lunch
[17:37] <mars> ok
[17:37]  * jml meeting
[17:40] <abentley> maxb: I am trying to get an answer on whether the permissions have been fixed, but it's taking a while.
[17:47] <lvh> Hi :-)
[17:47] <lvh> What's the right place to make or discuss feature requests for lp?
[17:47] <lvh> I was just thinking it would be really awesome if merge requests had diffs that looked like bzr qdiff (side by side). A bit like rietveld.
[17:51] <mars> lvh, best file a bug with the request, or ask about the feature on the launchpad-dev mailing list.  For MPs specifically, you would likely end up talking to abentley or rockstar.
[18:09] <benji> I'm upgrading to Maverick and my LP tests are now erroring out with "ImportError: No module named mailman.monkeypatches.defaults"; anyone seen this before?
[18:10] <benji> nope, I've not done anything with that yet
[18:13] <benji> I just skimmed some KWallet stuff and it seems to be about the same design/complexity as the Gnome Keyring.
[18:13] <benji> oops, wrong chan
[18:17] <mars> benji, I have not checked - have you run rocketfuel-get, merged devel in the branch you are working on, and run 'make clean && make'?
[18:17] <benji> mars: nope; I'll do that.
[18:18] <benji> (well, I was running the tests on devel, but the make clean I haven't tried)
[18:18] <mars> bac or sinzui, ping, you both rebuilt your systems for maverick, correct?
[18:18] <sinzui> no, I upgraded
[18:19] <mars> ok, it was Brad then who did a rebuild
[18:29] <benji> mars: the make clean helped, but now I get a PG error; I tried this https://pastebin.canonical.com/38344/ but got the error you see there
[18:52] <dobey> mars, maxb, abentley: did you guys figure out anything with the branch rescans yet?
[18:53] <abentley> dobey: What I know so far is we already had this problem, it was fixed on production, and the database upgrade seems to have lost the fix.
[18:53] <abentley> dobey: so I am trying to get it re-applied.
[18:54] <abentley> dobey: it was bug 634451
[18:54] <_mup_> Bug #634451: launchpad code rescans failing <branch-scanner> <oops> <qa-ok> <Launchpad Bazaar Integration:Fix Released by thumper> <https://launchpad.net/bugs/634451>
[18:54] <dobey> abentley: ok, thanks.
[18:54] <mars> benji-lunch, looking
[18:55] <mars> benji-lunch, you need to open Synaptic or Update Manager and re-enable the launchpad PPA software source
[18:55] <mars> benji-lunch, the upgrade disables all third-party repos
[18:56] <mars> benji-lunch, then, after that, 'sudo apt-get update && sudo apt-get install'
[18:58] <mars> gary_poster, flacoste, how did the Python 2.6 upgrade go?  Can we kill the Hardy builders yet? :)
[18:58] <mars> err, database upgrade
[18:59] <gary_poster> mars, it went well; see my brief email to the list for remaining step.  yes, we can kill the Hardy builders, which is part of what I have in my RT for the last step.
[18:59] <mars> \o/
[18:59] <dobey> benji-lunch, mars: i think he meant s/install/upgrade/ for that second one. install without args won't do much :)
[18:59] <mars> thanks gary_poster.  It will be nice to see those mails stop
[18:59] <gary_poster> agreed
[19:00] <mars> dobey, I thought 'apt-get install' offered to install new versions of all of the upgradable packages?
[19:00] <mars> and that 'upgrade' did the base system
[19:00] <maxb> No, that's not how it works
[19:01] <dobey> upgrade installs new versions
[19:01] <maxb> AFAIK apt has no "just the base system" thingy at all
[19:01] <dobey> indeed
[19:02] <mars> so what was the apt command to upgrade Debian (or Ubuntu) to the next major version?
[19:02] <mars> do you have to explicitly tell it to do so, or does it just happen when the new version is released?
[19:02] <maxb> There is no single apt command for that
[19:03] <maxb> Ubuntu: Use the release-upgrader tool.
[19:03] <maxb> Debian: Follow the full instructions in the release notes
[19:05] <mars> Funny, I have been using Linux for more than 12 years, and never knew that
[19:08] <flacoste> mars: what was the name of a devscripts failing test?
[19:10] <mars> flacoste, test_remote
[19:10] <flacoste> mars: more specifically, there are a bunch of test_remote
[19:11] <flacoste> mars: i'm trying to assess if buildbot ran the failing tests successfully, it appears so
[19:11] <flacoste> mars: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/195/steps/shell_7/logs/stdio
[19:11] <mars> flacoste, bin/test -cv devscripts.ec2test.tests.test_remote
[19:11] <flacoste> mars: i can't reproduce
[19:11] <mars> hmmm
[19:11] <flacoste> mars: so i'm looking for something like a pastebin of the failing tests output
[19:11] <mars> that is not necessarily a bad thing
[19:12] <mars> ok
[19:12] <flacoste> mars: i can't reproduce because my env is not working, not because i don't have the error :-)
[19:12] <mars> oh :p
[19:12] <mars> oh, to have a pastebin grep
[19:14] <mars> flacoste, http://pastebin.ubuntu.com/508177/
[19:16] <flacoste> mars: thanks, these tests pass successfully on build 195
[19:16] <flacoste> so i think, this is an environmental thing
[19:16] <flacoste> diff between dev env and the builder env
[19:17] <mars> I can't think of how to debug that though
[19:18] <mars> would have to dig into the code to see where those variables are being generated
[19:18] <mars> and what the heck is with the revno that caused everything to break?  It does not look related
[19:28] <flacoste> not sure how much we should chase this up at this stage
[19:28] <flacoste> the utf-8, utf8 things might be due to a package update
[19:28] <flacoste> that isn't in the builder yet
[19:28] <flacoste> iow, these were all fragile tests
[19:29] <flacoste> are all tests passing in stable locally and buildbot now?
[19:29] <flacoste> as long as we have deltas between the dev / test / production environment, we'll suffer from fragile / env tests
[19:30] <lifeless> environment failures sure
[19:31] <lifeless> but tests should be isolated from the environment, OR, we should ask all devs to develop in $prod-target-vms
[19:31] <jml> we fixed the utf-8 / utf8 things
[19:32] <jml> there's no easy way to learn that it's env dependent
[19:46] <LPCIBot> Project devel build (98): STILL FAILING in 3 hr 50 min: https://hudson.wedontsleep.org/job/devel/98/
[19:48] <jcsackett> EdwinGrubbs: what time is PQM closing today? can't seem to find the email...
[19:49] <EdwinGrubbs> jcsackett: 22:00 UTC, so in 3 hours
[19:49] <jcsackett> thanks.
[19:56] <LPCIBot> Project db-devel build (57): STILL FAILING in 4 hr 8 min: https://hudson.wedontsleep.org/job/db-devel/57/
[20:07] <lifeless> off to a doctors visit, back in a few hours
[20:58] <mwhudson> jml: hey
[20:59] <mwhudson> jml: have you looked at the lp-service branch at all?
[21:14] <rockstar> sinzui, hi.
[21:14] <sinzui> hi rockstar
[21:15] <rockstar> sinzui, I wonder if you might be able to help me sort out some things with the account merger, or point me to someone who might.
[21:15] <sinzui> rockstar, does this related to login or passwords
[21:17] <rockstar> sinzui, it relates to how the table list gets generated for finding references to Person.id
[21:17] <rockstar> sinzui, it's somehow finding a table I dropped in this branch.
[21:17] <sinzui> interesting
[21:17] <sinzui> I do not know, but I want to know so you have my attention
[21:17] <sinzui> which table
[21:18] <rockstar> sinzui, branchmergerobot
[21:18] <sinzui> and you get merge errors because the master rule believes there is a condition we do not have a rule for?
[21:19] <rockstar> sinzui, I WAS getting errors for the table I created that referenced it.  Now I'm getting errors because it's trying to update a table that no longer exists.
[21:20] <sinzui> I wonder is make schema generates a no-no list for merge
[21:20] <rockstar> canonical.database.postgresql.listReferences seems to be returning branchmergerobot, which this branch drops.
[21:20]  * sinzui starts reading code
[21:20] <rockstar> sinzui, lp.registry.model.person:4004
[21:21] <rockstar> sinzui, somehow, in the references var, branchmergerobot is showing up.  I have no idea why, since the table is deleted.
[21:21] <sinzui> rockstar, I see 4004 as the the line that changes the user name
[21:22] <rockstar> sinzui, oh wait! It's not deleted, it's just moved to to_drop (since dropping it would break replication)
[21:22] <sinzui> oh that sucks
[21:22] <rockstar> Oh yeah, I had some local changes, so the lines wouldn't match up.
[21:23] <sinzui> listUniques or Handle all simple cases>
[21:23] <sinzui> ?
[21:27] <mwhudson> ow
[21:27] <mwhudson> is the fkey constraint still on the table when it's in to_drop?
[21:27] <sinzui> rockstar, I think listReferences needs to verify the table is not going to be dropped, or merge needs to filter that list by checking some table/column really needs updating
[21:28] <rockstar> mwhudson, no, the column that references it is also dropped.
[21:28] <mwhudson> oh, that's something at least
[21:30] <rockstar> sinzui, handle all simple cases.
[21:32] <jcsackett> can someone tell me why factory.makeBranch sets url to None if the branchtype is IMPORTED?
[21:36] <sinzui> rockstar, this is really old code. I think though that replication is the real issue. This is probably the first we have ever dropped a person column since replication was added
[21:37] <rockstar> jcsackett, because an import branch has a code import that points to where it imported the branch from.
[21:37] <rockstar> jcsackett, er, it has an ICodeImport...
[21:38] <rockstar> sinzui, yeah, so I'm not entirely sure how to proceed.  I could do a real hack job and just add branchmergerobot to the skip list.
[21:38] <rockstar> sinzui, replication is the real issue.
[21:38] <sinzui> rockstar, I try filtering the out the tuple  and leave an XXX to remove the hack after the DB update
[21:38] <rockstar> I guess I need to commit hairy query.
[21:40] <jcsackett> rockstar: thanks, i missed makeCodeImport when I read through factory.py
[21:40] <sinzui> rockstar, or you add a rule to your sql to add UPDATE CASCADE before your drop and trick the sanity check
[21:40] <rockstar> sinzui, yeah, that might be a good idea.
[21:41] <rockstar> sinzui, or I could just drop the column.
[21:41] <mwhudson> jcsackett: "because our data model is a bit messed up"
[21:42]  * jcsackett laughs.
[21:42] <mwhudson> (the answer to many questions about any sufficiently old and large project i guess!)
[21:42] <mwhudson> jcsackett: branch.url is only about mirrored branches
[21:42] <rockstar> mwhudson, yeah, I was just talking to wgrant a few days ago about the prospect of Delorean Driven Development.
[21:42] <mwhudson> jcsackett: really, the information about where the branch is mirrored from should be separate from the branch table, as it is for code imports
[21:43] <mwhudson> jcsackett: but (a) chunk of work to change for no real benefit (b) ~noone uses mirrored branches any more
[21:43] <jcsackett> mwhudson: yeah, i should have actually known that since i was doing some work with imports prior to looking at factory; i just didn't see makeCodeImport and assumed makeBranch did something magical.
[21:43] <jcsackett> and then was sadly disappointed. :-P
[21:43] <mwhudson> heh
[21:48] <rockstar> jcsackett, "there is no disappointment in no code."
[21:54] <rockstar> sinzui, what if I did this: http://pastebin.ubuntu.com/508280/
[21:55] <sinzui> rockstar, does it work?
[21:55] <rockstar> sinzui, yessir.
[21:55] <sinzui> then I love it
[21:57] <rockstar> sinzui, yay.
[22:04] <wgrant> Yay, my branch finally worked on DF.
[22:04] <wgrant> We can release Maverick.
[22:08] <flacoste> gary_poster, lifeless: do we know why the weekly and monthly performance reports are not generated?
[22:08] <gary_poster> no
[22:08] <flacoste> that's the https://devpad.canonical.com/~stub/ppr
[22:09] <gary_poster> on call
[22:09] <poolie> hi all
[22:09] <flacoste> hey poolie!
[22:09] <poolie> hi flacoste
[22:10] <poolie> i'll still try to get you some bugs-closed numbers
[22:10] <poolie> it's not as easy as it should be :/
[22:10] <flacoste> well, it's actually not an easy problem
[22:11] <flacoste> poolie: i've tried gathering the data at the DB level, and found it hard
[22:11] <poolie> i can see that having some metric is useful
[22:11] <poolie> mm that's what i was going to do next
[22:11] <flacoste> what should we count?
[22:11] <poolie> "line written" :-P
[22:11] <flacoste> bugs on the bzr project
[22:11] <flacoste> across the bazaar project
[22:11]  * sinzui checks his query data for closed bugs by developer and milestone
[22:11] <flacoste> fwiw, there were 4 bugs tagged udd closed during the quarter
[22:11] <poolie> i was going to try in bzr, udd, bzr-*
[22:12] <poolie> mm
[22:12] <flacoste> seems low
[22:12] <poolie> it seems a bit low
[22:12] <poolie> i suspect the tag is not always applied, especially when people split a bug into several etc
[22:13] <flacoste> that's surprinsgly low given the total number of bugs fixed
[22:13] <flacoste> so not sure i wanted to report that data :-)
[22:13] <flacoste> top was 'easy' bugs
[22:14] <flacoste> i didn't include bugs in the udd project
[22:14] <flacoste> since i suspect they weren't tagged udd
[22:14] <flacoste> i was going to add a UNION for those
[22:14] <flacoste> poolie, if you could only run the hottest script for main, that would be good
[22:14] <flacoste> i can probably get the bugs data myself
[22:14] <flacoste> so don't spend too much time on that
[22:15] <poolie> one way to do it is to count things from the release notes
[22:15] <poolie> manually classifying them now as udd relevant or not
[22:15] <flacoste> right
[22:15] <flacoste> but that excludes work that was done outside of bzr
[22:15] <flacoste> itself
[22:15] <poolie> from http://doc.bazaar.canonical.com/bzr.2.2/en/whats-new/whats-new-in-2.2.html and http://doc.bazaar.canonical.com/bzr.2.2/en/release-notes/index.html
[22:15] <poolie> right, and both of them exclude non-code-changing work
[22:15] <poolie> for example john has put probably a couple of months into lp-serve
[22:16] <poolie> which is moderately relevant
[22:16] <flacoste> yep
[22:16] <poolie> but not in bzr at all
[22:23] <rockstar> What time is PQM closing again?
[22:23] <flacoste> poolie: could we run hottest100 from devpad weekly?
[22:24] <flacoste> poolie: and have the reports available over HTTP, that could even be the first step to graphing this stuff
[22:24] <flacoste> if you set up a cron job on devpad, i'm willing to do the graphing
[22:24] <poolie> that would be good
[22:24] <poolie> when i ran it last time, too many lp rpc requests failed
[22:25] <poolie> i'm not sure what's changed that it's seeing that
[22:27] <rockstar> Edwin-afk, when you return, ping.
[22:28] <rockstar> (I'm probably going to need an RC)
[22:33] <flacoste> poolie: well you ran it over a DB ugprade
[22:41] <poolie> mm, i think it was failing even earlier in the day, but then there were a couple of outages
[23:10] <LPCIBot> Project devel build (99): STILL FAILING in 3 hr 24 min: https://hudson.wedontsleep.org/job/devel/99/
[23:10] <LPCIBot> * Launchpad Patch Queue Manager: [r=mars][ui=none][bug=654795] Allow a distribution's bug supervisor
[23:10] <LPCIBot> to set source package bug reporting guidelines and acknowledgment.
[23:10] <LPCIBot> * Launchpad Patch Queue Manager: [r=jml][ui=none] An ordering issue in Person:+subscriptions has been
[23:10] <LPCIBot> fixed.
[23:34] <mwhudson> losa ping
[23:35] <spm> mwhudson: yo!
[23:35] <mwhudson> spm: the branchscanner db user can't access the distributionsourcepackage table
[23:35] <mwhudson> spm: as seen in http://launchpadlibrarian.net/57215542/jR3X1uFDWYhXPet14K6N1hWzrkG.txt
[23:35] <spm> ugh
[23:36] <spm> ho ho ho. that sounds like cowboy #1 from the last release hasn't yet landed.
[23:36] <mwhudson> spm: well, it's in devel
[23:36] <mwhudson> spm: but i think which db was master changed recently?
[23:36] <spm> heh. *twice*. yes. :-)
[23:37] <mwhudson> so it's possible the cowboy didn't propagate with the master switcheroo?
[23:37] <mwhudson> spm: anyway, can you recowboy?
[23:38] <spm> yarp. so doing.
[23:38] <mwhudson> thanks
[23:38] <mwhudson> i don't know how to rescan the branches this affected...
[23:38] <spm> https://pastebin.canonical.com/36984/
[23:38] <spm> already done
[23:38] <spm> UPDATE 33
[23:39] <mwhudson> spm: heh, this has happened before i guess? :)
[23:39] <spm> istr stub did run sec.py, so I'd assume that zotted all the grnats nicely
[23:39] <mwhudson> because otherwise that was some quick typing :)
[23:40] <spm> mwhudson: https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus <== cowboy numero uno
[23:40] <spm> I am teh awesome
[23:40] <LPCIBot> Project db-devel build (58): STILL FAILING in 3 hr 43 min: https://hudson.wedontsleep.org/job/db-devel/58/
[23:40] <LPCIBot> * Launchpad Patch Queue Manager: [r=stub][ui=none][bug=654882] Add remote_name to component and
[23:40] <LPCIBot> component group tables to track the original name from bugzilla,
[23:40] <LPCIBot> so we can supply it when forwarding bugs.
[23:40] <LPCIBot> * Launchpad Patch Queue Manager: [r=stub][ui=none][bug=644794] Switch out a link to
[23:40] <LPCIBot> DistroSourcePackage,
[23:40] <LPCIBot> in favor of separate links to Distribution and SourcePackage.
[23:40] <LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][bug=655614] Don't publish indices for
[23:40] <LPCIBot> disabled architectures.
[23:40] <LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11683,
[23:40] <spm> I just thought; ya know, this'll effect branches that need rescanning and just typed that query in. magic.
[23:40] <LPCIBot> 11684, 11685, 11686 included.
[23:42] <mwhudson> spm: is the scanner chewing on the backlog now?
[23:42] <lifeless> nom nom nom
[23:42] <spm> not sure yet - just getting the slaves updated as well
[23:43] <mwhudson> pretty sure the scanner doesn't talk to the slaves
[23:44] <spm> mwhudson: ahh it's only having issues on *some* branches; so it was still mostly (for values of most) working
[23:44] <mwhudson> spm: right
[23:45] <mwhudson> i don't understand why "        and job.date_created > (current_timestamp at time zone 'UTC' - interval'1 day')" is in that query
[23:46] <lifeless> spm: bugger, can you cancel my pqm submission? plox?
[23:46] <spm> lifeless: sure
[23:46] <lifeless> mwhudson: https://code.launchpad.net/~lifeless/launchpad/db-code
[23:47] <lifeless> mwhudson: its just a revert; are you willing to rs it ?
[23:47] <lifeless> I propose to throw it straight at db-devel and let bb sort it out
[23:47] <spm> lifeless: sorry - too late; it's already gone thru.
[23:48] <lifeless> spm: no way, it takes longe rthan that to apply
[23:48] <lifeless> perhaps it didn't get sent . \o/
[23:49] <spm> https://pastebin.canonical.com/38360/ <== that one?
[23:49] <lifeless> yeah, it didn't land. thanks for looking
[23:50] <wallyworld> rockstar: you ok for a chat?
[23:50] <rockstar> wallyworld, sure are.
[23:50] <rockstar> Lemme slap skype into submission.
[23:50] <wallyworld> skype?
[23:51] <lifeless> mwhudson: gnip
[23:51] <mwhudson> lifeless: it seems reasonable
[23:52] <poolie> i wonder if we should implement "like this" in lp by linking out to one (or more) praise-giving web services?
[23:52] <poolie> rypple, ohlo, ... probably more
[23:52] <poolie> flattr
[23:53] <lifeless> if we want that feature that might be a good way to do it.
[23:53] <rockstar> wallyworld, can you hear me?
[23:53] <poolie> i'm not saying i urgently want it, but adding the integration seems more tractable than writing the whole thing
[23:53] <wallyworld> rockstar: nope
[23:54] <lifeless> poolie: its probably more complex to integrate
[23:54] <poolie> than to write from scratch?
[23:54] <lifeless> because it raises questions we don't have if we do it inhouse
[23:54] <lifeless> yes
[23:55] <lifeless> like, off the cuff:
[23:55] <lifeless>  - how do we deal with liking private objects
[23:55] <lifeless>  - or private people liking things for that matter
[23:55] <lifeless>  - how do we deal with objects being renamed
[23:55] <lifeless>  - how do we ensure it themes in well on an ongoing basis (not just when we do the integration)
[23:56] <poolie> sure, of course
[23:57] <mwhudson> "be the first of your facebook friends to like this!"
[23:57] <mwhudson> i can see that going down well :)
[23:57] <lifeless> as long as it only shows up on oem services projects ;)
[23:57] <poolie> needs a feature scope for "hates non-source-released web services"
[23:58] <wgrant> sinzui: Can we switch off lp and db_lp, then?