[00:31] <cody-somerville> Ugh, there appears to be a pretty serious bug with the launchpad import system. I just created a new import and it made me the owner instead of the vcs import team.
[00:32] <cody-somerville> Is it safe to make the vcs import team the owner?
[00:34]  * cody-somerville will ask for forgiveness later.
[00:34] <cody-somerville> ugh, I did it mid-import too
[00:34]  * cody-somerville hopes for the best.
[01:01] <lifeless> cody-somerville: why would you want the vcs import team to be the owner?
[01:01] <lifeless> cody-somerville: its your import
[01:01] <lifeless> jml: ^
[01:02] <cody-somerville> me being a member of vcs-imports aside, I don't want to accidentally push to my import which I imagine would cause problems the next time the importer runs and tries to import new revisions
[01:15] <jml> cody-somerville, you can't, I don't think. It ought to be r/o
[01:16] <cody-somerville> which is why I thought the branches were owned by vcs-imports
[01:16] <cody-somerville> Is there another mechanism now that makes them r/o?
[01:17] <wgrant> They're import branches, not hosted branches. They're Special.
[01:19] <cody-somerville> The UI should reflect that.
[01:19] <mwhudson> cody-somerville: they've always been read-only for reasons other than team membership
[02:11] <thumper> cody-somerville: does the UI not reflect that?
[02:11] <thumper> cody-somerville: I'm pretty sure it says it is updated by the code import service
[02:44] <cody-somerville> I'm not the only person to be confused by this change.
[02:45] <cody-somerville> I believe james_w mentioned this the other day as well
[02:45] <cody-somerville> I thought it was only "r/o" cause of the team who owned it
[03:08] <mwhudson> rockstar: https://code.edge.launchpad.net/~mwhudson/launchpad/recipe-model-code/+merge/16272
[03:34] <al-maisan>  Bug #506617
[03:34] <mup> Bug #506617: make Builder._findBuildCandidate() operate across all build farm job types <buildfarm> <Soyuz:In Progress by al-maisan> <https://launchpad.net/bugs/506617>
[03:38] <al-maisan> jtv: http://pastebin.ubuntu.com/355856/
[03:59] <jml> lifeless, do you have access to pqm.launchpad.net any more?
[03:59] <lifeless> no
[03:59] <lifeless> I mean
[04:00] <lifeless> I can see the web page
[04:00] <lifeless> :P
[04:00] <jml> lifeless, right. I meant special access.
[04:03] <mwhudson> jml: pjdc has access
[04:03] <mwhudson> but will require handholding
[04:04] <jml> mwhudson, it would be the blind leading the blind with me
[04:05] <jml> mwhudson, who'd know what they were doing?
[04:05] <mwhudson> i guess i know a bit
[04:05] <lifeless> its documentef
[04:06] <mwhudson> i wrote the documentation!
[04:06] <lifeless> some of it:)
[04:07] <jml> the bits with apostrophes :P
[04:07] <mwhudson> i wrote it for the crummy launchpad specific stuff that's currently falling on its arse
[04:07] <lifeless> :)
[04:43] <jamesh> now that you've got lots of users, do you really need the test suite any more?
[04:43] <jamesh> surely with many eyes, all the bugs will be shallow
[05:15] <stub> My wadl explodeth
[05:16] <mwhudson> stub: make clean
[05:16] <mwhudson> then try again
[05:16] <stub> Done
[05:16] <stub> And failed again
[05:16] <mwhudson> hm
[05:16] <stub> File "/home/stub/lp/replication/lib/lp/code/model/branchjob.py", line 134, in BranchJobType
[05:16] <stub> File "/home/stub/lp/lp-sourcedeps/eggs/lazr.enum-1.1.2-py2.5.egg/lazr/enum/_enum.py", line 100, in docstring_to_title_descr
[05:16] <stub>     assert not lines[num+1].strip()
[05:17] <mwhudson> stub: i just submitted my schema patch to pqm with a further change
[05:17] <mwhudson> stub: to whit, this: http://pastebin.ubuntu.com/355888/
[05:18] <mwhudson> stub: i hope this is ok :-)
[05:18] <stub> mwhudson: No problems there
[05:18] <jml> \o/
[05:18] <mwhudson> stub: great
[05:23] <stub> I think rockstar's landing broke db-devel. My launchpad/devel is building fine, my db-devel is failing unable to build wadl, that is the only landed patch on that branch since the last db-devel buildbot build and he touched branchjob with is similar to the area in the wadl generation that explodes.
[05:24] <stub> And reverting that patch fixes things
[05:31] <rockstar> stub, it went through ec2 just fine.
[05:31] <stub> It hasn't yet
[05:31] <rockstar> stub, no, I mean I sent it through ec2
[05:31] <stub> Oh... not buildbot
[05:31] <stub> hmm
[05:31] <stub> Anyone else reproduce this locally?
[05:32] <rockstar> stub, trying now.
[05:32] <rockstar> I just did a make clean and a make.
[05:33] <stub> On your branch, or your branch merged with latest db-devel?
[05:33] <stub> Your patch might be victimized by some other update, like a lazr changes.
[05:34] <rockstar> stub, oh noes, it's broken here now too.
[05:35] <stub> version.cfg changed recently - probably passes with old dependencies but fails with current.
[05:35] <rockstar> stub, I think I know what this is.
[05:36] <stub> The assert above seems to suggest a docstring not conforming to some standard, but neglects to produce a meaningful error message.
[05:36] <rockstar> stub, yes, it's not conforming to the Enum standard.
[05:36] <rockstar> stub, I've got a fix.  It's just whitespace.  Can I have your rs, or should I pastebin?
[05:36] <stub> rs
[05:37] <rockstar> stub, thanks, sending fix now.
[05:42] <rockstar> stub, fix is off to pqm
[09:05] <wgrant> noodles775: Only that one failure, it looks like. Thanks for running it.
[09:05] <noodles775> wgrant, yeah! Great work!
[09:06]  * wgrant works out where that logger is coming from.
[09:07] <noodles775> G'night.
[09:23] <mrevell> Mornin' all
[14:12] <flacoste> morning launchpadders
[14:25] <mars> morning flacoste
[16:05] <sinzui> bac: call me when you are ready for our meeting.
[16:13] <bac> sinzui: ok
[16:50] <salgado> beuno-lunch, any chance you could help me figure out why the text is not centered (bug 506581) in the OOPS page?
[16:50] <mup> Bug #506581: oops template page is out of center <ui> <Launchpad Foundations:New for salgado> <https://launchpad.net/bugs/506581>
[16:58] <beuno> salgado,
[16:58] <beuno> sure
[17:08] <beuno> salgado, it seems to be related to the CSS combining
[17:08] <beuno> trying to pinpoint the style to blame
[17:09] <salgado> beuno, I was confused because everything there seems to have a "text-align: center" (according to firebug, at least)
[17:10] <beuno> salgado, yeah, it claims that body hast text-align: center
[17:12] <beuno> salgado, it's coming from /* lazr/build/yui/cssgrids/grids.css */
[17:12] <beuno> body{text-align:center;margin-left:auto;margin-right:auto}
[17:12] <beuno> so, it's a matter of order
[17:13] <beuno> I'm also pretty sure that the oops page didn't load that CSS before at all
[17:14] <salgado> that's correct
[17:15] <beuno> salgado, so we can either override it in that template specificall (a hack) or port it to one of the new master templates
[17:16] <beuno> one that uses the yui-* CSS clases
[17:16] <salgado> I'll try porting it then
[17:17] <salgado> but it doesn't use any
[17:17] <salgado> it's a standalone template
[17:17] <beuno> salgado, you could add the CSS clases manually then
[17:17] <salgado> beuno, what classes are needed?
[17:18] <salgado> yui-u and yui-g?
[17:18] <beuno> salgado, I don't remember them by heart, but use on the main div the same class used on the one-column layout template
[17:18] <beuno> sinzui, do you remember them?
[17:20] <sinzui> yui-u and yui-g as stated, and there are yui-t4 and yui-d0 setup in base-layout
[17:30] <salgado> sinzui, beuno, but do I need yui-u and yui-g on a page which has only one section with a few paragraphs of text?
[17:31] <beuno> salgado, I think not
[17:32] <sinzui> salgado: certainly not
[17:32] <sinzui> salgado: those are only needed to create columns
[17:33] <intellectronica> beuno, allenap: sent my notes and mockups on the ui changes we want to do for making bug syncing more reliable. your comments etc
[17:33] <allenap> intellectronica: Cool!
[17:33] <beuno> intellectronica, wooo, will look
[17:36] <salgado> sinzui, any idea what classes I need to use on the oops template to make it looks nice again? (https://bugs.edge.launchpad.net/launchpad-foundations/+bug/506581)  that page now includes cssgrids.css (from yui), so it looks awful
[17:36] <mup> Bug #506581: oops template page is out of center <ui> <Launchpad Foundations:New for salgado> <https://launchpad.net/bugs/506581>
[17:42] <sinzui> salgado: know, but I suspect that yui-reset is the culprit. I'll make an opps and see the markup
[17:43] <salgado> sinzui, https://translations.edge.launchpad.net/ubuntu/hardy/+source/gnome-control-center/+imports?field.filter_status=all&field.filter_extension=potaaaa
[17:43] <salgado> (an oops)
[17:45] <sinzui> salgado: interesting becase https://edge.launchpad.net/~buy-viagra-online-q looks fine and the markup is similar. I think this may be an easy fix
[17:46]  * salgado sees yui-main and yui-b divs there
[17:50] <sinzui> salgado: we might be able to add a rule to the locationless but i see that this is not using base-layout. I think you can hardcode a text-align: left in the oops template or add structure that is left-aligned
[17:51] <salgado> sinzui, I placed a <div class="yui-d0"> around the main content there, which seems to have fixed the text alignment
[17:53] <sinzui> okay
[17:53] <salgado> sinzui, beuno, thanks a lot for the help!
[18:01] <rockstar> morning
[18:01] <rockstar> Has anyone looked at the build failures?
[18:03] <sinzui> rockstar: I suspected that the failures were in the layer, not the specific tests
[18:03] <sinzui> rockstar: I think those tests are wrongly reported to have left the layer dirty
[18:03] <rockstar> sinzui, it looks like two of them might be, but the code import stuff is probably a valid failure.  I won't see thumper for another two hours or so though.
[18:04] <rockstar> sinzui, yes, I think so.
[18:05] <rockstar> (thumper was working on the code import stuff yesterday)
[18:10] <beuno> mars, flacoste, EdwinGrubbs, what do you guys think about makign sprites horizontal instead of vertical?
[18:12] <mars> beuno, is there a reason why they are traditionally vertical?
[18:12] <EdwinGrubbs> beuno: do you mean combining them horizontally in the giant consolidated image?
[18:12] <beuno> EdwinGrubbs, yes, so they don't show up with multiple lines
[18:12] <EdwinGrubbs> beuno: does that mean that you will need to space them out 1920 pixels for users who maximize their windows?
[18:12] <beuno> mars, the only reason I made the vertical is because images get loaded from top to bottom
[18:13] <beuno> EdwinGrubbs, well, I can't think of any scenario where we would push it horizontally like we do vertically, so I don't think we'd need a crazy amount of spacing at all
[18:15] <deryck> beuno, ping
[18:16] <beuno> deryck, hi
[18:20] <mars> beuno, IIRC GIFs compress best vertically, thus GIF sprites should be vertical.  However, I can not find anything that says PNGs have the same limitation.
[18:21] <beuno> mars, so that would be a good measure, make sure it's not significantly bigger
[18:21] <beuno> in size
[18:49] <kfogel> intellectronica: still online?  question about mapping back from an attachment -> bug -> bugtask (which I'm not sure is possible, so I may have to rearrange data flow here)
[18:52] <kfogel> deryck: if you have a sec, I'd hit you with the same question I just asked intellectronica above
[18:54] <deryck> you want to get to the bugtask from the attachment?
[18:54] <deryck> kfogel, ^^
[18:55] <kfogel> deryck: right, and I'm not sure that's possible (since you can't convert a many-to-one mapping back to one of the many, if you know what I mean).
[18:55] <kfogel> Am I unduly pessimistic?
[18:56] <kfogel> deryck: the core code in model/bugtarget.py is:
[18:56] <kfogel>     @property
[18:56] <kfogel>     def patches(self):
[18:56] <kfogel>         """See `IHasBugs`."""
[18:56] <kfogel>         lst = []
[18:56] <kfogel>         for bugtask in self.all_bugtasks:
[18:56] <kfogel>             for attachment in bugtask.bug.attachments:
[18:56] <kfogel>                 if attachment.type == BugAttachmentType.PATCH:
[18:56] <kfogel>                     lst.append(attachment)
[18:56] <kfogel>         return lst
[18:56] <kfogel> So I'm using the bugtasks to get to the attachments, but the information about which bugtask it was is thrown away.
[18:57] <kfogel> (I mean, there are solutions; I just want to know if I'm analyzing correctly.)
[18:57] <deryck> kfogel, what is patches a method of?  what is "self" in other words?
[18:57] <kfogel> deryck: HasBugsBase
[18:59] <kfogel> deryck: and http://paste.ubuntu.com/356183/ has in-progress bugtarget-patches.pt I'm working on, when I realized the problem (i.e., that I couldn't necessarily get "status" or "importance" from a bug, I had to get it from a bugtask)
[19:01] <deryck> kfogel, ah, ok, I see what you are wanting to do.  Yeah, there is no way to get back from patch to bugtask.
[19:01] <deryck> kfogel, I think it would be better to use searchTasks and get tasks with patches, and operate on those tasks.
[19:02] <kfogel> deryck: cool, I'll go in that direction.  I'm actually kind of pleased, at least, to discover that what I thought was the problem *is* in fact the problem.  That's not always the case!
[19:04] <kfogel> deryck: (note that searchTasks doesn't seem to offer that, but that's okay, the code I pasted in-channel above can easily get a list of tasks with patch attachments; in fact, it already does, all I have to do is not throw the information away.)
[19:05] <kfogel> oh, nm, there's a has_patch=foo on searchTasks
[19:08] <deryck> kfogel, you can't use searchTasks with has_patch?
[19:08] <kfogel> deryck: see my "oh, nm" above
[19:08] <deryck> ah, sorry :-)
[19:08]  * deryck only looks at the red in xchat
[19:09] <kfogel> deryck: how much longer you on for?  (So I can time likely-to-produce-questions activities vs other stuff.)
[19:10] <deryck> my EOD is top of the hour coming up.  But I can hang around some after that.
[19:10] <deryck> kfogel, ^^
[19:10] <kfogel> deryck: *nod* thx
[19:10] <deryck> kfogel, np
[19:10] <kfogel> deryck: so where I can find a reference of all the tal: macros available?  I've just been cutting and pasting from other .pt files, making educated guesses, so far.
[19:13] <deryck> kfogel, I just cut-n-paste and guess myself ;)
[19:14] <kfogel> deryck: thought that might be the universal answer, np :-)
[19:14] <deryck> kfogel, I don't think we have a reference, and all the zope refs on tal on I find are pretty basic
[19:14] <kfogel> ok
[19:16] <kfogel> deryck: easy one for you: in this excerpt from the .pt file (http://paste.ubuntu.com/356188/) what's the Official Right Way to convert the bug ID to a link?  I'm betting that just handcoding an "<a href=..." is not how the cool kids do it.
[19:18] <kfogel> (I know it will need to be tweaked later, when we use a task instead of a patch, but that's okay)
[19:20] <deryck> kfogel, grep for fmt:link
[19:20] <kfogel> deryck: thx
[19:25] <beuno> intellectronica, still around?
[19:27] <beuno> deryck, maybe you can help. In Tom's mockup of a remote bug, would that be a bug that was imported from another bugtracker, and is read-only in LP?
[19:27] <beuno> where can I see one today?
[19:27] <deryck> beuno, haven't looked closely at what Tom sent... let me look.
[19:46] <intellectronica> beuno: just got back. the mockup is of a new page for a bugwatch. that is, launchpad's representation of a remote bug
[19:46] <beuno> intellectronica, cool, deryck filled me in, thanks. I'm replying to your email. Great work  :)
[19:47] <intellectronica> beuno: it doesn't carry any interesting data regarding the bug itself, but we'd like to have it so that users can help more with monitoring checkwatches
[19:47] <intellectronica> cool
[19:48] <beuno> intellectronica, and any change to the bug page itself?
[19:48] <beuno> just the icon, right?
[19:48] <intellectronica> beuno: just to the representation of a bugwatch (basically, the icon). haven't mocked that up, though
[19:49] <intellectronica> beuno: what do you think about making it link to the new bugwatch page, instead of to the remote bug directly. i'm unsure about it myself. ot1h it will be annoying to some users, otoh i really want to make people pay attention to bug syncing. i'm really looking for a better idea, actually
[19:50] <beuno> intellectronica, I thought about it
[19:51] <beuno> I think it's not the best  thing to do
[19:51] <beuno> it will dectract from the usefuleness of it, no?
[19:51] <beuno> I am thinking, however, on how to best link to the new page
[19:53] <beuno> intellectronica, what if
[19:53] <beuno> *if* it failed
[19:54] <beuno> we should a link to the bugwatch page next to it?  "() gnome-bugs #32241 (edit bugwatch)"
[19:54] <mup> Bug #32241: Distro release source package release page is empty <Soyuz:Fix Released> <https://launchpad.net/bugs/32241>
[19:54] <intellectronica> yes, that's another option. but being inconsistent about where you link to is also quite annoying
[19:54] <intellectronica> oh right, that's a nice option i didn't think about
[19:54] <beuno> intellectronica, edit icon?
[19:54] <intellectronica> it will be a bit hard to cram it into the bugtasks table, but maybe a pencill icon?
[19:54] <beuno> :)
[19:55] <intellectronica> synchronicity
[19:55] <beuno> it would be a slightly different page than you may expect, but it could be a good compromise
[19:55] <beuno> not super sure that would be enough to entice people into fixing it
[19:55] <intellectronica> then the only problem that's left is, how do you get to the bugwatch page if it's not broken?
[19:55] <beuno> we could leave the edit icon there always
[19:56] <intellectronica> well, there's not much that people can do to fix it other than letting us know
[19:56] <beuno> true
[19:56] <beuno> but
[19:56] <beuno> there's the tip of a thread there
[19:56] <intellectronica> the problem is, in the context of the bugtask row, edit means 'edit this cell'
[19:56] <beuno> how about being controversial
[19:56] <beuno> and linking to filing a question?  :)
[19:57] <intellectronica> yeah, that's definitely something we can do. next to the broken sync line
[20:00] <beuno> intellectronica, I think it's shaping up nicely
[20:00] <beuno> I'll reply to the email with other nitpicks as well
[20:01] <intellectronica> beuno: cool. i still want to add a graph like the ones deryck just added too
[20:03] <beuno> intellectronica, I always get excited about tracking progress
[20:04] <intellectronica> beuno: oh yeah? what does it say about you? ;)
[20:04]  * intellectronica hides
[20:07] <beuno> intellectronica, that I'm a good fit for a company like Canonical!  :p
[20:35] <jml> thumper, buildbot compile failed
[20:35] <thumper> jml: I don't grok that
[20:36] <jml> thumper, buildbot was building five minutes ago. it's not any more, because the compile step failed.
[20:36] <thumper> jml: on db-devel?
[20:37] <jml> thumper, yeah, db_lp
[20:37] <thumper> jml: make fails due to soyuz code move
[20:37] <thumper> I am fixing
[20:37] <jml> thumper, ahh, ok.
[20:37] <jml> thumper, man, those sounds must get annoying
[20:37] <jml> thumper, really
[20:37] <jml> thumper, really
[20:37] <jml> thumper, really
[20:37] <jml> thumper, annoying
[20:39] <wgrant> bigjools: Does it really?
[20:46] <jtv> al-maisan:
[20:46] <jtv> https://code.edge.launchpad.net/~jtv/launchpad/bug-500110/+merge/17272https://code.edge.launchpad.net/~jtv/launchpad/bug-500110/+merge/17272
[20:46] <jml> jelmer, SourcePackageRecipeBuildJob
[20:47] <jml> thumper, tell me where the branch is, and I'll review it.
[20:47] <thumper> jml: it's a coming
[20:47]  * mwhudson wants to know too, so i can test my branch again...
[20:58] <wgrant> jtv: https://code.edge.launchpad.net/~wgrant/launchpad/lp-buildd-generalisation
[21:01] <cody-somerville> wgrant, Whats that? :)
[21:01] <cody-somerville> wgrant, it looks interesting
[21:01] <mwhudson> ec2 land can feel like throwing a dart at a dartboard and hoping the dartboard is still there in four hours
[21:05] <jml> mwhudson, hahaha
[22:05] <bac> mwhudson: i like your analogy but i think it is more ephemeral, like playing whack-a-mole and hoping the mole pops up in four hours just before you swing.
[22:05] <mwhudson> bac: :)