[00:04] wgrant: eh? [00:04] wgrant: launchpad.dev uses openid? [00:05] thumper: Yeah. [00:05] And edge will tonight. [00:05] why? [00:05] Because c-i-p is the new hotness. [00:06] cip? [00:06] canonical-insecurity-provider [00:06] and wtf is that? [00:06] login.ubuntu.com [00:18] thumper: the i is identity [00:18] Not after 48 hours. [00:18] wgrant: do we need to stop the rollout ? [00:19] wgrant: does this mean you can't create a user? [00:19] wgrant: locally? [00:19] thumper: The OpenID thing does, but that's easily resolved with the factory. [00:20] Just a little annoying that all this functionality is being pushed into an external proprietary application the development team for which isn't doing a very good job. === bjf is now known as bjf-afk === jamalta-afk is now known as jamalta [01:33] my current branch is 1600 revisions behind devel... :( [01:34] thumper: wheee [01:34] lifeless: and I merged trunk with no conflicts \o/ [01:36] nice [01:36] what vcs are you using ? :) [01:36] lifeless: perforce [01:36] heh [01:36] haha [01:36] NOT! [01:41] * mwhudson writes a LEP: using clearcase for launchpad development [01:41] mwhudson: E stands for enhancement [01:41] lifeless: spoilsport! [01:41] mwhudson: :> [01:46] Are Clearcase and Perforce really that bad? [01:46] I know VSS is, but I haven't had the pleasure of using the other two. [01:46] differently bad [01:46] not dataloss bad like vss [01:47] Pfft. Where's the fun in that? [01:47] wgrant: perforce is quite good [01:48] wgrant: clearcase is fcuking aweful [01:48] * thumper checks his spelling [01:48] no e [01:48] awful [01:48] horrible [01:48] makes you want to slit your wrists [01:49] so, a lphant then ? [01:49] perforce at least does what you expect [01:49] clearcase takes forever, slow, complex and doesn't always do what you want [01:50] doesn't even have atomic commits [01:50] Ew. [01:50] apparently it gained atomic commits in december 2009!! [01:52] mwhudson: really? [01:53] thumper: it's what wikipedia says [01:53] ok, didn't have atomic commits when I used it [01:53] which was 2006 [02:33] hmm. I get a different set of test failures on lucid to wgrant [02:35] maxb: What failed? [02:36] (this brings back bad, bad memories of mid-Karmic) [02:36] AppServerLayer oopsed all over the place, and I have one bugs windmill failure [02:37] Which Windmill test failed? [02:37] And what were the AppServerLayer oopses? [02:38] ohh.... wait a moment [02:38] it might work better if I had testopenid.dev in my /etc/hosts [02:38] Yeah. [02:39] the oopsing just gave me a load of 500 internal server errors, and nothing more helpful in a visible log [02:40] It'll be the OpenID XRDS hostname lookup exception. [02:44] hmm, so now I just have test_bug_tags_entry (lp.bugs.windmill.tests.test_bug_tags_entry.TestBugTagsEntry) [02:45] maxb: that passed here. What's the error? [02:45] * wgrant tries on recent devel. [02:45] rerunning, I suppose it could have been openid issues too [02:46] yeah, it's happy now [02:46] well, that's nice. Lucid here we come... next up python2.6 [02:47] maxb: Can you reproduce the two identical question-target.txt failures, and the test_ftparchive one? [02:47] question-target.txt did not fail for me [02:47] The question-target.txt one looks really odd -- the query should ensure order. [02:47] * wgrant reruns. [02:47] I see the ftparchive one [02:48] I haven't looked at that one at all. [02:48] I also need to test utilities/*, since some of it is broken. [02:49] oh, you mean the "You need to invoke update-sourcecode using the system python, not what its shebang says" problem? [02:49] yes. [02:49] And maybe others too [02:50] Have you had the bootstrapping issue lately? [02:50] I ran into it for the first time in weeks last night when trying the python2.6 branch. [02:51] I've been working in karmic still quite a lot [02:52] so no, I've not seen it [02:52] OK. [02:52] And what do you know, questiontarget.txt passes for me now. [02:53] Actually, the failure was on db-devel. [02:53] * wgrant tries there. [02:53] I would really love it if the DB and librarian data directories were per-branch. [02:55] doable [02:57] OK, questiontarget.txt works on db-devel too. [02:57] It must have just hated me yesterday. [02:57] * wgrant looks at test_ftparchive. [03:00] * wgrant vomits in the direction of lp.archiveuploader.ftparchive. [03:00] s/uploader/publisher/ [03:07] uhoh, postgres 8.3 just got kicked out of lucid - so much for launchpad-dependencies being installable [03:08] * maxb copies it back into the ppa [03:08] Urgh. [03:08] still, it seems that stub wants to move to 8.4 really soon. [03:10] I love how easy it is to use PPAs to rescue removed packages [03:11] Yeah, it's pretty handy. [03:11] ... pending publication on amd64 i386 powerpc sparc and ia64 :-) [03:12] not often you see the ppa build status column being stretched that far [03:12] No armel? [03:12] it ftbfs, apparently [03:12] Ah. [03:21] maxb: Oh. I just realised that questiontarget.txt does still fail on db-devel. I just had my test fix in place. [03:21] maxb: can you try it on db-devel? [03:29] AARRGGGHHHH!!!!! [03:29] YUI madness [03:34] * thumper heads to #yui [03:54] Anybone else running LP on Lucid? [03:55] wgrant: only under a chroot [03:55] poolie: That's fine. Could you please 'bin/test -vvt questiontarget.txt' in db-devel? [03:56] it will take a few minutes, but yes [03:58] wgrant: just to be clear, i mean in a karmic chroot on a lucid host [04:02] wgrant: do you still want it? [04:02] poolie: Oh, right. That's probably not what I want, then. [04:14] gaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaar [04:15] ? [04:15] Normally I would assume that was a JavaScript scream. [04:15] it's a zope scream [04:15] xml-rpc methods can't take *args [04:16] haha [04:16] sorry. [04:16] Better than lazr.restful methods, which can't take positional args at all. [04:16] 'omg I'm so surprised' [04:16] and it' [04:16] s basically because of stupid LBYL-ism [04:17] wgrant: i _could_ be writing js! [04:17] theoretically [04:18] Gngrg stupid doctests. [04:18] -D is almost completely useless with them. [04:25] Also, WTF. I have a test failure in db-devel on Lucid that does not appear in devel. It's an ordering difference, but executing the query manually in the transaction gets the right order. [04:32] lifeless: so it's bug 59846 [04:33] hullo bot? [04:33] * mwhudson EODs [04:33] http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/utilities is not opening [04:34] swarna: Go to http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel and browse to utilities/rocketfuel-setup from there. [04:35] poolie: well, that was about an earlier behaviour [04:36] poolie: I think perhaps the last subscriber can't unsubscribe. [04:36] is it? that looks like what we're hitting here [04:36] no, the bug in question had plenty of subscribers [04:36] Ah, it's private. That's why there's no bot. [04:36] and I've unprivated it. [04:38] how is having lots of subscribers relevant? [04:39] in reference to bug 59846, where we dealt with bugs having only one subscriber (the filer) due to a bug in the bug filing logic [04:40] i think kiko felt that bug was closed by dealing by cleaning up some particular cases [04:40] but the description says [04:40] > it seems wrong that (a member of) the *security contact* for a product can be prohibited from viewing a bug report about that product, whether they are subscribed or not. [04:40] and i agree with that [04:40] the underlying bug still exists [04:41] so, this isn't a quick topic, and I started 9 1/2 hours ago. [04:41] np [04:41] it's not urgent [04:41] i was just surprised [04:41] i understand what's causing this now, so thanks [04:41] you can followup on 59846 if you want [04:41] I appreciate you feel that there is a bug here; I don't see how to reconcile what you are asking for with CVE support and multiple organisations both contributing to one project. [04:42] the bug you found wasn't filed on bzr; it was half-connected to bzr, and should have been made unprivate at the same time [04:42] are you saying that's a case where there are bugs that affect a project, that the project's security team is not allowed to know about? [04:42] poolie: yup [04:43] as I understand it anyhow. [04:44] hm [04:44] two separate cases; also note that private and 'security' are nowadays separate flags. [04:44] well, nobody has yet made a case for that on that bug [04:44] so I wouldn't comment on bug 59846 regardless, I'd file a new one. [04:44] so it looks like just a plain bug [04:48] poolie: [meta] this looks like a case where a new bug would really have been better [04:48] yes, you said that [04:48] poolie: I've commented there anyhow [04:48] gnight [04:48] to me it seems like the underlying bug has not actually been fixed [04:49] poolie: it is deliberate, by design. Rejected would be a better term, for that aspect of it. [04:50] that may be true but nobody has actually said so [04:50] except you :) [04:50] and it sounds more like defense of an accidental behaviour [04:50] poolie: comment #2 describes it [04:51] I agree that a clear unambiguous statement wasn't made. [04:51] it's not actually the same thing [04:51] And I'm not in a position to do that either. [04:51] I'm just sharing the context and history I know of with you. Privacy was /agonised/ over. [05:30] wgrant: If the ordering is depended on but not explicit, its broken. implicit order is effectively random (you can't even trust it to come out in disk order, as it might get pulled from a cache). [05:55] stub: The order is in the query, sorry. [05:57] stub: What is the timeframe for moving to PostgreSQL 8.4? [05:57] stub: 8.3 is gone from Lucid now. [05:58] lifeless: (when you're back) [05:58] i don't think this is a critical bug [05:58] but it is pretty surprising [05:58] and i think there is some kind of bugginess here [05:58] it's internally inconsistent [05:58] What is the bug? [05:59] the security team can't see all bugs on the product [05:59] and, depending on the history of the bug, they may not get subscribed by default [05:59] for instance adding a new bugtask does subscribe them [05:59] As soon as possible. Last I looked, we had maybe three or four tests failing that looked trivial. I need to get slony 1.2.20 packages backported from lucid to hardy, at which point we can test staging and migration procedures. [05:59] retargeting an existing bugtask does not [05:59] Ah. Hm. [05:59] stub: Oh, excellent. [06:00] poolie: Really? I've found that moving a task explicitly subscribes the security contact even when the bug is public. [06:01] wgrant: Bug #426823 is tracking this [06:01] Bug #426823: Update to PostgreSQL 8.4 [06:01] wgrant: nup, definitely not [06:01] look at https://bugs.staging.launchpad.net/launchpad/+bug/453104 [06:01] Bug #453104: sftp user/password don't work [06:01] oh heh, you can't :) [06:02] but try now [06:02] If mup can see it, it's probably public... [06:02] it's public in reality, i changed it on staging [06:03] Ah. [06:06] * wgrant curses 64kbps throttling. [06:36] poolie: so I think this hinge on what 'security team' means [06:36] poolie: I think it means 'people to be told about new security bugs, by default' [06:36] I think that is the assumption. [06:36] k [06:37] poolie: I'm open to 'adding a product task to a secured disto bug should subscribe the product security team' [06:37] right [06:37] or retargeting a task [06:37] poolie: but that is very different to 'the security team can always see bugs' [06:37] right [06:37] and i dont' think it's specific to whether they're distro or product or series tasks etc [06:38] conceptually perhaps not [06:38] lifeless: so 'the security team should always see bugs' is a different bug [06:38] perhaps a closer match for this existing one [06:38] i'm kind of ok if that's marked wontfix [06:38] i would like there to be a public bug for it, as documentation [06:38] and explanation [06:39] i do think it's a bit weird that potentially absolutely no one from the product can see the bug [06:39] I think thats fine, but something we want to have happen explicitly not accidentally [06:39] It's handy if you want to hide a bug, like I did last week. [06:40] i mean some bugs seem to at least accidentally have got into this state [07:37] When does edge update these days? [07:38] wgrant: I didn't realise it had changed (but haven't been watching), so I'd assume between 8:30-9:00UTC? [07:38] noodles775: buildd-manager has again been broken for three or four hours. [07:39] noodles775: It probably hasn't changed. I just didn't remember. [07:39] wgrant: no losa? OK, they're still sprinting and probably having brekkie. [07:39] * noodles775 tries to find out. [07:40] * wgrant wonders if this actually happens quite often, but there's normally a LOSA around to respond to the Nagios scream. [07:41] wgrant: I don't think so, there's a note on their page to always let us know (which is why I keep the bug up to date). [07:41] noodles775: Ah, good. [07:41] If it is happening regularly now, it might be worth CP'ing the change so that it doesn't block the b-m. [07:42] It seems like it might be worth it to log all SQL queries executed by b-m to see if we can work out WTF is happening. [07:44] yeah, let's chat about that with bigjools. Great, the losa's are on it :) [07:45] Great. [07:59] wgrant: back to normal now, thanks to the losa's, and we'll check the sql log to see if it can point us back to a problem in the code. [08:00] noodles775, $LOSA: Thanks. [08:02] * wgrant has a look through the new code for anything suspicious. [08:02] It was the building build without a builder again, right? [08:17] good morning [08:27] wgrant: Thanks, and yes, a build_queue item that is dispatched (ie. has a related job with non-null date_started), but build_queue.builder is None. [08:42] noodles775: Do we have the state of build/buildqueue/job before it was repaired? [08:44] wgrant: other than the above, no, but I'll update the wiki page so that we have it next time. [08:44] noodles775: Great. [08:44] It might tell us where in the build it actually was. [09:00] g'morning [09:05] Morning bigjools. [09:06] hello europe [09:07] morning wellington [09:07] You know you're in trouble when the Americans (apart from deryck) show up. [09:08] wgrant: even more so for me i guess [09:09] haven't stayed up that late in a while [09:09] bigjools: Speaking of download stats... [09:10] heh [09:12] * mwhudson stares at buildbot, trying to figure out if his change will be in db-stable in time for the code import update in more than twelve hours time [09:14] mwhudson: In time to get the incremental import repo pull fix onto staging? [09:14] wgrant: exactly [09:17] moin mwhudson [09:17] hi wgrant [09:17] Morning jelmer. [09:17] jelmer: Are you running LP on Lucid? [09:17] wgrant, yep [09:18] jelmer: Can you 'bin/test -t questiontarget.txt' on db-devel, please? [09:18] jelmer: I get a strange ordering failure here, but not on devel, and I wonder if anybody else can reproduce it. [09:19] wgrant: ok [09:19] It's one of only two lucid test failures. [09:22] * jelmer hates how slow 'make schema' is on this machine [09:22] It's slow everywhere. [09:32] wgrant, running now [09:32] jelmer: Thanks. [09:35] wgrant, failing here too because of the ordering [09:36] jelmer: excellent except not. [09:36] "daf" is now the first entry rather than the second [09:36] jelmer: Yep, same failure is seen here. [09:37] But the query is explicitly ordered, and running it in that transaction gets the right result. [09:53] henninge: feel free to replace the intltool-debian line with plain intltool, or use them both. [09:54] jtv: I am still not convinced they are the same. [09:55] jtv: ah, now I see [09:55] henninge: when I wrote that line, I had no reason to care. I might as well have installed Quake and added a comment for you to replace it with the right package. :) [09:56] jtv: so why is it that you install it manually from the script and not just add a dependency to the package? [09:57] henninge: to what package? I didn't want to pull in another package for all slaves when we only need it for this one job. [09:57] Also, IIRC this gets installed into the chroot whereas the buildd package lives outside it. [09:58] jtv: oh, we have a chroot inside the buildd? [09:58] to build [09:59] henninge: yes, the slave sets up a chroot, and then sets up its build environment in there. That's what I did in translationtemplates.py [10:02] jtv: frankly, translationtemplates.py looks a bit over-engineered ... ;) Mind if I change it or is this some common pattern? [10:03] jtv: using a state machine this way, I mean. [10:03] henninge: that's how the base class wants it. The job runs asynchronously in twisted, so it doesn't hold everything up. [10:04] It is _possible_ to do the whole thing in one go, but not much easier. [10:04] And this way helps provide progress information, I believe. [10:05] You need to either use the state machine or have a single subprocess that does all of the work. [10:24] bigjools: Given the earlier discussion, I guess you don't have time to discuss PPA download stats today? [10:24] wgrant: next week would be better - I really need to get the rebuild work done [10:24] or maybe on Friday if I am done by then [10:25] Yep, OK. [10:25] I found some odd behaviour when testing them locally -- the binaries ended up in NEW. But it looks like it's OK on production. [10:28] Hm, rebuild archives have the same permission rules as PPAs when they're disabled. Damn. [10:33] bigjools: Is there a good reason for that, or can I submit a branch to fix it? [10:35] wgrant: which rule is a problem? [10:37] bigjools: Disabled copy archives are not accessible except by their owners and admins. [10:37] This is awkward, since they normally get disabled when they're done. [10:38] there's a bug about not being able to see them when they get disabled [10:41] Bug #488468 [10:41] Bug #488468: Disabled rebuild archives are not shown anywhere [10:42] there ya go [11:04] Morning, all. === jtv is now known as jtv-afk [11:26] BjornT, ping. [11:38] adeuring, hi. I think noodles775 suggestion about using real text and hiding it off screen is nice, assuming this does indeed play well with screen readers. [11:39] I say "assuming" not to question noodles775, just that I don't know much about screen readers. [11:39] deryck: yes and no. I think it is a bit like expoiting a bug in screen readers ;) [11:40] they should not present non-visible text, I'd argue [11:40] adeuring, hmmm, that would make me concerned then. img alt tags are the standard way to handle this. [11:40] deryck: that's my main point indeed. [11:41] adeuring, let me look closer at the comments in the MP again. [11:45] adeuring, did you see the link noodles775 provided? The webaim site notes pushing content off screen as an acceptable way to hide content. I would assume they know screen readers well. [11:45] deryck: no, I had not looked yet. [11:47] adeuring, it makes me confident in this approach, and using a sprite and a fmt'er would make this nicer to use in tal and for front-end performance. [11:48] deryck: well, ok. I am not 100% convinced, but it does not matter that much. === jtv-afk is now known as jtv [11:48] adeuring, ok, thanks. sorry to send you back to work again. [11:51] henninge: hi. when you have time, can you please take a look at the last comment from https://code.edge.launchpad.net/~adiroiban/launchpad/bug-509252-take-2/+merge/19484 [12:07] deryck: pong [12:43] Oh wow, a "here's your compensation from the Nigerian government for being scammed" Nigerian scam. === jtv is now known as jtv-eat [13:12] intellectronica: If you want to chat about a logarithmic scale for bug heat, I'll be free in 5. [13:12] gmb: excellent. i'm just firing an MP for my first branch and will ping you in ~5m [13:12] Cool. [13:14] www.search2.net [13:16] now that must be the mossad ^^^^^ [13:23] gmb: ready when you are [13:24] intellectronica: Cool. Skype? [13:24] gmb: yup [13:26] intellectronica, just FYI, I'm changing my max_heat branch to have max_bug_heat where the default is NULL not 0. [13:26] intellectronica, but you could review as is, and I can fix it up in my branch when merging in. === al-maisan_ is now known as al-maisan [14:44] intellectronica: hey, you're totally right about that targetName thing -- I feel dumb. Will fix, thanks. [14:44] cool [14:44] and it was easy to confuse that one [14:45] maybe it's even worth a comment, so that the next reader won't get confused. i nearly missed it myself [14:45] kfogel: ^^^ [14:46] intellectronica: well, I think the code will make it clear, since the used-visible display name is going to be generated instead of hardcoded. [14:47] intellectronica: maybe an explanation of why, though, yeah. [14:48] deryck: i didn't really update on my bug heat work. the branch for using max_heat is in review. i am now looking at scaling the results. went over it with gmb and we've reached the conclusion that just using a logarithmic scale is not obviously a good solution, so now i'm trying out a few formulas to see what makes sense. i'll try not to get stuck on that for too long and come up with something by the end of the day. it will be much easier [14:48] intellectronica, sounds good. thanks for the info. [14:49] intellectronica, sorry to leave you out, too. Still trying to find a good rhythm with the board. [14:50] that's oright. it's also not like the call is our one and only opportunity to update [14:50] right [14:50] i wonder if we can get a feed or something of the updates on the kanban and spew it here [14:51] intellectronica, there is RSS for the board. [14:51] it's nice how the kanban shows a notification when someone changes something, but you can't really follow it [14:53] yeah [14:53] we need some kind of commit email or something. [14:53] this would also make sharing in the open better. [14:54] flacoste, is there something like the above for the board? ^^ Or some way to come up with that. [14:55] deryck: there is [14:55] each line has an email icon [14:55] to subscribe to events there [14:55] there is also a RSS feed for the whole board [14:55] and there is an email notification option for the whole board also [14:55] look under the Options tab [14:56] ah, ok. thanks flacoste [14:56] intellectronica, see that ^^. You can subscribe your email to board events. [14:57] deryck: thanks. i'll give that a try. [14:58] I find the per lane rss or email useless, really. But the global option is nice. [14:58] ah, and i found out why i didn't see avatars. there's a global option to show or hide them [14:59] deryck, intellectronica: the option to turn off the white board markers is also nice to get more screen real-estate [14:59] ah, right. sorry. I didn't realize that was per user. [14:59] flacoste: indeed [15:00] yes, nice. [15:01] flacoste, I wonder if we couldn't have a generic user account and subscribe some email to all boards and have this go to a mailing list. Or something like this. === danilo__ is now known as danilos [15:01] flacoste, would make it less private. [15:01] deryck: they should implement a "public board" option soon [15:01] flacoste, ah, ok. cool. [15:20] intellectronica: new version of the branch pushed up. It was actually not as trivial to fix as I thought -- the uppercase/lowercase needs are different between the sort order display and the column name on the right, which wasn't an issue before. [15:21] intellectronica: anyway, review when ready [15:23] kfogel: looks good. r=me [15:23] intellectronica: thx [15:25] intellectronica: you think any need for UI review on this one? [15:25] * kfogel answers his own question [15:25] no. the ui change is trivial and unambiguously an improvement :-) [15:25] kfogel: never hurts, but since this was such a small change i don't think it's strictly necessary [15:26] kfogel: normally i wouldn't even ask for a first ui review for something like this, tbh [15:26] intellectronica: what, you mean for the whole feature? [15:26] i only added the keyword because we did discuss it a bit in the review [15:26] intellectronica: keyword? [15:26] * kfogel confused [15:27] intellectronica: where? [15:27] kfogel: for the whole feature definitely, but for something like the capitalization of the option in a combo ... depending on how confident i'd feel about the change [15:27] kfogel: keyword in the review signature. i used 'code ui'. [15:27] maybe it's called review type [15:28] intellectronica: oh, didn't refresh, didn't see that yet [15:29] intellectronica: so if I use 'ec2 land', it'll automatically use the commit message from the merge proposal, right? That is, I can just run 'utilities/ec2 land -v --headless -b launchpad=db-devel' ? [15:29] kfogel: if so then that's a complete surprise to me. i never used it like that. [15:29] hmmm. [15:29] let me know if it works for you :) [15:30] intellectronica: well, I don't want to risk a change landing with a bogus message. I'll ask around. [15:33] deryck: do you regularly use 'ec2 land'? [15:33] kfogel, I do [15:33] deryck: so the 'ec2 help land' text is a bit thin. I'm trying to figure out if, when a merge proposal has a commit text set (as https://code.edge.launchpad.net/~kfogel/launchpad/515584-fix-DRY-violation/+merge/19990 does) whether 'ec2 land' will automatically use that as the PQM submit message. [15:34] kfogel, it will. do `ec2 land --dry-run` and you can see what it will do. [15:34] deryck: and if so, whether it auto-generates the reviewer metadata "[r=foo][etc]" or whether it figures all that out from the merge proposal. [15:34] kfogel, it does [15:34] deryck: thx [15:34] kfogel, np === jtv-eat is now known as jtv [15:46] hey peeps === salgado is now known as salgado-lunch === matsubara is now known as matsubara-lunch === Guest5903 is now known as NCommander [16:56] could somebody review my branch for bug 527174? [16:56] Bug #527174: logo_link missing from "team" object in API