=== jamalta-afk is now known as jamalta === jamalta is now known as jamalta-afk === jamalta-afk is now known as jamalta [07:40] good morning launchpadders [07:40] G'day :) [07:41] Morning. [07:41] jml: Back on the wrong side of the world? [07:41] wgrant, indeed [07:41] Hey wgrant ! [07:41] where it is deliciously toasty warm [07:41] rather than bloody hot. [07:42] yeah, I had +50C difference from getting on the plane in syd and off in Berlin... [07:42] Sydney was revoltingly humid when I passed through it today. [07:42] But not too hot, fortunately. [07:43] noodles775, not quite a 40C difference for me [07:47] jml: Your branch isn't going to land for 10.01, I guess? [07:47] no. a test failure in db-devel sank it, I'm afraid. [08:22] * thumper waves [08:24] * al-maisan waves back at thumper [08:30] thumper, hi :) [08:34] bigjools, good morning. [08:34] eyup jml [08:36] jml: bummer about your branch but it's not the end of the world [08:37] bigjools, yeah. I know. [08:38] just frustrating. [08:39] yeah the TZ was against us [08:39] db-devel was buggered most of Friday here >:( [09:01] good morning [09:02] moin adeuring [09:02] hi al-maisan! [09:03] adeuring: how are things? Did you go skiing after all? [09:04] al-maisan: yeah, I went for a day to Winterberg ten days ago or so. But last week I was sprinting, so no chance fos a trip to Sauerland... [09:05] ah, I see .. not much snow in AL I guess? [09:06] al-maisan: naaa, no snow. just the opposite, it was quite warm :) [09:06] :) [09:10] bigjools: How is buildd-manager on dogfood looking? [09:10] wgrant: fine as of Friday [09:10] but I will re-test today anyway [09:11] There is still that odd logging problem, but production doesn't log DEBUG anyway. [09:14] wgrant: is there a bug that describes that problem? [09:14] yeah I forgot which problem [09:15] we have so few problems :P [09:18] Since the refactoring during the sprint, the loggers retrieved by code called within BulderGroup (not in BuilderGroup itself, but other stuff that it calls) do not appear to actually log anyway. [09:18] s/anyway/anywhere/ [09:18] I suspect that there is some Twisted logging evil going on somewhere, but I've not looked at it in depth. [09:27] wgrant: there's 2 possibilities. 1, blame twisted, 2, the logging only exists for some crack tests [09:28] (which check debug output) [09:28] The output is useful for debugging, though. [09:29] (as we saw at the end of the sprint, where I had to put print statements everywhere because the logging wasn't working) [09:29] yes [09:31] wgrant: in another of my twisted programs: from twisted.python import log; log.startLogging(sys.stdout) [09:52] are people experiencing problems with the QA plan generator? ours seems to be missing many entries [11:05] Morning [11:11] deryck, good morning === matsubara-afk is now known as matsubara [11:37] danilos: hi. regarding bug 127171. It is OK if Ubuntu Translation Coordinators have launchpad.translationsAdmin right for IDistribution ? [11:37] Bug #127171: Rosetta experts not allowed to "Change translators" [11:38] this change was done when we set the launchpad.translationsAdmin rights for POTemplates [11:38] adiroiban: not sure [11:38] but not sure if we should keep it :) [11:41] oh, you meant danilos ;) He'd know better. [11:41] adiroiban: but i have not yet seen him today [11:42] the change was done together with IDistroSeries and IPOTemplate [11:43] ok. will wait for Danilo and see what can be done [11:44] I talked about this bug with jtv ( Hi!), but it looks like Danilo did not agree with our aproach :) [11:47] and hi adiroiban :) [11:48] i was asking Danilo about bug 127171. Will wait for him to come online... [11:48] Bug #127171: Rosetta experts not allowed to "Change translators" [11:57] adiroiban, henninge: sorry, long phone call :) [11:58] adiroiban, so, why would you want that privilege for UTC on Ubuntu? do you imagine changing a translation group often (or ever)? [11:58] danilos: nope. but this is the current code [11:59] adiroiban, right, so it's about simpler implementation, right? [11:59] so I was asking if its ok the remove UTC from IDistribution [11:59] adiroiban, that might be a good reason to let UTCs do it :) [11:59] and leave only for IDistroSeries and IPOtemplate [12:00] adiroiban, where exactly do UTCs use their privileges on IDistribution otherwise? [12:00] :) not sure [12:00] the change, was one of my first branches [12:00] when I didn't know to much about LP [12:01] right now [12:01] adiroiban, yeah, I can't think of anything myself right now [12:01] UTC can change lang-pack admins [12:01] but not sure if it vital [12:01] adiroiban, there is one thing that they should have, and that is setting translation focus [12:01] as lank-pack admins are per distribution [12:02] not sure if UTC can do that now [12:02] adiroiban, right, I think that makes sense and there is a future need for having them administer more things in a distro (like setting focus; they can't do that yet) [12:03] then we should keep the permission? [12:04] I'm still learning about Zope, and I am not sure what are the best practices for implementing fine grain permission policies [12:04] adiroiban, so, with all that in mind, I'd say let's just let UTCs change the group as well, just so we don't have to introduce another permission for them [12:04] ok [12:16] heh heh [12:16] no one knows what the best practices are for implementing fine-grained permission policies in Zope. [12:20] :) [12:20] jtv: regarding bug 121520 , don't know if we can have it for this release [12:20] Bug #121520: Language pages show merged accounts [12:20] adiroiban: ah, OK... I should've asked you first. Can I assign it to 02? [12:21] I am not sure why it is not working on edge [12:21] thumper: jml: you might find bug 388325 interesting to fix :) [12:21] Bug #388325: branches linked in bugs are hard to use from bzr [12:21] I have a testcase where I'm creating a merge account [12:21] lifeless, I don't fix Launchpad bugs. [12:21] and everhing is ok [12:21] lifeless, but thanks :) [12:21] jml: :) [12:21] jml: no but you get to provoke things [12:21] adiroiban: both ways around? [12:21] jtv: so I will need help for this bug [12:22] jtv: both ways? [12:22] lifeless, my provoking powers are exactly the same as your own. [12:22] its unclear to me whether it should be a malone or a lp-code bug [12:22] adiroiban: I don't know the first thing about account merging but istm that it's asymmetric [12:23] jtv: well, I asked gmb, he reviewed the branch [12:23] jtv: I have merged_account.merge = realaccount [12:24] adiroiban: oic... there's no asymmetry between the accounts you're displaying then. [12:24] btw I say "account" but in this case I guess you want "person" [12:24] * jml afk [12:25] jtv: sorry, person [12:25] I did it too :) [12:28] adiroiban: it's not a doubly-merged account or anything? [12:29] jtv: don't know what is a doubly-merged account :) [12:29] adiroiban: e.g. foo-merged is merged with foo-old and foo-old is merged with foo, and you get to see both foo-merged and foo? [12:29] no [12:30] as before the commit there was not foo-old [12:30] just foo [12:30] and foo-merged [12:31] adiroiban: ah, and you're simply not displaying merged accounts at all... [12:31] yes [12:31] the code was working on my local system , [12:32] adiroiban: I'm looking at the diff for your branch, but afaict it simply doesn't touch the template for the page that the bug links to as an example. [12:32] I will have ask somebody to look again over the testcase [12:32] adiroiban: the diff fixes pofile-details.pt and pofile-translate-contributors.pt, but the bug links to a *language* pas an example. [12:33] jtv: isn't that lib/lp/translations/templates/pofile-translate-contributors.pt [12:33] but the language is including the `portlet` [12:33] adiroiban: nope... I wouldn't have noticed except the fix in the diff inserts commas between names, which the example page for the bug doesn't do [12:34] so I think the same fix is needed in language-portlet-top-contributors.pt [12:35] thanks! :) [12:35] (BTW odd that the text says "top 20" even when there are fewer than 20 people) [12:35] adiroiban: the devil is in the details. :) [12:36] adiroiban: what I would do is Q/A the fix for the other pages as best you can, and file a new bug for the remaining one. [12:37] Which also means we can keep this one targeted for 10.01. [12:38] well... now that those pages got me into trouble, and that I know a little bit more about Zope, I would no hurry and try to see if I can refactor that code into a macro [12:39] and next time just change it from one place [12:39] adiroiban: if you can improve it, great. But you've already landed the incomplete fix, right? [12:39] yes [12:39] the current branch is landed [12:40] And as far as we know, it didn't actually break anything, so we can treat this as an incomplete fix and have a separate bug for "clean up this fix and add one more template." [12:40] Add one more template to the places you fix, that is> [12:40] ok [12:41] filling the new bug [12:41] adiroiban: the good news is that you probably did fix the bug in a lot of places. :) [12:42] yes :) ... but failed to fix the link from the report [12:45] adiroiban: btw, I'm fixing up the milestones for bugs that are assigned to you but not targeted to milestones... did your fix for bug 135008 roll out before the new year? The commit date is the Sunday before release. [12:45] or seems to be [12:45] Bug #135008: "Languages in Launchpad" page doesn't auto-focus search field [12:46] jtv: not sure about how, if and when my branches were landed on production [12:46] adiroiban: nm... it looks like it may well have landed earlier [12:48] yep [12:48] maybe it went togheter with Henning changes for the langauges page [13:07] beuno, around? [13:08] mars, hey [13:08] hey beuno [13:24] I've noticed that lp:launchpadlib is lacking in tags - I've pushed lp:~maxb/launchpadlib/with-tags with added tags based on diffing the released tarballs. - It's not a merge per se, but should I file a MP nonetheless? [13:32] maxb, I guess. Maybe it's better to just ask leonardr? :) [14:08] Ursinha: ping [14:08] sinzui: hi [14:09] Ursinha: https://dev.launchpad.net/RegistryTeam/RegistryTestPlans/10.01 was not updated with my last branch that landed in db-devel. [14:11] sinzui: which revision is that? [14:11] Ursinha: r8923 [14:11] sinzui: it's there [14:12] * sinzui blinks [14:13] Ursinha: thanks. I will drink more coffee. [14:16] kfogel, btw, I downloaded Sita Sings the Blues, and have distributed pirate copies to my friends. [14:18] jml: alas, there is no piracy with Sita Sings the Blues. I hope you all enjoy it despite this! :-) [14:18] kfogel, I tried watching it last night, but I fell asleep (it was really good, but it had been about fifty hours since I last slept in anything better than an economy seat) [14:18] kfogel, oh no, you don't understand. [14:19] jml: heh, understood. I won't tell nina. [14:19] kfogel, I put on a funny hat and eye patch and said "Yarrr", then I copied it legally. [14:19] .oO ("understood" referred to something other than that which jml said I didn't understand) [14:19] Ah! [14:19] beautiful [14:19] that I WILL tell Nina :-) [14:36] maxb: i'm not sure what you mean by tags in this context [14:36] OOPS-1486EA603 [14:36] leonardr: "bzr tags" [14:36] hm [14:43] maxb: i've actually never used bzr tags. it looks like you use them to mark released versions? is that what your branch does? [14:43] (i'm just asking from curiosity; you should definitely file an mp) [14:44] Yes. I'm surprised, because this is the first project I've come across which doesn't tag versions [14:44] Without them, how do you answer questions like "Is this revision included in that release tarball?" ? [14:45] maxb: i've been using bzr log. and no one has corrected me since i'm the only person who's had to answer those questions [14:45] maxb: tags are a better solution [14:45] It wasn't obvious to me browsing the log messages exactly where the releases were [14:45] maxb: well, you are the second person :) [14:45] it's not a scalable solution [14:47] maxb: give me the mp and i'll review it. i hope it hasn't caused you too much trouble [14:48] No, it's fine. I'll do a MP === salgado is now known as salgado-lunch [14:58] sinzui, ping [14:59] Hi mars [15:00] hi sinzui. Just reading your mail reply, and wondering what the goal of CSS bug filing procedures is? Is it to "get them fixed", or to "get them triaged"? [15:01] Mars: Get them triaged. The triaged state tells us roughly how it will be fixed an release [15:01] sinzui, and if the latter, then can you safetly assume that the filing engineer already knows everything about the CSS bug needed to set that priority? Or is there a risk of them mis-prioritizing, and a more formal filing would prevent that? [15:04] sinzui, I guess I'm missing the original problem that this idea is meant to solve. Were there a whole bunch of 'New/Undecided' CSS bugs building up that we wanted to triage? [15:04] mars:an engineer knows if there is datalose it an impossible impediment to completing a task we say can be done...CRITICAL, assign an engineer and create a CP. [15:04] Or the problem is an OOPS, a impediment that many users cannot work around, or is a series goal...High assign it to a milestone, find an engineer [15:04] Otherwise it is low, engineers will fix it when there is a oportunity [15:05] mars: the problem is that we had High bugs without anyone assigned to fix or a date to see them fixed [15:06] sinzui, ok, so is the goal is fixing said bugs? Or re-prioritizing them, so they are triaged correctly? [15:07] Triage always involves repriorisation of bugs as we discover new information, the code change, and our goals change. Items we thought were High were not high after we ignored the issue for many month [15:08] mars: consider that the emergence of Chrome required us re-triage and fix many webkit bugs because it doubled the number of affected users in a few months [15:09] sinzui, ok, still not understanding how this CSS bug filing procedure relates to that. I thought it was just a way to keep new CSS bugs from slipping through. [15:10] Most the recent css bugs we fixed were for webkit [15:10] I fixed 4 this release [15:11] ok [15:11] bac and deryck were discussing one that they did not know was CSS [15:13] mars: If someone cannot do the triage, then he should not, but I think launchpad engineers can determine severity and priority for most bugs in the span of a minute. If he can take time to report a bug, surely he has thought about the impact on users and our own commitments [15:17] intellectronica, deryck, is it known that bug index pages are timing out pretty much consistently? [15:17] Ursinha, yes. [15:17] Ursinha: oh yes it is. i've got a fix in review [15:17] what he said :-) [15:17] intellectronica: oh, awesome then :) [15:24] hi guys [15:25] i'm trying to run tarmac for one of my projects, and launchpad keeps giving back 502 or 503 errors (usually 502) [15:26] dobey: rockstar might be a good person to ask === matsubara is now known as matsubara-lunch === Ursinha is now known as Ursinha-lunch [16:03] intellectronica: it looks like the failure is from the call of branch_merge_proposal.createComment() [16:03] intellectronica: did that API change in some way that's not documented properly? === salgado-lunch is now known as salgado === gary_poster changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.01 | PQM is closed | gary_poster is release manager | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu.com/ | Edge bugs searching is timing out, use lpnet === matsubara-lunch is now known as matsubara === beuno is now known as beuno-lunch [17:38] adeuring: hey, thanks for fixing that ec2 failure in 506018. Shall I just merge your change into my branch? === matsubara is now known as matsubara-afk === beuno-lunch is now known as beuno === gary_poster_ is now known as gary_poster === henninge_ is now known as henninge === Ursinha-lunch is now known as Ursinha [18:38] * jml is gone. === matsubara-afk is now known as matsubara === gary_poster is now known as gary-lunch [19:34] thumper: good morning [19:35] thumper: going to the drs this morning, will miss stand up === Ursinha is now known as Ursinha-bbl === EdwinGrubbs is now known as Edwin-lunch [20:35] morning people [20:37] * thumper goes hunting for his headset === matsubara is now known as matsubara-afk === salgado is now known as salgado-afk === gary-lunch is now known as gary_poster [21:03] Whats the URL to the buildd farm these days? [21:06] cody-somerville: you mean https://edge.launchpad.net/+builds ? [21:07] * cody-somerville nods. [21:12] gary_poster: project groups do not implement IHasBugs, right? I'm looking at lib/lp/registry/model/project.py:"class Project" and while I see some methods that say "See `IHasBugs`", the class as a whole does not seem to inherit from HasBugs. (Am I even asking the question in the right way?) [21:14] kfogel, they would implement the interface, which is a different spelling than inheriting from a class. I don't know the specific answer, but gimme a minute [21:14] gary_poster: *nod* [21:17] gary_poster: just for context: What this is really about is issue #506018, the new "+patches" view, which will be accessible from Product, ProductSeries, DistroSeries, DistributionSourcePackage, Distribution, SourcePackage, and eventually Person/Team. What I'm trying to figure out is, will we have to do any extra coding to get it working for Project Group too? [21:17] Bug #506018: Need a "+patches" view: report lists patches attached to bugs. [21:18] kfogel: I'm a bit too booked for context :-) but I'll try to answer your question, and show you how I did. [21:18] gary_poster: that helps, if you have time. thanks [21:21] kfogel: yes, it implements the interface http://paste.ubuntu.com/362878/ [21:21] gary_poster: looking [21:22] gary_poster: hey, that was a huge clue bat! Thank you. [21:22] np :-) [21:33] hmm [21:33] i still seem to be connected to irc [21:33] thumper: can you see this? === Ursinha-bbl is now known as Ursinha [22:05] When running make run I encounter a Couldn't find a distribution for 'zc.buildout==1.50.dev-gary-108342' message [22:05] bdmurray: update your download-cache [22:11] gary_poster: a bzr update in download-cache? [22:13] bdmurray: yeah. rocketfuel-get should do this for you. If you don't use this you are using the "advanced" path, at least for now. In any case, if your download-cache is a checkout (the way rocketfuel-get does it), use bzr up; if it is a branch, use bzr pull. [22:14] okay, I'm on 112 now without a change in behavior [22:14] hunh. is it expected that loading a branch like https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report will fail right now, with an error: [22:14] Please try again [22:14] Sorry, there was a problem connecting to the Launchpad server. [22:14] Try reloading this page in a minute or two. If the problem persists, let us know in the #launchpad IRC channel on Freenode. [22:14] Thanks for your patience. [22:22] kfogel: is it working now? [22:22] there was a blip [22:23] mwhudson: working now [22:23] good [22:31] mwhudson: I could see that [22:31] thumper: yeah, everything seems to be working again now [22:31] * thumper starts digging through the email mountain [22:31] good [22:32] thumper: i was worried that my isp had disconnected me a few days early... [22:32] heh [22:40] gary_poster: so I'm still receiving that error [22:42] bdmurray: hm. What I described is definitely the core problem, so we just need to make sure your download-cache is up to date. In the launchpad branch, cd to the download-cache (bzr gets confused otherwise, I have found). Then...do a bzr revno for me. I get 112. [22:43] gary_poster: yes, that's what I have [22:43] bdmurray: uh. [22:43] bdmurray: so, cd out of there, run bin/buildout, and put a pastebin up somewhere for me. [23:54] gary_poster: make build is failing as see at http://pastebin.osuosl.org/31259 [23:59] bdmurray: yours is an isolated problem, so I'm trying to figure out what it could be. The only thing this has ever indicated in the past is an out-of-date download-cache. I'm experimenting.