[00:11] <jelmer> mwhudson, awesome
[00:11] <jelmer> mwhudson, yes, the fix for the symlink bit has landed
[00:36] <jelmer> mwhudson: so the newer dulwich and bzr-git are confirmed working for the kernelk?
[00:37] <mwhudson> jelmer: no, i haven't tried the kernel yet
[00:37] <mwhudson> i was hoping spm was going to be working today
[00:37] <jelmer> mwhudson: have you tried gedit?
[00:37] <mwhudson> jelmer: yes, locally, and it worked
[00:38] <jelmer> mwhudson: did you pull from a local git repo or a remote one?
[00:39] <mwhudson> so i'm reasonably confident :)
[00:45] <mwhudson> jelmer: remote
[00:51] <jelmer> mwhudson: cool
[00:51] <mwhudson> i'll try the kernel overnight perhaps, if i don't get it set up on staging
[01:00] <jelmer> I'm also trying the kernel here locally
[01:00] <jelmer> it'd be great to have staging trying it, I think it should take 3 days or so to do the actual import
[01:00] <thumper> jelmer: are you looking into reusing the pack file?
[01:01] <mwhudson> jelmer: trying from a local repo or remote?
[01:01] <jelmer> thumper: I started in Wellington but haven't looked at it since.
[01:01] <jelmer> mwhudson: remote
[01:03]  * thumper afk for a bit again
[01:05] <mwhudson> jelmer: ah, ok
[01:05] <mwhudson> jelmer: how many revs through now?
[01:05] <jelmer> 3300
[01:06] <jelmer> but I had 5k earlier today, restarted after I made that encoding fix
[01:07] <mwhudson> jelmer: how many revs are you pulling in each go?
[01:07] <jelmer> mwhudson, 1k
[01:07] <mwhudson> jelmer: cool
[02:07] <jelmer> mwhudson, once the new version is rolled out, it would be nice if all existing failing git imports could be retried because of the symlink issue
[02:07] <mwhudson> jelmer: git?  or bzr-svn?
[02:07] <jelmer> mwhudson, git particularly, but bzr-svn for an older issue with symlinks
[02:07] <mwhudson> or both?
[02:07] <mwhudson> ah ok
[02:07] <mwhudson> well, if there was an api for code imports...
[02:07] <mwhudson> i guess we really need to look at fixing that
[02:11] <jelmer> if they were more like mirrors you could just call requestMirror() I guess >-)
[02:12] <mwhudson> well boringly that does something rather different for imports...
[02:12]  * thumper pokes jelmer in the eye
[02:12] <mwhudson> (and the difference is now important, to avoid exposing users to partially imported incremental imports)
[02:29] <thumper> mwhudson: we don't really need to QA the removal of the old puller code do we?
[02:29] <thumper> mwhudson: as it isn't being used
[02:29] <thumper> mwhudson: I maked it ?? on the wiki page
[02:29] <thumper> mwhudson: so we should just move it to done-done on the kanban board, right?
[02:29] <mwhudson> thumper: no, not really, i guess it's just "make sure codehosting basically works"
[02:29] <thumper> mwhudson: I've pushed branches
[02:29] <thumper> mwhudson: they have been pulled and scanned
[02:30] <mwhudson> which it doesn't at the moment, but hopefully that's just apache needing to be gracefulled
[02:30] <mwhudson> thumper: ok, that sounds good enough for this item
[02:30] <thumper> I'll move it if you like
[02:30] <mwhudson> i just did
[02:30] <thumper> have you tried the reduced concurrancy?
[02:31] <mwhudson> yes, but it also includes a command line arg to specify the limit from the slave
[02:31] <mwhudson> that hasn't been tried on staging
[02:31] <thumper> ok
[02:31] <thumper> so need a losa then?
[02:31] <mwhudson> similar for the "pull mirrored branches in a separate process" item
[02:31] <mwhudson> thumper: yeah
[02:40] <mwhudson> ha
[02:40] <mwhudson> ha
[02:41] <mwhudson> assertSqlAttributeEqualsDate is broken
[02:41] <mwhudson> never fails
[02:43] <thumper> haha
[02:43] <thumper> oops
[02:44] <mwhudson> will make ec2testing this branch a little more interesting
[02:49] <thumper> mwhudson: I'm off for the afternoon, back later tonight to talk to europeans
[02:49] <mwhudson> thumper: ok
[03:42] <deryck> thumper, you around?
[03:45] <mwhudson> deryck: he'll be back in a couple of hours i think
[03:46] <deryck> mwhudson, ah, ok.  thanks.  too late for me then.
[03:46] <mwhudson> deryck: send email, i guess
[03:46] <mwhudson> (is this about the max_bug_heat thing?)
[03:46] <deryck> mwhudson, yeah.  wondering if it was still unresolved.
[03:46] <mwhudson> deryck: it is still unresolved
[03:47] <deryck> mwhudson, ok, crap.
[03:47] <mwhudson> deryck: noodles said "this needs a bug person to sort out" and i believed him
[03:47] <mwhudson> deryck: if you provide instructions i'm happy to execute them :-)
[03:47] <deryck> mwhudson, yeah, no worries.  I was just out all day with family and just now seeing email
[03:47] <mwhudson> deryck: fair enough!
[03:48] <deryck> mwhudson, let me look at the failure and see.  It may be simple enough.
[04:09] <deryck> mwhudson, how do you feel about this?  http://pastebin.ubuntu.com/386061/
[04:09] <deryck> mwhudson, I ask because I'm tired.  IPerson will never need or use max_bug_heat/
[04:09] <deryck> and the failing test will pass with this.
[04:09] <mwhudson> deryck: well, it looks like it will fix the test failures
[04:09] <mwhudson> deryck: seems a bit of a crappy solution though
[04:10] <deryck> mwhudson, yeah, that's my feeling, too. :(
[04:10] <mwhudson> is max_bug_heat perhaps on the wrong interface?
[04:10] <deryck> mwhudson, I don't think so.  It really needs to be on everything that is an IHasBugs except IPerson.
[04:11] <deryck> mwhudson, really, there's no harm in adding to IPerson.  But it's a DB patch required.
[04:11] <mwhudson> i guess given the timing of the situation, a quick fix is probably a good idea
[04:12] <mwhudson> so um yeah
[04:12] <mwhudson> seems ok to me
[04:12] <mwhudson> bung it in a merge proposal and get thumper to stamp it?
[04:12] <deryck> mwhudson, ok, I will.  And I'll do an XXX that we need a proper DB patch later.  Seem fair?
[04:12] <mwhudson> deryck: sounds right to me
[04:13] <deryck> mwhudson, cool.  thanks for the chat about it.
[04:13] <mwhudson> deryck: np
[04:17] <lifeless> deryck: I'm curious why not IPeople
[04:18] <deryck> lifeless, is there such a thing as IPeople?
[04:19] <lifeless> sorry, IPerson
[04:21] <deryck> lifeless, oh, you mean, why not have max_bug_heat for it at all?  max_bug_heat is for a pillar specific view of hot bugs.  I guess I'm not sure what a person hot bugs list looks like.
[04:22] <deryck> max_bug_heat controls the distribution of the flames.
[04:22] <lifeless> well, what does a projects hot list look like?
[04:22] <lifeless> I assume its how many 'active' indicators the bugs have, out of the 'set of bugs for this project'
[04:22] <lifeless> Seems to me that the same metric applied to a persons bugs would give a non-rubbish result
[04:24] <deryck> lifeless, yeah, you may be right.  We just have done any work yet on using hot bugs for people. Maybe we should.
[04:25] <deryck> person bugs just seems like a hazy grab-bag term of different kinds of bugs related to me, whereas project bugs makes sense.  So where to hang heat for a person?
[04:25] <deryck> related bugs?  Assigned bugs?  commented?  Everywhere? :-)
[04:26] <lifeless> yeah, I can see the impact
[04:36] <deryck> mwhudson, I need to bail now, due to short time for sleep before work. :)  Can you or thumper land that branch for me if he signs off on it?
[04:36] <mwhudson> deryck: sure
[04:36] <deryck> mwhudson, many thanks.  Sorry the failure blocked work for so many hours today.
[04:37] <mwhudson> deryck: not having any sysadmins around has been more obstructive, don't worry ;-)
[04:37] <deryck> heh, fair enough
[04:37] <deryck> cheers.  have a nice one!
[04:41] <wgrant> mwhudson: They're not back in sane timezones yet?
[04:41] <mwhudson> wgrant: travelling today i think
[04:41] <wgrant> Ah.
[04:42] <mwhudson> or maybe unconscious with jetlag
[04:42] <wgrant> Heh.
[05:07]  * mwhudson winds down for the day
[06:52] <poolie1> hi
[06:52] <poolie1> can someone remind me where the tuolumne config is?
[06:54] <poolie1> nm, i found it in https://code.edge.launchpad.net/~canonical-losas/tuolumne-lp-configs/trunk   i think
[07:05] <thumper> gah
[07:05] <thumper> trying to land deryck's branch
[07:05] <thumper> but ec2 land isn't working
[07:05]  * thumper makes a clean build
[07:15] <thumper> can anyone else get ec2 land working?
[07:15] <thumper> even with a --dry-run?
[07:17] <wgrant> thumper: It fails with a launchpadlib NotImplementedError for me.
[07:18] <wgrant> wadllib, even.
[07:18] <thumper> wgrant: thanks, me too
[07:19] <wgrant> thumper: Possibly related to the hard-coded /beta in devscripts.autoland, when the default version on edge is now 'devel'?
[07:20] <thumper> wgrant: ah, perhaps
[07:20] <wgrant> It should be fine, but it's the first thing that comes to mind.
[07:21] <wgrant> Oh, hmm, it doesn't hardcode it for edge, only dev and lpnet.
[07:22] <thumper> any other ideas?
[07:22] <wgrant> thumper: Which version of launchpadlib are you using?
[07:24] <wgrant> Yeah, so, it's requesting a /devel URL for me.
[07:24] <wgrant> ANd then complains when it gets a /beta resource type.
[07:27] <thumper> I'm using the one in the tree
[07:28] <wgrant> thumper: It looks like the served WADL is on crack.
[07:28] <wgrant> wget --header="Accept: application/vnd.sun.wadl+xml" https://edge.launchpad.net/api/devel/
[07:28] <wgrant> Has lots of /beta references in it.
[07:29] <thumper> :(
[07:29]  * wgrant works out how to invoke the launchpadlib version override.
[07:32] <wgrant> thumper: add version="beta" lib/devscripts/autoland.py's Launchpad.login_with call, clear your cache, and try again.
[07:32] <wgrant> And pester leonardr to fix lazr.restful, too!
[07:33] <thumper> wgrant: where is the cache?
[07:33] <wgrant> thumper: ~/.launchpadlib/cache, because you guys seem to hate XDG.
[08:31] <adeuring> good morning
[09:07] <thumper> gah
[09:08] <thumper> commit re fail
[09:08] <thumper> although I can't see how
[09:08] <thumper> Commit message [[testfix][release-critical=thumper][r=thumper] Return None for\n\tmax_bug_heat on IPerson until max_bug_heat can be fully added.] does not match commit_re [(?is)^\\s*\\[testfix\\]\\s*\\[(?:release-critical|rs?=[^\\]]+)\\]]
[09:08] <thumper> can anyone else see it?
[09:09] <bigjools> thumper: r-c is first IIRC?
[09:09] <wgrant> Not in that RE.
[09:09]  * bigjools hates regex
[09:09] <wgrant> ETOOMANYBACKSLASHES
[09:09] <thumper> it has testfix first
[09:09] <bigjools> try it
[09:10] <thumper> hmm...
[09:10] <thumper> trying, although it should only succeed if it isn't testing what it says it is testing
[09:10] <thumper> lifeless: regex help needed
[09:10] <bigjools> lol
[09:12] <al-maisan> is that what "special circumstances" is for ;)
[09:13] <lifeless> thumper: what ?
[09:13] <lifeless> al-maisan: its for digging out of pits :P
[09:13] <thumper> lifeless: the commit message fail above
[09:13] <lifeless> thumper: you have a \n
[09:13] <lifeless> \t
[09:14] <lifeless> in the message. Why ?
[09:14] <thumper> email subject wrapping I believe
[09:14] <thumper> lifeless: it's been happening for ages
[09:14] <thumper> lifeless: it is the start of the string that gets me though
[09:14] <thumper> lifeless: to me it looks like it matches
[09:15] <thumper> oh ho
[09:15] <thumper> it is different to the devel one
[09:15] <lifeless> thumper: no =thumper
[09:15] <lifeless> [release-critical][rc...
[09:16] <thumper> lifeless: yeah, I just saw that too
[09:16] <lifeless> perhaps. ICBW
[09:16] <lifeless> are you submitting with pqm-submit?
[09:16] <thumper> ICBW?
[09:16] <thumper> yes
[09:16] <noodles775> thumper: bzr log --line --limit 1000 |grep release-critical seems to show that ui=none is required? (or at least, has been used for successful landings in the past)
[09:16] <thumper> noodles775: not for testfix
[09:16] <lifeless> thumper: Icould be wrong
[09:17] <lifeless> I.C.B.W.
[09:17] <al-maisan> intercontinental ballistic wiki?
[09:17] <thumper> lifeless: yep, no =thumper
[09:18] <thumper> lifeless: it is in the queue
[09:22] <jml> good morning Lanuchpadders
[09:22] <wgrant> Morning jml.
[09:23] <al-maisan> hello jml
[09:26] <bigjools> hey jml
[09:27] <bigjools> you're not going to be staying in my local pub any more
[09:37] <bigjools> wgrant: you probably saw that I landed your chroot_url export branch, I don't supose you tested it on edge?
[09:37] <wgrant> bigjools: I did, and altered the local Soyuz docs to use it.
[09:37] <wgrant> bigjools: Thanks.
[09:37] <wgrant> So yes, QA OK.
[09:38] <bigjools> awesome, thanks
[09:42] <jml> bigjools, ok
[09:42] <jml> bigjools, where am I going to be staying
[09:43] <jml> bigjools, and how do I get there
[09:43] <jml> bigjools, and what are the dates again?
[09:43] <bigjools> jml: http://www.sarova.com/abbey/hotel_introduction.asp
[09:43] <bigjools> the Cheltenham Gold Cup is on at the same time - this was the last hotel with rooms
[09:43] <lifeless> jml: back in London ?
[09:44] <bigjools> jml: 17, 18,19th March
[09:44] <bigjools> jml: room booked 16th, 17th, 18th
[09:44] <bigjools> jml: you get there on a train from Paddington, which I guess is quite convenient for you :)
[09:49] <wgrant> bigjools: Any idea why there is a Pending publication (717553) in primary jaunty-release from 2009-09-07?
[09:51] <bigjools> no idea, but if it's in -release you know why it's not being published
[09:51] <wgrant> Right, but I have to wonder how it got there.
[09:51] <bigjools> me too
[09:51] <bigjools> maybe a copy
[09:51] <jml> bigjools, thanks.
[09:51]  * wgrant checks the queue.
[09:51] <wgrant> Possibly.
[09:51] <bigjools> jml: I'll email more details this week
[09:51] <wgrant> Hm, no.
[09:55] <wgrant> bigjools: Looks like it was an override.
[09:55] <bigjools> yay :/
[09:55] <wgrant> It was published in universe 6 months earlier.
[09:55] <wgrant> And the newer publication is multiverse.
[09:55] <bigjools> !
[09:58] <wgrant> Yeah, changeOverride should probably die in that case.
[09:58] <wgrant> change-override.py doesn't check.
[09:59] <bigjools> rock and roll
[09:59] <wgrant> bigjools: Also, seen bug #529710?
[09:59] <bigjools> maybe when mup decides to show me
[10:00] <wgrant> It won't.
[10:00] <bigjools> private
[10:00] <wgrant> Yes.
[10:01] <bigjools> wgrant: :(
[10:06] <wgrant> Oh good, I only rebuilt the test database, not the dev one.
[10:13] <wgrant> bigjools: Commented.
[10:25] <bigjools> wgrant: thanks
[10:42] <wgrant> win 32
[10:42] <wgrant> Argh.
[10:53] <wgrant> gmb, bigjools: ~launchpad-security emails would be getting to you through ~launchpad, which has a contact address set.
[10:54] <bigjools> you'd think :)
[10:55] <wgrant> (so they'll be on the launchpad-bugs list)
[10:57] <jml> bigjools, btw, I have no idea how to QA my item on https://dev.launchpad.net/StrategyTeamTestPlans/10.02
[10:57] <jml> (yes, I know it's too late)
[10:57] <gmb> Hahaha.
[10:58] <gmb> bigjools: Did you know about the launchpad-bugs list
[10:58] <gmb> ?
[10:59] <bigjools> gmb: maybe
[10:59] <bigjools> what does it get?
[11:00] <gmb> bigjools: Well, apparently, all the bugs ever. I'd forgotten it existed.
[11:00] <wgrant> Everything. Including the security bugs I filed yesterday which somebody might want to notify people about.
[11:00] <gmb> bigjools: But wgrant is right; your security notification might well be there.
[11:00] <bigjools> jml: stick it in the ?? section
[11:00] <bigjools> we're not QA-ing any of those recipe things et
[11:00] <bigjools> yet
[11:00] <jml> bigjools, ok, thanks.
[11:00] <gmb> Thing is, subscribing to it is an exercise in sipping from the firehose.
[11:00] <bigjools> that's prob why I don't do it
[11:01] <bigjools> we need a totally separate security-related list
[11:01] <bigjools> I get too much fucking email already
[11:01] <wgrant> I think we actually need implicit subscriptions to be fixed.
[11:01] <wgrant> In that they should apply if the user can otherwise see the bug.
[11:04] <bigjools> gmb: so, the bugs go to a private list then?
[11:05] <gmb> bigjools: Looks that way; probably a holdover from the days before a) Open sourcing and b) structural subscriptions
[11:05] <bigjools> gmb: so I get things straight - what is the notification "path" now?
[11:05] <gmb> wgrant, bigjools: I believe fixing subscriptions is high on the bugs team list for the next 6-monthly cycle, but I could be wrong about that. You'd have to ask deryck.
[11:05] <bigjools> ie. teams etc
[11:07] <deryck> Morning.
[11:07] <gmb> bigjools: So, it looks like security bugs go to LP Security, of which ~launchpad is a member. ~launchpad has a contact address (to stop us from getting spammed to death), which is launchpad-bugs@lists.ubuntu.com.
[11:07] <bigjools> ok
[11:08] <bigjools> so lp-security should have its own contact address that I can subscribe to
[11:09] <wgrant> Since they've likely not been received by anybody, can somebody please notify relevant people about bug #529348 and bug #529370?
[11:11] <gmb> bigjools: Yes, it should. That would be the sane solution.
[11:11] <bigjools> gmb: I'm taking this to the internal list
[11:11] <gmb> bigjools: Righto.
[11:11] <bigjools> gmb: thanks for your help
[11:12] <gmb> np
[11:15] <thumper> night all
[11:15]  * thumper -> bed
[11:20] <bigjools> nn thumper
[11:27] <bigjools> wgrant: any thoughts on https://bugs.edge.launchpad.net/soyuz/+bug/529950
[11:27] <mup> Bug #529950: gina fails to update "clxclient" in the LP Debian mirror <Soyuz:New> <https://launchpad.net/bugs/529950>
[11:37] <wgrant> bigjools: It's valid.
[11:37] <wgrant> Hm, at least in Packages it can happen now.
[11:37] <wgrant> Let me check.
[11:37] <bigjools> wgrant: so is there a definition of which one is the right onw?
[11:38]  * bigjools 's caffeine stream has too much blood in it, brb
[11:38] <wgrant> It's probably because dak now has aromic arch-indep domination.
[11:38] <wgrant> But the opposite of our version.
[11:38] <wgrant> s/aromic/atomic/
[11:39] <wgrant> bigjools: Shouldn't you just import both?
[11:39] <wgrant> (if that's not easy, the latest is most appropriate)
[11:45] <wgrant> bigjools: It looks like it will be easy enough to fix. Just add an extra level of dicts.
[11:46] <bigjools> wgrant: yeah
[11:47] <bigjools> wgrant: so does the spec say the most recent version or does it say the first in the file?
[11:47] <wgrant> bigjools: For apt, the latest version will win.
[11:48] <wgrant> But there's no reason we shouldn't import all of them.
[11:49] <wgrant> (Ignoring pinning, apt will pick the latest version. If there is more than one instance of the latest version, the first entry in sources.list will win.)
[11:55] <wgrant> bigjools: Native binary indices are unordered -- this appears to be because getBinaryPackagePublishing doesn't have a default order clause, whereas getSourcePackagePublishing does.
[11:55] <wgrant> This isn't deliberate, I guess?
[11:56] <bigjools> I highly doubt it
[11:57] <wgrant> I guessed not, but it seems a bit odd that only one is ordered.
[11:59] <bigjools> probably either for a test or UI
[12:00] <wgrant> I guess.
[12:07] <wgrant> bigjools: Isn't bug #528459 just the NBS case?
[12:07] <mup> Bug #528459: PPA does not delete old packages after new build <Soyuz:Incomplete> <https://launchpad.net/bugs/528459>
[12:09] <bigjools> I am asking for an example to double check
[12:09] <bigjools> it also becomes a test case if there's a problem
[12:10] <wgrant> True.
[13:25] <deryck> gmb, there are two bugs in the QA ready lane for filebug -- add an api, and poll for status.
[13:26] <deryck> gmb, Are these done, or can they be done to free some space on the board?
[13:26] <gmb> deryck: I am testing both as we speak (well, as soon as a LOSA becomes available for the second one)
[13:30] <deryck> gmb, excellent, thanks.
[13:36] <deryck> morning, kfogel :-)
[13:37] <kfogel> deryck: hey, morning.
[13:43] <gmb> deryck: Offline blob processing FTW! https://bugs.staging.launchpad.net/malone/+bug/528792
[13:45] <deryck> gmb, very nice!
[13:45] <deryck> oh happy fat data day!
[13:45] <gmb> deryck: And that's all the +filebug stuff QA'd, too. Epic win.
[13:46] <deryck> gmb, very epic.  A good start to our Monday.
[13:46] <gmb> deryck: Now I'll finish that blog post.
[13:46] <gmb> Would've finished it Friday but had issues with my dev env. Happily, that's now fixed too.
[13:47] <mup> Bug #528792: No right-click menu on Notification Area panel item <amd64> <apport-bug> <lucid> <gnome-panel (Ubuntu):New> <https://launchpad.net/bugs/528792>
[13:56] <kfogel> deryck: I've done everything I can at Gravatar to get my image showing for my canonical email, but the kanban board still doesn't show it (for bug 471195 for example)
[13:56] <mup> Bug #471195: Private bugs don't set the body class to "private" <css> <privacy> <Launchpad Bugs:Triaged by kfogel> <https://launchpad.net/bugs/471195>
[13:57] <deryck> kfogel, do you show up on any other gravatar site for your canonical.com addr?  (You can post a test comment on the latest post on my personal site and see.)
[14:00] <kfogel> deryck: ok, ready for you to mod the comment through
[14:02] <deryck> kfogel, done.  and avatar'ed.
[14:02] <kfogel> deryck: avatar is there. how come there's a strikethrough on my name, though?
[14:02] <kfogel> (just curious -- doesn't matter for kanban purposes)
[14:03] <deryck> kfogel, strikethough is my visited link convention.  not a great one, I'll admit.
[14:03] <kfogel> deryck: it makes me feel... struck through :-).
[14:03] <deryck> kfogel, heh.
[14:03] <deryck> yeah, I should change it.  But I don't love on my site like I should.
[14:04] <deryck> kfogel, so I hard reloaded the kanban board and you show up there for me now.
[14:07]  * deryck stares at adeuring and thinks "gravatar," making an I-am-telepathic face
[14:07] <adeuring> argghhh
[14:07] <kfogel> deryck: hunh.  I was doing hard reloads too, and yet it wasn't showing up.  Now I'd test again, but my Firefox has again jammed up, as it does approximately every 12-18 hours.
[14:07] <adeuring> yeah, i suck with this stuff
[14:08] <deryck> kfogel, no worries.  Maybe some delay on gravatar's cache.  You want me to delete your comment from my site, or let it stand?
[14:08] <kfogel> deryck: rebooting, just to see if that shakes the dust out.  enough is enough.  bbiab.
[14:08] <kfogel> deryck: oh, delete it I guess.  My parents will do a google search and then worry about my weight :-).
[14:08] <deryck> heh
[14:08] <deryck> kfogel, I've lost 3 pounds since that post. :-)
[14:09] <kfogel> deryck: man, writing it must have been hard work!
[14:09] <kfogel> :-)
[14:10] <deryck> heh
[14:26] <kfogel> deryck: gravatar showing up for me in Chrome.  Go figure.
[14:26] <deryck> kfogel, weird.
[14:29] <deryck> adeuring, allenap, gmb, intellectronica, kfogel -- standup in two?
[14:29] <adeuring> yes
[14:29] <gmb> Yarp
[14:29] <intellectronica> yes
[14:30] <kfogel> deryck: ready
[14:59] <leonardr> when i try to buildout launchpad i'm getting a ClientCookie error. i've gotten this error before but i don't remember what to do about it
[14:59] <leonardr> the first error i get is that launchpad tries to download a setuptools egg and is ***BLOCKED***, which is also familiar
[15:05] <leonardr> my download-cache and eggs symlinks point to the directories i'd expect
[15:07] <leonardr> flacoste, maybe you can end my torment? -^
[15:08] <flacoste> leonardr: do you have pastebin of the whole buildout run?
[15:08] <leonardr> flacoste: i'll paste it now
[15:12] <leonardr> flacoste: http://paste.ubuntu.com/386348/
[15:13] <leonardr> there's bootstrap.py and buildout
[15:13] <leonardr> never mind the ***BLOCKED** thing, it's irrelevant
[15:13] <leonardr> i ran bootstrap with the wrong arguments
[15:14] <leonardr> gary: you might know better than flacoste what my problem is -^
[15:15] <gary_poster> leonardr: does not look familiar.  did you simply try make clean and make?
[15:15] <leonardr> gary: this is a branch new checkout
[15:15] <leonardr> http://paste.ubuntu.com/386347/ shows what happens when i checked out and ran make
[15:24] <gary_poster> leonardr: sorry had dr call.  Try merging my branch...getting
[15:25] <gary_poster> leonardr: lp:~gary/launchpad/bug491705
[15:25] <gary_poster> gmb: ping?
[15:27] <gary_poster> gmb: want to know if you are available to diagnose your buildout problem from Friday.  Let me know if you can, or I should try you later in week.  (Current request is to start with clean branch (make clean is fine), merge my branch, apply http://pastebin.ubuntu.com/384463/ , and give me full output of ``make SHHH=``
[15:28] <gmb> gary_poster: I've actually found and fixed the problem this morning. There were stray zope.testing packages-3.8.3 on my system, even after apt-get removing it. Removing those packages made the problem go away
[15:29] <gary_poster> gmb: great...ish. ;-) I can't try making it more robust for everyone else, then.  Do you now know a way I can dupe the original situation, maybe?
[15:30] <gmb> gary_poster: If you install zope.testing 3.8.3 for python 2.5 and then leave the package lying around in the site-packages directory that should do the trick, I think.
[15:31] <gary_poster> gmb ok awesome will give it a try thanks.  install via apt I assume you mean?
[15:31] <gmb> Yes
[15:31] <gary_poster> cool thanks
[15:34] <leonardr> gary: same problem. bootstrap warns about ClientCookie, buildout chokes on it
[15:35] <gary_poster> leonardr: this sounds like an old problem we had when people had badly-removed ClientCookie packages from apt.  Lemme see if the traceback suggests someplace to look.
[15:35] <leonardr> gary: it definitely seems familiar to me
[15:35] <leonardr> let me update my packages
[15:38] <gary_poster> leonardr: I would start Python2.5, and see if ClientCookie is importable.  If so, get the __file__.  Then see if apt thinks that the package is installed.  If apt doesn't think that ClientCookie, or that version of ClientCookie, is installed, then it sounds like the old problem.  Clean up the bad ClientCookie and try again.
[15:39] <leonardr> gary: it's the latter. i see broken symlinks. 'clean up' by removing or by fixing manually?
[15:41] <gary_poster> leonardr: ...it depends on what the symlinks are.  If you think the symlinks are supposed to still be there, then fix 'em.  If not, remove 'em.  If you are not sure, I guess I'd want to know exactly what the symlinks were and what they used to point to and what apt thinks is installed for me to make my own guess.
[15:42] <leonardr> gary: i don't have any 'cookie' package installed, so i removed them
[15:42] <gary_poster> sounds right, leonardr
[15:42] <GPenguin> how easy is it to extract the "karma" related code from the entire base?
[15:43] <GPenguin> or lets put it different - could a python beginner expand the karma related code easily or would it be smarter to "hire" somebody to do it?
[15:43] <leonardr> gary: getting a new problem now. i got a similar problem, reverted my merge of your branch, and then got this
[15:45] <leonardr> gary: http://paste.ubuntu.com/386369/
[15:47] <leonardr> gary: 3.7.3 is the version installed in site-packages
[15:47] <gary_poster> GPenguin: not ignoring you, but don't know that part of code.  I strongly suspect the only way a Python beginner could do it is with more than a little assistance (to know where to look in the code, and to write automated tests sufficient to pass review).
[15:47] <leonardr> so once again, the site-packages version is taking precedence over the version installed by ubuntu
[15:48] <gary_poster> leonardr: did you have that problem with my branch?
[15:48] <leonardr> er
[15:48] <leonardr> i had a similar problem... let me find it
[15:48] <james_w> leonardr: when you have a minute I would appreciate your input on bug 529998, as you will be able to point to the faulty component.
[15:48] <mup> Bug #529998: Error caused by binding to anonymous collection resource <wadllib:New> <https://launchpad.net/bugs/529998>
[15:48] <leonardr> gary: with your branch i got this error message
[15:48] <leonardr> Error: There is a version conflict.
[15:48] <leonardr> We already have: zope.testing 3.8.2
[15:50] <leonardr> i believe that was the version you specified in your change to versions.cfg
[15:50] <gary_poster> leonardr: could you give a pastebin of the full output, *or* let me know if that is happening clearly in bin/buildout, rather than bootstrap?
[15:52] <gary_poster> leonardr: if it is happening in bootstrap, then this sounds like Graham's report, and I was hypothesizing that http://pastebin.ubuntu.com/384463/ (in addition to my branch) might help
[15:53] <leonardr> gary: it happened in bootstrap, but looking at the scrollback revealed that i didn't run bootstrap with the right options
[15:53] <leonardr> i'm trying again now
[15:54] <gary_poster> leonardr: ok, in bootstrap makes me mildly happier (I was optimistic that I had squelched problems in bin/buildout with my branch). I doubt the options will help, but .  The patch I gave might.
[15:54] <leonardr> gary: no, it happens in buildout for me. bootstrap runs without warnings or errors
[15:54] <gary_poster> lovely.
[15:54] <leonardr> i'll try the patch
[15:55] <gary_poster> that won't help bin/buildout
[15:55] <leonardr> right
[15:58] <leonardr> gary: now that i know it might not be my problem, i'm going to try to do work on a branch i already have checked out
[15:58] <gary_poster> leonardr: I really have to dupe.  I've solved everything I know of that can cause this in my branch, except for in bootstrap, which is not where you are encountering the problem.  Just to doublecheck, would you please pastebin your bin/buildout?
[15:58] <leonardr> gary, sure
[15:58] <gary_poster> The bin/buildout that is causing the problems, of course.
[15:58] <leonardr> if you need me for this that's a different story
[16:00] <gary_poster> thanks leonardr.  I certainly don't want to block you any more that you already have been.  Maybe you can make progress on the other branch while I occasionally ask questions of you for this one.  I'll try to be out of your hair as quickly as possible.
[16:00] <c_schmitz_> hi everyone
[16:01] <c_schmitz_> A really nice thing about Launchpad is the translations part
[16:01] <c_schmitz_> would it be possible to use if without the other modules?
[16:01] <c_schmitz_> *use it
[16:01] <c_schmitz_> if I install Launchpad on my own site?
[16:02] <c_schmitz_> Or are the modules all tightly connected to each other?
[16:03] <c_schmitz_> I would be very glad for any hints/experiences on that
[16:03] <gary_poster> c_schmitz_: within the hosted service, sure.  on your own site, the code is installed in a bundle, and we don't support that  (we want to encourage people to use the hosted service).
[16:03] <leonardr> gary: http://paste.ubuntu.com/386381/
[16:03] <leonardr> brand new checkout of your branch
[16:04] <c_schmitz_> gary_poster: I see
[16:04] <danilos> c
[16:06] <gary_poster> leonardr: could you pastebin the contents of the bin/buildout script?
[16:07] <leonardr> sure
[16:08] <leonardr> gary: http://paste.ubuntu.com/386384/
[16:12] <james_w> thekorn: thanks, that would have saved me quite some time had I found those :-)
[16:15] <thekorn> james_w, oh :( I wish this bug could somehow be fixed
[16:16] <james_w> thekorn: I have it fixed locally
[16:16] <james_w> I'd just like Leonard's input to know whether it is the correct fix
[16:17] <thekorn> james_w, you mean the .total_size bug or the more general "does not behave like a collection"-bug ?
[16:17] <james_w> well, the bug that means you get a crash every time you access an attribute of an anonymous collectio
[16:18] <gary_poster> leonardr: ok thanks.  Have an idea.  Could you give me the content of the addsitepackages function in /home/leonardr/canonical/lp-branches/from-gary/parts/buildout/site.py?
[16:18] <leonardr> sure
[16:19] <leonardr> gary: i'll tell you right now it's mostly site-packages repeated a lot
[16:19] <gary_poster> leonardr: ok that's enough
[16:20] <leonardr> gary: and then there's the zc.buildout-1.5.0devgary at the end
[16:20] <gary_poster> leonardr: ok, will give you a patch in a minute or two for you to try.
[16:20] <leonardr> grat
[16:28] <gary_poster> leonardr: http://pastebin.ubuntu.com/386394/ for eggs/zc.buildout-1.5.0dev_gary_r109427-py2.5.egg/zc/buildout/buildout.py .  Lines 19-21 are the important bits.
[16:29] <leonardr> all right
[16:34] <gary_poster> leonardr: oh forgot to say, you need to rerun bootstrrap
[16:34] <gary_poster> then bin/buildout should be ok
[16:34] <gary_poster> (because site-packages should not be in in parts/buildout/site.py any more)
[16:34] <leonardr> gary: still not working, doing a make clean
[16:35] <gary_poster> k
[16:35] <leonardr> gary: site-packages is no longer in site.py but i get the same problem
[16:35] <gary_poster> !!
[16:36] <gary_poster> leonardr: *exactly* the same problem (during recipe installation)?
[16:36] <gary_poster> While: Installing recipe z3c.recipe.i18n.
[16:37]  * gary_poster hates not being able to dupe problem :-(
[16:37] <leonardr> gary: yes, exactly the same
[16:37] <leonardr> we already have: zope.testing 3.8.2
[16:37]  * gary_poster curses
[16:38] <leonardr> gary: what if i put debug in whatever outputs "we already have"
[16:38] <leonardr> to see what the conflict is?
[16:38] <leonardr> do you know where that code is?
[16:40] <gary_poster> leonardr: yeah, it is in zc/buildout/easy_install.py, Installer.install, but the conflict is with zope.testing 3.8.2, like it says, which you and I both have installed in apt, so I don't have a lot of optimism on what information we can get extra there.  I think I'll get out of your hair awhile so you can focus more fully on the critical bug fix.  When that is done, let me know.  I'll look at it a bit more.  Thank you!
[16:41] <leonardr> ok
[16:56] <leonardr> gary: i no longer have any working branches, so i can't make any more progress on wgrant's problem
[16:56] <gary_poster> leonardr: ah, lovely.
[16:56] <leonardr> the conflict is with zope.testing 3.8.2 and what? the version mentioned in versions.cfg?
[16:57] <gary_poster> leonardr: yes 3.8.1
[16:58] <gary_poster> leonardr: possible workarounds: (1) uninstall zope.testing (2) try setting 3.8.2 in versions.cfg and hope it works.
[16:58] <deryck> adeuring, could you do a review for me?  Should be easy.
[17:00] <leonardr> ok...
[17:01] <leonardr> Getting distribution for 'zope.testing==3.8.2'.
[17:01] <leonardr> make: *** [/home/leonardr/canonical/lp-branches/untouched-trunk/bin/py] Error 1
[17:01] <leonardr> gary: that would imply that it can't find the download-cache at all
[17:01] <leonardr> ('couldn't find a distribution')
[17:01] <leonardr> well, that would imply it's not looking in site-packages
[17:02] <leonardr> so when it's time to look for the version number, it looks in site-packages
[17:02] <leonardr> and when it's time to look for the package, it looks in download-cache
[17:02] <gary_poster> leonardr: is this after you tried option 2?
[17:02] <leonardr> gary: yes
[17:03] <gary_poster> leonardr: option 1 didn't work/was too annoying because something important depended on it?
[17:03] <leonardr> gary: #2 seemed easier
[17:03] <leonardr> i'll try #1 now
[17:03] <gary_poster> ok
[17:05] <leonardr> gary: #1 says it'll break python-zodb
[17:05] <leonardr> but i might not need that since launchpad has its own
[17:06] <gary_poster> leonardr: yeah, what package wants zodb?  leonardr I'm trying a restart to see if that somehow makes me able to dupe
[17:07] <gary_poster> ...nope, still works fine...
[17:09] <gary_poster> leonardr: will try installing python-zodb...if you see what depends on it, tell me, and I'll add that
[17:09] <adeuring> deryck: yure
[17:09] <leonardr> gary: so, i removed all the zope stuff
[17:09] <adeuring> (and sorry ffor the late answer)
[17:09] <leonardr> now i get
[17:09] <leonardr> Error: There is a version conflict.
[17:09] <leonardr> We already have: zope.testing 3.7.3
[17:10] <gary_poster> leonardr: which aptitude doesn't know about?  If so, find it and kill it.
[17:11] <leonardr> gary: given a path, can aptitude tell me which package owns that path?
[17:12] <gary_poster> leonardr: I would see if zope.testing is installed.  If not, kill it.
[17:12] <deryck> adeuring, thanks.  See:  https://code.edge.launchpad.net/~deryck/launchpad/fix-affects-me-widget-529049/+merge/20380
[17:12] <leonardr> zope.testing is not installed
[17:12] <gary_poster> leonardr: (IOW, I don't know, but I don't think it matters)
[17:12]  * adeuring is looking
[17:12] <gary_poster> ..aaaand it works just fine for me when I have python-zodb installed.
[17:13] <gary_poster> leonardr: this is an up-to-date karmic, yeah?
[17:13] <leonardr> gary: yeah
[17:13] <gary_poster> k
[17:13] <leonardr> buildout is taking a while now...
[17:13] <gary_poster> that's a good sign
[17:15] <gary_poster> leonardr: do you not share eggs, or have you not made a build in a while?  Usually goes about 6 seconds for me when all eggs are built
[17:17] <leonardr> gary: i made a build last week. it's possible that earlier code was working with my strangely installed zope packages
[17:17] <gary_poster> huh
[17:22] <gary_poster> leonardr: buildout still going??
[17:24] <adeuring> deryck: r=me
[17:24] <deryck> adeuring, awesome.  thanks.
[17:27] <leonardr> gary: seems to be ok, i'll let you know
[17:27] <gary_poster> ok leonardr thanks
[17:29] <deryck> adeuring, there's something else I needed to mention to you.... what was it? .... oh, yeah, what's that word?....  gravatar.
[17:29] <deryck> :-)
[17:29] <adeuring> yeah...
[17:29] <deryck> heh
[17:30] <deryck> adeuring, I'll leave you alone about it now.  Promise. :-)
[17:46] <gary_poster> leonardr: I think I got it.  I think lines 29-31 of http://pastebin.ubuntu.com/386428/ would have fixed it.  I'll see if I can write a test for it when I get back from lunch.  I still don't understand why it doesn't bite me.
[18:55] <leonardr> gary, can you spare a few for some Makefile brainstorming?
[18:55] <gary_poster> sure leonardr
[18:57] <leonardr> gary: current behavior is to create the wadl file like so
[18:57] <leonardr>  LPCONFIG=$(LPCONFIG) $(PY) ./utilities/create-lp-wadl.py > $@.tmp
[18:58] <leonardr> however, now create-lp-wadl.py creates an arbitrary number of wadl files, not just one
[18:58] <leonardr> i changed the script to take a path template as a command-line argument
[18:58] <leonardr> so now LPCONFIG=$(LPCONFIG) $(PY) ./utilities/create-lp-wadl.py $@.tmp
[18:59] <leonardr> where WADL_FILE is lib/canonical/launchpad/apidoc/wadl-$(LPCONFIG)-%(version)s.xml
[18:59] <leonardr> unfortunately the old $@.tmp pattern doesn't work anymore
[18:59] <leonardr> it used to be we were writing to .tmp in a directory that already existed, then renaming
[19:01] <leonardr> i'm thinking of making an apidoc.tmp directory, generating the files in there, and moving the _contents_ to apidoc
[19:01] <leonardr> does that sound good?
[19:02] <gary_poster> leonardr: the concern I have right now is how to make it so that we don't rebuild those for every make invocation
[19:03] <gary_poster> do you have a plan for that?
[19:03] <leonardr> gary: right now we explicitly clear out the cache so that the wadl is generated on every make invocation. you want to change that?
[19:04] <leonardr> if we don't want that, we can just not clear the cache
[19:04] <gary_poster> we do?!  looking at Makefile
[19:05] <leonardr> gary: it's in the create-lp-wadl.py file
[19:06] <gary_poster> leonardr: because it is controlled in the Makefile with $(WADL_FILE): $(BZR_VERSION_INFO) then it will only be regenerated if the wadl file is missing or the bzr version info file changes
[19:06] <gary_poster> leonardr: that kind of constraint needs to stay.  devs get crankier and crankier the longer make run takes unnecessarily
[19:07] <leonardr> gary: ok, i can change that so it makes sure the 'devel' wadl is present. we'll always have that
[19:07] <gary_poster> leonardr: yeah, I was going to suggest something like that
[19:09] <gary_poster> leonardr: as far as apidoc.tmp, that sounds reasonable as a pattern.  I don't have a string opinion as to names (and may be missing a concern), but apidoc.tmp specifically is ok with me
[19:09] <mwhudson> yeah, unnecessary make run time brings out the pitchfork wielding mobs
[19:09] <gary_poster> leonardr: another possibility is to use Python's temp directories
[19:09] <gary_poster> :-)
[19:09] <leonardr> gary: from a makefile?
[19:10] <gary_poster> leonardr: I guess I was thinking of moving the logix to ./utilities/create-lp-wadl.py
[19:10] <gary_poster> logic
[19:10] <leonardr> that might be simpler
[19:10] <mwhudson> you have to be a bit careful using mkdtemp if you want to do os.rename later
[19:10] <gary_poster> mwhudson: we'll just me moving the contents
[19:10] <gary_poster> be
[19:11] <gary_poster> so that's ok, yeah?
[19:11] <mwhudson> gary_poster: but if /tmp and your launchpad tree are on different filesystems that'll fail, i think?
[19:11] <gary_poster> mwhudson: ah, so.
[19:12] <gary_poster> shutil copying would still be fine
[19:12] <gary_poster> or whatever that package name is...
[19:12] <gary_poster> yah that's it
[19:13] <gary_poster> so leonardr, either do everything in create-lp-wadl, but use shutil to do the final move-the-contents thing, or do the directory dance you originally proposed.  I'm fine with either, though slightly prefer the all-Python approach.
[19:15] <leonardr> gary: where does $@ come from? is that the file that exists in the conditional?
[19:16] <gary_poster> $@ is the make target I believe, leonardr
[19:17] <gary_poster> so, $(WADL_FILE)
[19:17] <gary_poster> in this case
[19:18] <leonardr> ok, so that's what i need to change to DEVEL_WADL_FILE
[19:19] <gary_poster> yeah
[19:19] <leonardr> ok
[19:43] <thumper> morning
[19:44] <kfogel> deryck: re bug #471195: when you were talking about javascript the other day, was that for javascript to reload the page (with the new body class tag) after someone sets the bug to "private"?
[19:44] <mup> Bug #471195: Private bugs don't set the body class to "private" <css> <privacy> <Launchpad Bugs:In Progress by kfogel> <https://launchpad.net/bugs/471195>
[19:44] <kfogel> deryck: ...or for something else?
[20:08] <thumper> deryck: ping
[20:08] <thumper> deryck: https://lpbuildbot.canonical.com/builders/db_lp/builds/560/steps/shell_7/logs/summary
[20:08] <thumper> deryck: db builder running right now has that failure
[20:09] <deryck> thumper, looking now.
[20:10]  * deryck primal screams
[20:11] <mwhudson> weee
[20:11] <mwhudson> blowing up in error reporting, for that extra pain
[20:14] <deryck> not sure I follow at all what's happening there.  but updating db-devel locally and running locally to see if makes more sense looking at the fille.
[20:15] <mwhudson> deryck: i know that error
[20:15] <mwhudson> deryck: the script is trying to report an oops
[20:16] <mwhudson> deryck: but no oops directory is configured in the config
[20:16] <mwhudson> --> bang!
[20:16] <deryck> ah
[20:17] <deryck> two levels of fail then.  my lucky day. :-)
[20:18] <deryck> I'm running ./bin/test with no shirt on.
[20:19] <deryck> never go change to running clothes and check IRC in the middle
[20:32] <deryck> intellectronica, any chance you're around?
[20:33] <wgrant> sinzui (or other Registry people): Have you seen bug #529370?
[20:34]  * sinzui looks
[20:35] <sinzui> wgrant: No I had not
[20:36] <sinzui> wgrant: apparently I do not get notified when something is really important
[20:36] <sinzui> wgrant: Thank you very much for following this up
[20:36] <wgrant> sinzui: No, we discovered that last night. The email goes to launchpad-bugs@l.u.c.
[20:36] <wgrant> I believe the issue was taken to the list.
[20:38] <sinzui> I do not seem to get that. Bug supervisor and security are so fucked when it comes to ACLs
[20:39] <wgrant> Yes...
[20:40] <wgrant> sinzui: Interesting that this one is critical for 10.02, when the other two (both of which are more critical, and one of which involves only deleting code) are 10.03.
[20:40] <sinzui> wgrant: my team completed QA last week, We are available to fix issues now
[20:41] <wgrant> Ah, good.
[20:41] <sinzui> wgrant: if It is rejects for RC, I will peruse a CP
[20:41] <sinzui> s/rejects/rejected/
[20:41] <wgrant> sinzui: Thanks.
[21:02] <leonardr> gmb, are you around?
[21:02] <deryck> thumper, I don't think I can get this fixed before I need to be away.  (Kids little league soccer/footbal practice.)
[21:02] <thumper> deryck: the db_devel failure?
[21:03] <deryck> thumper, yeah
[21:03] <deryck> thumper, there's a problem with intellectronica's method to updates max_bug_heat, though it's not clear to me what's going wrong.
[21:04] <thumper> deryck: abentley tells me that you are missing an error dir in the config
[21:04] <thumper> deryck: and probably that is all
[21:04] <thumper> deryck: maybe that is all
[21:05] <deryck> thumper, maybe that is another issue.  But I think there's a real error.  If I comment out setMaxBugHeat, the test passes.
[21:05] <thumper> deryck: hmm, ok
[21:05] <thumper> deryck: so... what's the plan?
[21:06] <thumper> deryck: it is only 9pm in London
[21:06] <thumper> heh
[21:06] <deryck> thumper, just had one more idea....  let me try.
[21:06] <deryck> heh
[21:06] <abentley> deryck, agreed, you have two issues: your test is erroring, and your error handling isn't working because you don't have an error directory configured.
[21:06] <deryck> abentley, right
[21:07] <deryck> thumper, I can be back later if intellectronica doesn't come back tonight.  which we shouldn't expect. ;)
[21:08] <deryck> I know that line 220 of lib/lp/bugs/model/bugtarget.py is the issue.  setMaxBugHeat is, I think, getting a value it doesn't like.
[21:08] <deryck> but I can't get pdb to play well with this test, so can't work it out.
[21:08] <deryck> thumper, ^^
[21:09] <thumper> deryck: hmm, shouldn't then max_bug_heat be on IBugTarget? (I was thinking this last night)
[21:10] <deryck> thumper, probably.  but last night is unrelated to this. :-)
[21:10] <thumper> deryck: yeah
[21:11] <deryck> thumper, so I'll just have to have a look later.  I don't expect anyone on my team to be back tonight.  Very sorry.... but I have to do a practice with my daughter.
[21:12] <thumper> deryck: ok, I might call Tom :)
[21:13] <deryck> thumper, I think that's fair.  We shouldn't have landed this without running through ec2.
[21:13] <deryck> thumper, in fact, I'll call him.
[21:17] <thumper> deryck: thanks
[21:27] <intellectronica> thumper: i hear that there's a failure related to bug heat, but looking at the builders they look fine and i didn't get any failure mail. got any info on the problem?
[21:27] <thumper> intellectronica: https://lpbuildbot.canonical.com/builders/db_lp/builds/560/steps/shell_7/logs/summary
[21:27] <thumper> intellectronica: it is still running
[21:29] <intellectronica> thumper: i'll have a look, thanks
[21:58]  * mwhudson afk for a few minutes
[22:04] <intellectronica> thumper: i have a fix
[22:04] <intellectronica> thumper: https://code.edge.launchpad.net/~intellectronica/launchpad/bug-heat-testfix/+merge/20404
[22:04]  * thumper looks
[22:08] <thumper> intellectronica: confirmed to fix it?
[22:09] <thumper> intellectronica: store.flush needed somewhere in a unittest?
[22:09] <intellectronica> thumper: yes. it's the last error of this kind. i fixed a bunch of them earlier and simply left this user out
[22:09] <intellectronica> thumper: no, i don't think a store flush is needed to test this
[22:10] <intellectronica> but i don't know much about this particular test, and it worked before, so i'm satisfied with just fixing the permissions
[22:11] <james_w> https://code.edge.launchpad.net/~james-w/launchpad/fix-getRequestedReviews/+merge/20378
[22:11] <intellectronica> the problem was introduced because i made that job, indirectly, do more work that touches more tables, and as a result had to give the permissions to all users who call it
[22:11] <james_w> ^ a get violates a unique key constraint? It only checks on the get? or doctests are masking the issue?
[22:12] <thumper> intellectronica: ok
[22:12] <james_w> the first get is actually triggering it to the actual things that were set up at the start of the test?
[22:15] <leonardr> gmb, i'm going to throw some stuff out here--send me an email if i'm not around when you read it
[22:15] <intellectronica> thumper: do i need to land it with [testfix] ?
[22:15] <thumper> intellectronica: I don't think so
[22:15] <thumper> intellectronica: as it hasn't finished yet
[22:15] <intellectronica> ok
[22:16] <leonardr> i'd like to remove wadl-testrunner-devel.xml from launchpad. bzr annotate seems to indicate that you originally introduced that file. with the multi-version code i've been working on, i don't think that file does anything useful except add another thing that needs to be tested. i'd like to hear if you agree, and if not, what good the wadl-testrunner-devel.xml file does from a performance standpoint or whatever standpoint leads
[22:16] <leonardr>  you to disagree
[22:20] <wgrant> james_w: Storm won't flush the changes to the DB until it needs to.
[22:20] <wgrant> james_w: A GET will normally do a store.find somewhere, which will cause a flush.
[22:21] <james_w> wgrant: right, so this is likely something in the diff that I've added, rather than the auth changes meaning that it is trying to create a new person when the request comes in?
[22:21] <james_w> because I'm having trouble seeing how my changes add to or alter to the Person table to violate that constraint
[22:22] <wgrant> james_w: makeBranchMergeProposal probably created a new Person.
[22:22] <wgrant> james_w: Do a flush after that, and see if it fails.
[22:22] <thumper> james_w: it is probably the renaming of a branch or person in the test
[22:23] <wgrant> + >>> proposal.source_branch.owner.name = 'target'
[22:23] <james_w> ah
[22:23] <thumper> james_w: pass in the owner or project to the makeXXX factory function
[22:23] <james_w> trying to actually get a dev environment back up so that I can actually run the tests
[22:24] <james_w> so much for coding purely using the force
[22:25] <wgrant> gary_poster: The change should be easily RCable, right?
[22:25] <wgrant> It is just a deletion and probably a test inversion.
[22:26] <gary_poster> wgrant: you are talking about the security bug you made?  If so, yes.  This should be a trivial branch, unles a test run proves otherwise.
[22:26] <wgrant> gary_poster: Right. Great!
[22:26] <wgrant> Thanks for getting onto it.
[22:27] <gary_poster> Thank you, wgrant.
[22:27] <wgrant> it'll break a few apps, but they'll find out soon enough.
[22:27] <gary_poster> :-) true
[22:27] <wgrant> (that's actually how I discovered it)
[22:34] <wgrant> sinzui: Thanks for fixing that.
[22:34] <sinzui> wgrant: thanks again for following up the issue
[22:38] <wgrant> np
[22:42] <thumper> wgrant: which one?
[22:43] <wgrant> thumper: Which what?
[22:44] <thumper> wgrant: which security bug
[22:44] <thumper> mwhudson: https://code.staging.launchpad.net/~mwhudson/gedit/trunk looks good
[22:44] <wgrant> https://bugs.launchpad.net/bugs/529370, https://bugs.launchpad.net/bugs/529348 or https://bugs.launchpad.net/bugs/529710
[22:46] <wgrant> thumper: It would be nice if it gave a more useful progress indicator, but I guess that's more difficult.
[22:47] <thumper> wgrant: "it gave a more useful progress indicator", what it?
[22:47] <thumper> wgrant: and that first bug number didn't exist for me
[22:48] <thumper> wgrant: nm, I think it was the trailing comma
[22:48] <thumper> wgrant: and the first one is fix committed
[22:48] <wgrant> thumper: 'it' being incremental imports. They just say n/1000 every time.
[22:49] <wgrant> It's going to be unobvious to everybody that it's actually working.
[22:49] <mwhudson> should be easy to change
[22:49] <thumper> wgrant: file a bug :)
[22:49] <wgrant> thumper: Against bzr-git?
[22:50] <thumper> mwhudson: do we echo it exactly?
[22:50] <mwhudson> yeah
[22:50] <mwhudson> (to both of you, i guess!)
[22:50] <thumper> mwhudson: could we hook in our own ui factory?
[22:50] <mwhudson> thumper: well, so "echo it exactly" is definitely not right
[22:51] <mwhudson> we do have our own ui factory that only updates once a minute
[22:51] <thumper> mwhudson: ah
[22:51] <mwhudson> and doesn't try at all to do fancy terminal things
[22:51] <mwhudson> we don't fiddle with the text though
[22:51] <thumper> mwhudson: so we could update our own ui factory to show that it is '345/1000 (partial import of 9876)'
[22:51] <thumper> something like that?
[22:52] <mwhudson> thumper: much easier to do it in bzr-git
[22:52] <thumper> should be trivial right?
[22:52] <thumper> hmm..
[22:52] <mwhudson> thumper: well no, our code wouldn't know that the revision count is 9876 (easily, anyway)
[22:55] <mwhudson> hmm
[22:55] <mwhudson> not totally flexible actually
[22:56] <mwhudson> would "fetching 1000 revisions 2/2345" "fetching 1000 revisions 5/2345" and then stopping at 1000/2345 make sense
[22:56] <mwhudson> or "fetching 1000 out of 2345 revisions 4/1000" ?
[22:56] <mwhudson> i guess the latter
[23:04]  * thumper afk
[23:19] <james_w> wgrant: did you have to anything special with python-debian to get it working under 2.5?
[23:21] <wgrant> james_w: I don't believe so.
[23:21] <wgrant> james_w: Hm. You may have to reinstall/reconfigure it after installing the 2.5-capable python-support and python-central.
[23:21] <james_w> oh
[23:22] <wgrant> Although I thought the PPA's python-support was modified to automatically compile modules when adding a new supported version.
[23:22] <james_w> I wasn't aware that I needed python-support to change as well as python-defaults for it to work for 2.5
[23:23] <wgrant> james_w: You're not fully upgraded from the PPA?
[23:23] <james_w> no
[23:23] <james_w> I have it pinned at 50
[23:23] <wgrant> Heh. Good luck with that.
[23:24] <james_w> well, I don't mind the troubles when it helps me understand what's being added
[23:37] <mwhudson> thumper: does "fetching 1000 out of 5354 revisions 880/1000" look better to you?
[23:38] <wgrant> mwhudson: that doesn't give any indication of overall progress. "fetching 1000 revisions from revision 3000: 3521/9876", maybe?
[23:46] <mwhudson> not sure that that information is terribly accessible
[23:50] <lifeless> nested pb
[23:50] <lifeless> outer one you know - you control it
[23:50] <lifeless> inner is bzr driven
[23:51] <lifeless> write a custom UI to log this to wherever your 'show to the user' stuff goes
[23:56] <mwhudson> er
[23:56] <mwhudson> we already do most of that
[23:56]  * wgrant should really learn this bzr thing one day.
[23:59] <lifeless> wgrant: anytime you want, tutorials on demand