[00:30] <kfogel> sinzui: any way to get launchpad to re-evaluate a .py file without restarting?  I'd save a lot of time as I make little edits to, say, lib/lp/bugs/model/bugtarget.py.
[00:50] <kfogel> BjornT: .pt --> HTML formatting question: I've got <td class="importanceUndecided">Undecided</td> in my output, but the Undecided is still not showing up in any particular color.  Is there something more I need to do?
[00:54] <kfogel> BjornT: never mind; trick is use tal:attributes="class string:importance${task/importance/name}" instead of tal:attributes="class string:importance${task/importance/title}"
[00:54] <kfogel> (And why would I think BjornT is actually awake right now anyway?)
[01:20] <jml> kfogel, because he's in NZ :)
[01:20] <kfogel> jml: zing!
[01:21] <kfogel> jml: Do I win the Company-Wide Awareness Award for this month yet?
[01:23] <jml> maybe.
[01:25] <mwhudson> bzr's setUp -> set_up for Server is breaking launchpad
[01:26] <kfogel> jml: What do you mean, someone else already got it this month?  Why wasn't I told??
[01:26] <mwhudson> 176 times so far
[01:29] <jml> kfogel, :D
[01:29] <jml> mwhudson, I told poolie so :)
[01:31] <mwhudson> yeah, i grumbled about it a bit when it landed
[01:31] <mwhudson> pretty boring change though luckily
[01:56] <poolie> hello jml, mwhudson
[01:56] <poolie> sorry
[02:00] <mwhudson> not a big deal
[02:03] <mwhudson> bug 404693
[02:03] <mup> Bug #404693: PPA ssh reset trigger can hang the buildd-manager indefinitely <buildd-manager> <soyuz-build> <Soyuz:Triaged by jelmer> <https://launchpad.net/bugs/404693>
[02:31] <poolie> mwhudson: by way of compensation, i'll do https://bugs.edge.launchpad.net/bzr/+bug/507710 if you like it
[02:31] <mup> Bug #507710: want bzrlib.initialize() to do all typical setup <api> <Bazaar:Confirmed for mbp> <https://launchpad.net/bugs/507710>
[02:37] <al-maisan> about:blank
[02:37] <al-maisan> jtv: https://dev.launchpad.net/Soyuz/Specs/BuilddGeneralisation
[02:37] <wgrant> jtv: https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally
[02:53] <al-maisan> jtv: I am about to add the logic collecting the buildd slave results to `TranslationTemplatesBuildBehavior` .. is that OK?
[03:06] <jelmer> jml: can you merge lp:~jelmer/launchpad/builder-behavior again?
[03:07] <jelmer> jml: Sorry, seems I forgot to push a rev
[06:49] <lifeless> what are the zope singletons/global thingies called again ?
[06:52] <lifeless> ah.. remembered. Utilities
[07:09] <lifeless> jml: launchpad still thinkgs you're in sydney
[07:26] <lifeless> loggerhead fail http://bazaar.launchpad.net/~jelmer/launchpad/subunit-formatter/revision/10160
[09:13] <mrevell> Morning
[11:00] <deryck> Morning, all.
[12:30] <jml> lifeless, I don't care.
[16:19] <sinzui> adiroiban: ping
[16:19] <adiroiban> sinzui: hi
[16:20] <sinzui> adiroiban: what is blocking the landing of your branch to fix bug 496352
[16:20] <mup> Bug #496352: Refactor DistroSeriesStatus to SeriesStatus <Launchpad Registry:In Progress by adiroiban> <https://launchpad.net/bugs/496352>
[16:20] <adiroiban> sinzui: I asked gmb to do a test and land it
[16:20] <sinzui> today?
[16:20] <adiroiban> sinzui: no
[16:21] <adiroiban> about 4 days ago
[16:21] <sinzui> I think your branch fixes some circular imports. Do you mind if I try to land it?
[16:21] <adiroiban> sinzui: nope
[16:21] <sinzui> thanks
[16:21] <adiroiban> but you must merge with devel before
[16:21] <sinzui> okay
[16:21] <adiroiban> and check if the merged changes
[16:21] <adiroiban> contains DistroSeriesStatus
[16:22] <adiroiban> and then do a full test again
[16:22] <sinzui> I'll do that
[17:14] <bac> sinzui:  i've been trying to figure out what i changed that made download file deletion by a proj admin break.  turns out it is broken in devel.  :(
[17:39] <lifeless>  jml :P
[17:52] <mrevell> have a good weekend all
[18:07] <sinzui> bac: excellent. Do you think it can be fixed in your branch? Should it be a separate branch?
[19:27] <bac> sinzui: i think a separate branch
[19:27] <bac> sinzui: unless you want me to continue chasing it
[19:39] <dobey> hi all
[19:40] <dobey> does the Prerequisite branch field on merge proposals work well for declaring that a branch in another project needs to land there, before this branch can land? or does it only work for other branches being merged to the same place?
[19:42] <salgado> dobey, the latter
[19:44] <dobey> salgado: that's what i thought. ah well. :)
[19:48] <dobey> salgado: if i filed a bug to request cross-project dependencies in merge proposals, how many years would it take to get implemented do you think? :)
[19:49] <salgado> dobey, no idea, but maybe abentley can answer that
[19:51] <abentley> dobey: You mean, proposing a branch for merging with a prerequisite branch from a different project?
[19:53] <dobey> abentley: yeah. like if i add new API to a more general library project, and in my other project that uses that library, i also make a branch that uses the new API, i don't want the latter sitting around without a proposal waiting for the former to land, but i would like some way to let reviewers know that it can't be reviewed without the other branch
[19:54] <dobey> without explicitly saying so in a comment, but something that can be checked via LP REST API and such
[21:21] <sinzui> bac: I think the +download delete file bug is because that view is heavily cached. I can see that the deleted rules are building the cache before as it runs. the cache should be built after the process.
[21:22] <bac> sinzui: yeah, i know the caching is the problem.  just haven't figured out the details yet
[21:23] <sinzui> bac:I updated bug 508085 with the call chain problem I see
[21:23] <mup> Bug #508085: Deleting files from +download still displays the deleted file <Launchpad Registry:Triaged> <https://launchpad.net/bugs/508085>
[21:24] <bac> thanks sinzui
[22:08] <abentley> dobey: I can't predict how long it will take to be implemented if you file it, but I can predict how long it will take to be implemented if you don't file it :-).
[22:09] <dobey> abentley: sure, i was just being facetious, because i know you guys have a neverending queue :)
[22:11] <abentley> dobey: Maybe the best way to express it in our model would be a dependency on a bug.  (There may be no merge proposal in the other project yet)
[22:12] <dobey> abentley: bug dependencies is another thing i definitely want to see, yeah
[22:14] <abentley> dobey: I actually a meant that the merge proposal would have a dependency on a bug.  I'd also like to see bug dependencies, but that's not something the Code team can do.
[22:14] <dobey> right
[22:15] <dobey> bug dependency might be weird/confusing though, given how bugs work in lp
[22:15] <dobey> as they can "affect" multiple projects/distros
[22:21] <cody-somerville> Bug dependencies would be so awesome.
[22:22] <cody-somerville> dobey, Not sure I see how. That feature is intended to indicate a single bug affects multiple projects and/or distributions (the latter probably being the motivation for the feature). Why do you think bug dependencies would be weird/confusing?
[22:25] <dobey> cody-somerville: if a bug affects multiple projects, how do i clearly know which fix my branch will depend on? ie, it probably affects both the project i depend on, and the project i'm developing, if i'm writing branches for both projects at the same time. so it would be weird to say that this branch fixes bug X, but also depends on a fix in bug X. in LP there's no clear way to distinguish what project is relevant for which the bug affects
[22:26] <cody-somerville> haha, forget I said anything. I got excited there and thought we were talking about dependency between bugs.
[22:27] <dobey> between bugs is probably clearer, but i could definitely see some confusion due to the multiple project/distro affects bits :)