[00:04] james_w: ooi, why pin the PPA? [00:04] maxb: I don't want to give free reign to LP developers when I am supposed to be testing the development release of Ubuntu [00:05] maxb: the closer I can stay to pure lucid the better, and the more I know about the changes made the better [00:05] The reason for needing python-support is because python-support disregards python-defaults and embeds its own version list :-/ [00:05] wow [00:05] fair enough, but the PPA's delta is small. It's mostly no-change rebuilds [00:06] yeah [00:07] it's not that it's an LP ppa specifically, but that it is an extra archive at all [00:52] mwhudson: any reason why "Modify worker/monitor/UI to handle partial success" task is still blocked for QA (on kanban)? [00:53] Ursinha: sorry for breaking the scripts! [00:53] * mwhudson hates wikis, by the by [00:54] thumper: no reason, fixed [00:54] mwhudson: awesome [00:57] mwhudson: lol [00:58] thumper: hi, you're the RM this cycle right? [00:59] Ursinha: aye [01:00] thumper: mwhudson, are you aware of this oops: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1518S10 [01:00] aha! [01:00] ... in doctests is greedy! [01:01] * thumper frowns [01:02] thumper: I saw about 400 of them on staging, in 02/26 [01:02] Ursinha: likely to be when codehosting was updated before the xmlrpc server or vice versa [01:02] Ursinha: that'll be the codehosting system not in sync with the appserver [01:03] Ursinha: as long as they are not happening now we should be good [01:03] Ursinha: what thumper said [01:03] thumper: mwhudson, that's fine, I' ll let you know if they start happening again [01:03] thanks :) [01:03] thanks [02:13] thanks :) [02:13] oops [02:13] :) [03:11] wow, the staging code import slave is _much_ slower than my laptop [03:11] we gots some old hardware here... [03:12] mwhudson: how do I debug a particular function? [03:12] with pdb [03:12] I'm in the harness [03:12] and I want to step through a function [03:12] thumper: put "import pdb; pdb.set_trace()" in it? [03:12] oh [03:12] i think pbb.run("f()") ? [03:13] * thumper grunts [03:13] it seems I need locals somewhere [03:13] or maybe pdb.runcall(f, a1, a2) [03:14] mwhudson, neat trick. [03:15] yup [03:15] * thumper steps through [03:16] thumper, if something blows up in the harness, you may also be able to use pdb.pm() to dissect the traceback. Haven't tried it though. [03:16] gah [03:17] * thumper files first bug [03:19] oh, cool [03:20] in ipython, "setting %pdb on within ipython will make it such that the pdb debugger will automatically be started at the point of an exception" [03:20] err, that should read '%pdb on', as the command [03:20] so that would work in the harness too [03:21] iharness, specifically [03:23] oh clucking bell [03:45] mwhudson: got a minute? [03:54] thumper: sure [03:54] (sorry for the delay) [03:56] * thumper finishes editing the wiki [03:58] mwhudson: I was just thinking about the bugs I've just filed [03:58] mwhudson: and how urgent they really are [03:58] * mwhudson looks at email [03:58] they have to do with the qa of the email stuff [03:59] mwhudson: also I've had an idea about oops 1521SMPSSH1 [03:59] thumper: 530455 looks like inspiring head-wall interaction [03:59] mwhudson: skype? [03:59] thumper: sure [03:59] thumper: is that the "None has no attribute close" one? [04:00] yeah [04:00] or no attribute write [04:00] er ok [04:33] * thumper -> dinner [04:45] * mwhudson eods === bjf is now known as bjf-afk [06:46] thumper: g'night [07:01] kfogel: night [07:01] * thumper EODs [07:15] wgrant: hey, have you come across this when trying to send a key to your local keyserver? http://pastebin.ubuntu.com/386801/ [07:16] * noodles775 checks if it's lucid-related... [07:16] noodles775: Yeah, Lucid-related. [07:16] There is a patch to pygpgme. [07:16] * wgrant finds. [07:16] Thanks! [07:16] I think it's attached to a bug somewhere, but I've just been passing it around for now. [07:16] OK, I'll update the wiki page. [07:17] http://pastebin.ubuntu.com/386803/ [07:17] Ta! [07:18] Bug #452194 [07:18] Bug #452194: Call to gpgme_check_version is required when using gpgme >= 1.2.0 [07:24] wgrant: any objections if we add an API to talk to you for all bug searches? no particular reason for asking... ;-) [07:24] Heh. [08:06] good morning [08:25] wgrant: my branch for the soyuz dev startup work is up for review. I *think* I found a way to attach a real GPG key automatically, but I'm not sure it's complete because the UI still says the key is missing. [08:26] jtv: Link? [08:26] wgrant: yes [08:26] https://code.launchpad.net/~jtv/launchpad/bug-527170/+merge/20433 [08:27] wgrant: gets your fingerprint by running gpg --fingerprint [08:28] jtv: I'd prefer it if it took it as an argument. [08:28] But let me read. [08:30] * wgrant wonders why GPGKeySet.new() takes a person *ID*. [08:30] wgrant: it seems to be a pattern in soyuz [08:30] I've seen it before [08:30] La la la GPG isn't really Soyuz. [08:31] (Okay, I remember seeing it *once* before but by the bluffer's guide that makes it a pattern) [08:31] The occasional part of Soyuz does it for performance reasons, though. [08:31] rv42 [08:31] ahem [08:35] It's odd that that doesn't work. [08:35] Does it actually get added to the table? [08:42] wgrant: yes, it shows up as added to the test account (I called it ppa-user), but when I click through to it, I get a page saying that the key was not found [08:42] This may be because I'm not originally getting the key from zeca, I suppose. [08:42] Ah, yes. [08:42] It's a page on keyserver.launchpad.dev, right? [08:43] Hm, but GPGHandler is meant to use zeca, isn't it? [08:44] wgrant: I believe so, yes [08:45] wgrant: at least I got around the CoC signing trouble by inserting a CoC signed with a fake key. [08:45] Right. [08:47] that should save a bit of aggro all by itself, though it's not really germane to the rest of the gpg goings-on [08:47] good morning Launchpadders. [08:47] jtv: Yeah, although it's easy with the admin console. [08:47] hi jml! [08:47] By the way, the CoC infrastructure sucks. [08:48] heh [08:48] one battle at a time :) [08:48] wgrant: har har [08:48] lifeless: Hm? [08:49] CoC..sucks [08:49] Heh. [08:49] (unintended) [08:50] *sigh* [08:50] Uhoh. [08:50] What's happened now? [08:50] wgrant: puerile humour has happened [08:50] Ah. [08:50] jtv: oh noes. [08:50] I _could_ add here a reference to the gay & lesbian rights group of the same name, but [08:50] okay, I admit it: I couldn't think of a good one [08:52] * wgrant must try Landscape at some point. [08:55] morning dudes [08:56] jtv, just the man I need to speak to [08:58] uh-oh [08:59] bigjools: I do have a standup coming up I believe, so we may have to work around that, but otherwise might as well try to strike while the iron is hot [09:00] lifeless, wgrant: for the record, I'm a big fan of puerile humour. I really was sighing only over my failure to come up with a good one. [09:00] jtv: really quick - is there a way to make PG return a zero as a default value to a query? [09:00] COALESCE(expr, 0)? [09:01] bigjools: what wgrant said [09:01] That means "expr, or if it's null, 0." [09:01] parfait [09:01] Works for any number of args. [09:01] I suck at sql [09:01] thanks [09:01] SELECT COALESCE(min(id), 0) FROM MyTable [09:03] wgrant: to test, run ./utilities/start-dev-soyuz.sh *first* (I'll be updating the docs) and then ./utilities/soyuz-sampledata-cleanup.py using the --email option to provide your real email address. [09:04] I think I'll rename that latter script to reflect its expanded scope. [09:09] jtv: The first seems better as a Makefile target. [09:09] * wgrant backs up his DB and tests. [09:09] wgrant: cool idea... I'm thinking one step at a time though, since I'm also learning in the process. [09:10] otp now [09:11] k [09:16] security.py is too slooooow. [09:18] Good morning [09:18] wgrant: while you're waiting for that, I'm off the phone [09:18] hi mrevell! [09:18] Hi jtv :) [09:19] wgrant: as for making that script a make target, I think it's a good idea. One problem is setting up the right email address. [09:19] jtv: I mean the soyuz-starting one. [09:19] wgrant: oww [09:20] I don't think the other one makes sense. [09:21] wgrant: before turning that into a make target I'd like to see some more robustness... have separate targets for "make sure service foo is running," that sort of thing. [09:21] Right now it just fails somewhere along the line if something's already running. [09:21] Not good for make targets. [09:21] Hey jtv, have you already included the removal of the sample build (id:8) that is currently building on bob in the sample data? [09:21] jtv: See for example 'make run_codehosting' [09:21] noodles775: Good idea. [09:22] noodles775: if that one wasn't in w's original, I don't think I did [09:22] It wasn't. [09:22] jtv: ok, it'd be great to do... if you don't have time, I'll do it as a followup. [09:22] Then I didn't. [09:23] noodles775: I've already submitted my branch for review; I'm sure it needs more work, but I want to keep the chunks manageable. [09:23] Probably because I classically ran it before starting a buildd, so buildd-manager detected that the builder was offline and unassigned the build. [09:24] jtv: no worries, I'd be happy to add it later :), thanks for simplifying the whole process! [09:24] wgrant: that make target looks useful... is there any documentation that's easier to read than the source and specifies how it deals with already-running daemons? [09:24] noodles775: glad to see you jump in! [09:24] jtv: bin/run is buildout evil. Kill it with fire. [09:25] wgrant: did I mention I caught a whiff of certain patterns sometimes? :-) [09:26] Excellent, it added my correct test key. [09:27] wgrant: if you click through to it though, you'll see that knowledge of it is not complete and I have no idea whether that's likely to be an immediate problem. [09:27] Where are directories normally created? [09:27] /var/tmp/poppy and /var/tmp/zeca should probably be added there. [09:28] wgrant: I added that in the start-soyuz script [09:28] jtv: Ah, right. We should probably work out how to do all this properly. [09:29] wgrant: ideally, yes, though the effort should be commensurate with use. [09:30] jtv: Ah, that 404 is just because zeca is pretty braindead. [09:30] It doesn't do indices; if you replace 'index' with 'get' it will work. [09:31] wgrant: whoo! [09:31] any easy way we can fix it up? [09:31] Not really. [09:32] Oh well. I'll admit to being selfish here: if it works, I have bigger fish to fry. [09:32] Or should I admit to being shellfish? [09:32] zeca didn't even take uploads until a little over a year ago. It was a really trivial thing that just served files. [09:32] Heh. [09:32] It works, just the link won't. [09:32] I think it'll do for now. [09:32] \o/ [09:33] Actually, I remember now that zeca didn't originally actually work as a full dev server, but I patched it so it would. [09:33] I must have just decided that that wasn't worth fixing. [09:33] so it never really works in dev? [09:34] The link on the person index doesn't, no. [09:34] But the internals will all work fine. [09:35] btw it turned out that GPGHOME gets set somewhere to a tmp directory, and that's why it was hard retrieving real-world keys. [09:37] Why does that make it hard? [09:38] I couldn't figure out why I wasn't finding any keys using pygpgme [09:38] Don't you retrieve them from the server? [09:38] No, ultimately I forked off a gpg _with the variable removed_. [09:38] I tried the --home-dir option, but that didn't do the trick for some reason. Maybe I used it wrong. [09:39] Oh, so you're not sending the key to the server? [09:39] In that case it won't work. [09:39] I guess mine just already had it. [09:40] gah [09:44] wgrant: I'll see if I can delete my key from zeca and re-test [09:45] jtv: rm /var/tmp/zeca/* [09:45] wgrant: what about zeca.test? That's where most of the stuff is. Or is that _only_ the links to the keys that come in ftests? [09:48] jtv: I believe that's only used in the test config. [09:53] wgrant: you were right :( [09:53] key not found [09:54] wgrant: so... how _do_ I get that key into zeca? [09:55] jtv: gpg --keyserver keyserver.launchpad.dev --send-key DEADBEEF [09:55] I thought that was in the docs. [09:55] wgrant: ah yes, so it is [09:55] I just couldn't place it in the larger picture [09:55] Ah, right. [09:55] (from my perspective, all that's missing is the ritual goat sacrifice) [09:55] Heh. [09:55] Anyway, not too hard I'd say! [09:55] It all makes perfect sense to me now! [09:56] a good ritual goat sacrifice can really work wonders can't it? [09:56] Always. [09:59] wgrant, jtv: what have I missed? http://pastebin.ubuntu.com/386876/ [10:00] noodles775: ./scripts/publish-distro.py -C [10:00] ta. [10:00] I appear to have not added that to the docs. [10:01] wgrant: It's there, I just missed it as I had to go back and forth a bit (initially had a corrupt chroot). [10:01] Ah, I see, it's only htere after the first build, where as it needs to be run before. [10:01] wgrant: is it safe to assume that the key id is always the last 4 octets of the fingerprint? [10:01] noodles775: Yeah. [10:02] jtv: That's what it is, so yes. [10:02] cool [10:02] jtv: But you can also --send-key the fingerprint. [10:02] even better :) [10:02] I just don't, because I'm lazy. [10:02] But code has a convenient attribute of not being lazy. [10:05] should we have told noodles775 that he also missed the goat sacrifice? [10:05] Just a thought. [10:05] Possibly. [10:05] noodles775: Have you done this before? [10:05] oh, please do... [10:06] Nope, just going through for the first time (so I can test some stuff locally). [10:06] Aha. [10:06] Only a couple of people have used it, AFAIK. [10:07] Although it's a lot more streamlined now. [10:16] Building happily now, thanks wgrant/jtv. [10:16] * jtv points at wgrant [10:18] * wgrant points back. [10:19] arg, still failed (chroot problem) http://pastebin.ubuntu.com/386885/ ...but that's just because the package I'm testing with is targeted at security right? [10:19] noodles775: Ah, yeah, you can't target to security. [10:19] OK. [10:20] Unless there's a full copy of the archive somewhere that I don't know about apart from drescher. [10:20] Er, cocoplum. [10:20] * wgrant is stuck in the past. [10:25] mrevell, hi [10:25] hi jml [10:25] mrevell, sorry I missed our call. for some reason my calendar didn't buzz at me [10:26] jml, No worries. I'd heard a rumour you were sprinting at Millbank. [10:26] mrevell, no, I'm just at Millbank [10:26] mrevell, there's a decorator doing my room at home, so I can't work there. [10:27] jml, Ah right. I can do a call now, if you're available. If you don't mind, I'll just grab a tea first, though. [10:27] mrevell, yeah. me too. [10:27] wgrant: looks like security.py does a lot of needless name-dropping. I mean, it seems to drop a lot more users than it needs to. [10:28] stub, is that right? reset_permissions in security.py seems to try and drop every user from every group. [10:30] well, from only two groups actually [10:31] wgrant: sending the key seems to be working [10:32] jtv: Great. [10:35] mrevell, whenever you're ready [10:35] jml, Cool, just sorting Skype. [10:37] mrevell, when I said "skype was ok" [10:37] :) [10:43] jtv: Yes. It is a dumb implementation that needs improving. [10:43] jtv: That along with revoking all permissions and regranting them means live updates are pretty much impossible and the script is a low slower than it needs to be. [10:43] stub: for now I'm really just curious if that'd cost significant time, or whether it's a harmless good-enough implementation. [10:46] Its not harmess as it means we have to do security modifications manually. If it was smart enough to only apply the changes, we could run security.py against the live database without causing all the active sessions to bomb. It is also slow, as when you scale that up to 150 tables that is an awful lot of queries to issue (slower still when you need to quadruple that to run on all replicas) [10:46] mrevell, you've dropped out. should I call you on a landline? [10:47] If that's okay jml, will message you a number [10:47] (although the first bit we could probably fix by doing things in a single transaction now I think of it) [10:53] stub: sounds like an interesting challenge. I know you mentioned it months ago as something I could tackle. [10:53] IIRC there's only one commit in that script, though maybe it gets called from a loop somewhere [11:04] Morning, all. [11:11] hey Deryck [11:26] bigjools: are you still busy, or do you have time to talk about PPA download stats? [11:27] wgrant: busy as in looking at this security vuln [11:27] but we can talk [11:28] bigjools: Ah, no, you have better things to do :) [11:28] heh :) [11:28] wgrant: any suggestions on how to tackle it are welcome ;) [11:28] I've only just literally opened up the file in question to look [11:29] oh and don't talk about it on here of course [11:29] Of course. [11:35] lifeless: help! When I do branch, subdir = Branch.open_containing(url) ; export(branch.basis_tree(), '/tmp/foo') from my LP branch, all I ever seem to get is the LP source tree. Shouldn't that give me the branch at "url"? [11:51] noodles775, hello [11:52] Hi jml [11:52] noodles775, I'm now finally looking at the fourteen emails I've got about build from branch since I went to PyCon [11:53] noodles775, and I thought, maybe it'd be easier just to talk with you :) [11:53] jml: sure, call in 10mins? [11:53] noodles775, perfect. === matsubara-afk is now known as matsubara [13:00] jtv, ping [13:00] deryck: good evening [13:00] jtv, there's a bug from you on the malone 10.02 milestone... still in progress. But I think you finished this. Can you look at it and update the status or move it off? [13:01] deryck: will do [13:01] jtv, thanks [13:02] deryck: that one disappears with a lazr-js upgrade, so I'll have to go after that. [13:04] I think. :/ [13:08] jtv, I just did an LP branch updating to latest lazr-js. So once it lands that should be fixed then. [13:08] deryck: on closer inspection, this looks like it was one that still had a mystery problem. :( [13:09] jtv, ah, ok. Do you think you'll look at it again? If so, let's move to 10.03. if not, we can un-milestone and take it out of progress. [13:09] deryck: I ended up being stumped IIRC. Better to let the next volunteer try. [13:10] jtv, that works. Thanks for looking into it initially, though. [13:11] deryck: good luck with the little bastard :) [13:11] heh [13:11] thanks [13:16] james_w: Hi, are you free for a call regarding the mockups? [13:16] (at some point). [13:17] sure [13:17] either now or after lunch? [13:18] james_w: if you're going to lunch now, then after is fine, otherwise now is good for me. [13:18] I would be going for lunch in 30 minutes or so [13:18] depends how much you have on your mind :-) [13:18] Perfect, I only expect a 10min call :) [13:19] nice [13:19] noodles775: I successfully set external_dependencies, but aren't they supposed to show up in the UI? [13:19] I'll hold you to that ;-) [13:19] :-D [13:19] jtv: yes, I would have expected them to. [13:19] noodles775: I checked in "make harness" as well as the db, and I really have a string in there. Need a newline at the end maybe? [13:21] noodles775: I should make your skype make silly noises? [13:21] jtv: I'd check what's being passed to the form for the UI (in browser/archive.py). It might have something to do with the expanded_dependencies field, I haven't checked. [13:21] james_w: calling now. [13:21] gmb, there is a launchpad-users email question about timeouts with +filebug, saying this is on edge.... [13:21] noodles775: thx [13:22] gmb, I'm a little suspect of it, though, because it looks like the old timeout message, and we should be async now, right? [13:22] deryck: I've replied [13:22] gmb, ah, ok. go, you! :-) [13:22] deryck: If the user has JS disabled then they'll still hit the timeout with long bug titles. [13:22] ah, right. that makes sense. === daniloff is now known as danilos === mrevell is now known as mrevell-lunch [14:08] gmb: so, i'm trying to create bug heat calculation jobs. i haven't figured out a way to do this with sql only, so i'm writing a script. but it occurred to me that maybe you do know of a way of doing that with just sql. any hints? [14:09] intellectronica: Er... Lemme have a think for a sec. [14:10] intellectronica: So, no, I can't think of a SQL-only way to do it I'm afraid. [14:10] Because the job table is quite complex. [14:10] (Alhtough the BugJob table is stupidly simple) [14:10] gmb: oright, so a script creating jobs using the model object is the sensible way to go [14:11] intellectronica: Yes. [14:11] intellectronica: Though... how many are you planning to update? [14:11] gmb: cool, thanks [14:11] Erm, why can't it be done with SQL? It's just math, isn't it? [14:11] gmb: i was thinking of updating all bugs for malone [14:11] is that unrealistic? [14:11] intellectronica: Okay, sure, that sounds pretty sane. [14:12] intellectronica: To clarify, do you want SQL for creating jobs or just for updating heat? [14:12] Cos updating heat is easy peasy. [14:12] (As persia just pointed out) [14:13] gmb: no, i want to create jobs, because i want it to go through the webapp code and trigger recalculateMaxBugHeat too [14:13] intellectronica: Right, fair enough. Just checking that I understood properly [14:16] intellectronica, will this trigger max_bug_heat across all projects, or only for malone? [14:16] by "trigger" I really mean "update" :-) [14:16] deryck: only for malone [14:17] intellectronica, so maybe generate one job for any ubuntu bug, too, so we can see max_bug_heat updated for ubuntu bugs and check display of that, too. [14:17] deryck: ok, makes sense [14:17] intellectronica, thanks [14:27] jpds: take a look at bug 181298 that I do not think you have seen. It may be invalid now [14:27] Bug #181298: Get rid of DistributionMirror.official_candidate [14:31] using the API to add a tag on staging isn't working, any chance that this has broken server-side? [14:32] ah, it's ok, lists are odd in the LP API and I'm doing it wrong [14:33] james_w, hehe, yes, .append is not working, you need to overwrite the list [14:35] hey thekorn [14:35] thekorn: are you able to easily reproduce bug 336866? [14:35] Bug #336866: When adding tag or updating description, lp_save() gives "HTTP Error 412: Precondition Failed" [14:35] I'm having difficulty [14:37] ok, I can do it with a newMessage call and manipulating tags, but not just tag manipulation === salgado_ is now known as salgado [14:39] james_w, yes I can reproduce this bug sometimes, but it is not clear to me under which condition this is reproducible [14:41] bug.newMessage seems to alter the bug, but it doesn't cause a refresh of the bug object [14:41] james_w, one of my ideas (as descibed in https://bugs.edge.launchpad.net/launchpadlib/+bug/341950/comments/2) was that the http_etag attribute is not updated properly [14:41] Bug #341950: lp_save gives HTTP Error 412: Precondition Failed when adding a comment to a bug, but adds the comment anyway [14:41] but I don't see why that should affect just changing tags === mrevell-lunch is now known as mrevell [14:49] argh, someone killed staging ;) === Ursinha is now known as Ursinha-lunch [15:11] hmm [15:22] sinzui: hi, for bug 527728, the component name should be exported as „component” , „component_name” or „latest_published_component_name” ? [15:22] Bug #527728: Export source package component in API [15:25] adiroiban: I think component_name is correct [15:25] * sinzui looks [15:26] mrevell, where's that terminology wiki page? [15:27] jml: https://dev.launchpad.net/PlainEnglish ? [15:27] adiroiban: are you adding support to publish the component object, or flattening the data to return the string? [15:27] adiroiban, thanks. [15:28] sinzui: flattening to return a string... since IComponent has only one attribute [15:28] the name [15:28] jml, Took me a while to find as I gave it a stupid name. Thanks for getting it adiroiban :) [15:28] adiroiban: SP.latest_published_component_name [15:29]