| thumper | wgrant: eh? | 00:04 |
|---|---|---|
| thumper | wgrant: launchpad.dev uses openid? | 00:04 |
| wgrant | thumper: Yeah. | 00:05 |
| wgrant | And edge will tonight. | 00:05 |
| thumper | why? | 00:05 |
| wgrant | Because c-i-p is the new hotness. | 00:05 |
| thumper | cip? | 00:06 |
| wgrant | canonical-insecurity-provider | 00:06 |
| thumper | and wtf is that? | 00:06 |
| wgrant | login.ubuntu.com | 00:06 |
| lifeless | thumper: the i is identity | 00:18 |
| wgrant | Not after 48 hours. | 00:18 |
| lifeless | wgrant: do we need to stop the rollout ? | 00:18 |
| thumper | wgrant: does this mean you can't create a user? | 00:19 |
| thumper | wgrant: locally? | 00:19 |
| wgrant | thumper: The OpenID thing does, but that's easily resolved with the factory. | 00:19 |
| wgrant | 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. | 00:20 |
| === bjf is now known as bjf-afk | ||
| === jamalta-afk is now known as jamalta | ||
| thumper | my current branch is 1600 revisions behind devel... :( | 01:33 |
| lifeless | thumper: wheee | 01:34 |
| thumper | lifeless: and I merged trunk with no conflicts \o/ | 01:34 |
| lifeless | nice | 01:36 |
| lifeless | what vcs are you using ? :) | 01:36 |
| thumper | lifeless: perforce | 01:36 |
| thumper | heh | 01:36 |
| lifeless | haha | 01:36 |
| thumper | NOT! | 01:36 |
| * mwhudson writes a LEP: using clearcase for launchpad development | 01:41 | |
| lifeless | mwhudson: E stands for enhancement | 01:41 |
| mwhudson | lifeless: spoilsport! | 01:41 |
| lifeless | mwhudson: :> | 01:41 |
| wgrant | Are Clearcase and Perforce really that bad? | 01:46 |
| wgrant | I know VSS is, but I haven't had the pleasure of using the other two. | 01:46 |
| lifeless | differently bad | 01:46 |
| lifeless | not dataloss bad like vss | 01:46 |
| wgrant | Pfft. Where's the fun in that? | 01:47 |
| thumper | wgrant: perforce is quite good | 01:47 |
| thumper | wgrant: clearcase is fcuking aweful | 01:48 |
| * thumper checks his spelling | 01:48 | |
| thumper | no e | 01:48 |
| thumper | awful | 01:48 |
| thumper | horrible | 01:48 |
| thumper | makes you want to slit your wrists | 01:48 |
| lifeless | so, a lphant then ? | 01:49 |
| thumper | perforce at least does what you expect | 01:49 |
| thumper | clearcase takes forever, slow, complex and doesn't always do what you want | 01:49 |
| thumper | doesn't even have atomic commits | 01:50 |
| wgrant | Ew. | 01:50 |
| mwhudson | apparently it gained atomic commits in december 2009!! | 01:50 |
| thumper | mwhudson: really? | 01:52 |
| mwhudson | thumper: it's what wikipedia says | 01:53 |
| thumper | ok, didn't have atomic commits when I used it | 01:53 |
| thumper | which was 2006 | 01:53 |
| maxb | hmm. I get a different set of test failures on lucid to wgrant | 02:33 |
| wgrant | maxb: What failed? | 02:35 |
| wgrant | (this brings back bad, bad memories of mid-Karmic) | 02:36 |
| maxb | AppServerLayer oopsed all over the place, and I have one bugs windmill failure | 02:36 |
| wgrant | Which Windmill test failed? | 02:37 |
| wgrant | And what were the AppServerLayer oopses? | 02:37 |
| maxb | ohh.... wait a moment | 02:38 |
| maxb | it might work better if I had testopenid.dev in my /etc/hosts | 02:38 |
| wgrant | Yeah. | 02:38 |
| maxb | the oopsing just gave me a load of 500 internal server errors, and nothing more helpful in a visible log | 02:39 |
| wgrant | It'll be the OpenID XRDS hostname lookup exception. | 02:40 |
| maxb | hmm, so now I just have test_bug_tags_entry (lp.bugs.windmill.tests.test_bug_tags_entry.TestBugTagsEntry) | 02:44 |
| wgrant | maxb: that passed here. What's the error? | 02:45 |
| * wgrant tries on recent devel. | 02:45 | |
| maxb | rerunning, I suppose it could have been openid issues too | 02:45 |
| maxb | yeah, it's happy now | 02:46 |
| maxb | well, that's nice. Lucid here we come... next up python2.6 | 02:46 |
| wgrant | maxb: Can you reproduce the two identical question-target.txt failures, and the test_ftparchive one? | 02:47 |
| maxb | question-target.txt did not fail for me | 02:47 |
| wgrant | The question-target.txt one looks really odd -- the query should ensure order. | 02:47 |
| * wgrant reruns. | 02:47 | |
| maxb | I see the ftparchive one | 02:47 |
| wgrant | I haven't looked at that one at all. | 02:48 |
| wgrant | I also need to test utilities/*, since some of it is broken. | 02:48 |
| maxb | oh, you mean the "You need to invoke update-sourcecode using the system python, not what its shebang says" problem? | 02:49 |
| wgrant | yes. | 02:49 |
| wgrant | And maybe others too | 02:49 |
| wgrant | Have you had the bootstrapping issue lately? | 02:50 |
| wgrant | I ran into it for the first time in weeks last night when trying the python2.6 branch. | 02:50 |
| maxb | I've been working in karmic still quite a lot | 02:51 |
| maxb | so no, I've not seen it | 02:52 |
| wgrant | OK. | 02:52 |
| wgrant | And what do you know, questiontarget.txt passes for me now. | 02:52 |
| wgrant | Actually, the failure was on db-devel. | 02:53 |
| * wgrant tries there. | 02:53 | |
| wgrant | I would really love it if the DB and librarian data directories were per-branch. | 02:53 |
| lifeless | doable | 02:55 |
| wgrant | OK, questiontarget.txt works on db-devel too. | 02:57 |
| wgrant | It must have just hated me yesterday. | 02:57 |
| * wgrant looks at test_ftparchive. | 02:57 | |
| * wgrant vomits in the direction of lp.archiveuploader.ftparchive. | 03:00 | |
| wgrant | s/uploader/publisher/ | 03:00 |
| maxb | uhoh, postgres 8.3 just got kicked out of lucid - so much for launchpad-dependencies being installable | 03:07 |
| * maxb copies it back into the ppa | 03:08 | |
| wgrant | Urgh. | 03:08 |
| wgrant | still, it seems that stub wants to move to 8.4 really soon. | 03:08 |
| maxb | I love how easy it is to use PPAs to rescue removed packages | 03:10 |
| wgrant | Yeah, it's pretty handy. | 03:11 |
| maxb | ... pending publication on amd64 i386 powerpc sparc and ia64 :-) | 03:11 |
| maxb | not often you see the ppa build status column being stretched that far | 03:12 |
| wgrant | No armel? | 03:12 |
| maxb | it ftbfs, apparently | 03:12 |
| wgrant | Ah. | 03:12 |
| wgrant | maxb: Oh. I just realised that questiontarget.txt does still fail on db-devel. I just had my test fix in place. | 03:21 |
| wgrant | maxb: can you try it on db-devel? | 03:21 |
| thumper | AARRGGGHHHH!!!!! | 03:29 |
| thumper | YUI madness | 03:29 |
| * thumper heads to #yui | 03:34 | |
| wgrant | Anybone else running LP on Lucid? | 03:54 |
| poolie | wgrant: only under a chroot | 03:55 |
| wgrant | poolie: That's fine. Could you please 'bin/test -vvt questiontarget.txt' in db-devel? | 03:55 |
| poolie | it will take a few minutes, but yes | 03:56 |
| poolie | wgrant: just to be clear, i mean in a karmic chroot on a lucid host | 03:58 |
| poolie | wgrant: do you still want it? | 04:02 |
| wgrant | poolie: Oh, right. That's probably not what I want, then. | 04:02 |
| mwhudson | gaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaar | 04:14 |
| lifeless | ? | 04:15 |
| wgrant | Normally I would assume that was a JavaScript scream. | 04:15 |
| mwhudson | it's a zope scream | 04:15 |
| mwhudson | xml-rpc methods can't take *args | 04:15 |
| lifeless | haha | 04:16 |
| lifeless | sorry. | 04:16 |
| wgrant | Better than lazr.restful methods, which can't take positional args at all. | 04:16 |
| lifeless | 'omg I'm so surprised' | 04:16 |
| mwhudson | and it' | 04:16 |
| mwhudson | s basically because of stupid LBYL-ism | 04:16 |
| mwhudson | wgrant: i _could_ be writing js! | 04:17 |
| mwhudson | theoretically | 04:17 |
| wgrant | Gngrg stupid doctests. | 04:18 |
| wgrant | -D is almost completely useless with them. | 04:18 |
| wgrant | 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:25 |
| poolie | lifeless: so it's bug 59846 | 04:32 |
| poolie | hullo bot? | 04:33 |
| * mwhudson EODs | 04:33 | |
| swarna | http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/utilities is not opening | 04:33 |
| wgrant | swarna: Go to http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel and browse to utilities/rocketfuel-setup from there. | 04:34 |
| lifeless | poolie: well, that was about an earlier behaviour | 04:35 |
| lifeless | poolie: I think perhaps the last subscriber can't unsubscribe. | 04:36 |
| poolie | is it? that looks like what we're hitting here | 04:36 |
| lifeless | no, the bug in question had plenty of subscribers | 04:36 |
| wgrant | Ah, it's private. That's why there's no bot. | 04:36 |
| lifeless | and I've unprivated it. | 04:36 |
| poolie | how is having lots of subscribers relevant? | 04:38 |
| lifeless | 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:39 |
| poolie | i think kiko felt that bug was closed by dealing by cleaning up some particular cases | 04:40 |
| poolie | but the description says | 04:40 |
| poolie | > 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 |
| poolie | and i agree with that | 04:40 |
| poolie | the underlying bug still exists | 04:40 |
| lifeless | so, this isn't a quick topic, and I started 9 1/2 hours ago. | 04:41 |
| poolie | np | 04:41 |
| poolie | it's not urgent | 04:41 |
| poolie | i was just surprised | 04:41 |
| poolie | i understand what's causing this now, so thanks | 04:41 |
| poolie | you can followup on 59846 if you want | 04:41 |
| lifeless | 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:41 |
| lifeless | 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 |
| poolie | 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 |
| lifeless | poolie: yup | 04:42 |
| lifeless | as I understand it anyhow. | 04:43 |
| poolie | hm | 04:44 |
| lifeless | two separate cases; also note that private and 'security' are nowadays separate flags. | 04:44 |
| poolie | well, nobody has yet made a case for that on that bug | 04:44 |
| lifeless | so I wouldn't comment on bug 59846 regardless, I'd file a new one. | 04:44 |
| poolie | so it looks like just a plain bug | 04:44 |
| lifeless | poolie: [meta] this looks like a case where a new bug would really have been better | 04:48 |
| poolie | yes, you said that | 04:48 |
| lifeless | poolie: I've commented there anyhow | 04:48 |
| lifeless | gnight | 04:48 |
| poolie | to me it seems like the underlying bug has not actually been fixed | 04:48 |
| lifeless | poolie: it is deliberate, by design. Rejected would be a better term, for that aspect of it. | 04:49 |
| poolie | that may be true but nobody has actually said so | 04:50 |
| poolie | except you :) | 04:50 |
| poolie | and it sounds more like defense of an accidental behaviour | 04:50 |
| lifeless | poolie: comment #2 describes it | 04:50 |
| lifeless | I agree that a clear unambiguous statement wasn't made. | 04:51 |
| poolie | it's not actually the same thing | 04:51 |
| lifeless | And I'm not in a position to do that either. | 04:51 |
| lifeless | I'm just sharing the context and history I know of with you. Privacy was /agonised/ over. | 04:51 |
| stub | 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:30 |
| wgrant | stub: The order is in the query, sorry. | 05:55 |
| wgrant | stub: What is the timeframe for moving to PostgreSQL 8.4? | 05:57 |
| wgrant | stub: 8.3 is gone from Lucid now. | 05:57 |
| poolie | lifeless: (when you're back) | 05:58 |
| poolie | i don't think this is a critical bug | 05:58 |
| poolie | but it is pretty surprising | 05:58 |
| poolie | and i think there is some kind of bugginess here | 05:58 |
| poolie | it's internally inconsistent | 05:58 |
| wgrant | What is the bug? | 05:58 |
| poolie | the security team can't see all bugs on the product | 05:59 |
| poolie | and, depending on the history of the bug, they may not get subscribed by default | 05:59 |
| poolie | for instance adding a new bugtask does subscribe them | 05:59 |
| stub | 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 |
| poolie | retargeting an existing bugtask does not | 05:59 |
| wgrant | Ah. Hm. | 05:59 |
| wgrant | stub: Oh, excellent. | 05:59 |
| wgrant | poolie: Really? I've found that moving a task explicitly subscribes the security contact even when the bug is public. | 06:00 |
| stub | wgrant: Bug #426823 is tracking this | 06:01 |
| mup | Bug #426823: Update to PostgreSQL 8.4 <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/426823> | 06:01 |
| poolie | wgrant: nup, definitely not | 06:01 |
| poolie | look at https://bugs.staging.launchpad.net/launchpad/+bug/453104 | 06:01 |
| mup | Bug #453104: sftp user/password don't work <Bazaar:Incomplete> <https://launchpad.net/bugs/453104> | 06:01 |
| poolie | oh heh, you can't :) | 06:01 |
| poolie | but try now | 06:02 |
| wgrant | If mup can see it, it's probably public... | 06:02 |
| poolie | it's public in reality, i changed it on staging | 06:02 |
| wgrant | Ah. | 06:03 |
| * wgrant curses 64kbps throttling. | 06:06 | |
| lifeless | poolie: so I think this hinge on what 'security team' means | 06:36 |
| lifeless | poolie: I think it means 'people to be told about new security bugs, by default' | 06:36 |
| wgrant | I think that is the assumption. | 06:36 |
| poolie | k | 06:36 |
| lifeless | poolie: I'm open to 'adding a product task to a secured disto bug should subscribe the product security team' | 06:37 |
| poolie | right | 06:37 |
| poolie | or retargeting a task | 06:37 |
| lifeless | poolie: but that is very different to 'the security team can always see bugs' | 06:37 |
| lifeless | right | 06:37 |
| poolie | and i dont' think it's specific to whether they're distro or product or series tasks etc | 06:37 |
| lifeless | conceptually perhaps not | 06:38 |
| poolie | lifeless: so 'the security team should always see bugs' is a different bug | 06:38 |
| poolie | perhaps a closer match for this existing one | 06:38 |
| poolie | i'm kind of ok if that's marked wontfix | 06:38 |
| poolie | i would like there to be a public bug for it, as documentation | 06:38 |
| poolie | and explanation | 06:38 |
| poolie | i do think it's a bit weird that potentially absolutely no one from the product can see the bug | 06:39 |
| lifeless | I think thats fine, but something we want to have happen explicitly not accidentally | 06:39 |
| wgrant | It's handy if you want to hide a bug, like I did last week. | 06:39 |
| poolie | i mean some bugs seem to at least accidentally have got into this state | 06:40 |
| wgrant | When does edge update these days? | 07:37 |
| noodles775 | wgrant: I didn't realise it had changed (but haven't been watching), so I'd assume between 8:30-9:00UTC? | 07:38 |
| wgrant | noodles775: buildd-manager has again been broken for three or four hours. | 07:38 |
| wgrant | noodles775: It probably hasn't changed. I just didn't remember. | 07:39 |
| noodles775 | wgrant: no losa? OK, they're still sprinting and probably having brekkie. | 07:39 |
| * noodles775 tries to find out. | 07:39 | |
| * wgrant wonders if this actually happens quite often, but there's normally a LOSA around to respond to the Nagios scream. | 07:40 | |
| noodles775 | 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 |
| wgrant | noodles775: Ah, good. | 07:41 |
| noodles775 | If it is happening regularly now, it might be worth CP'ing the change so that it doesn't block the b-m. | 07:41 |
| wgrant | 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:42 |
| noodles775 | yeah, let's chat about that with bigjools. Great, the losa's are on it :) | 07:44 |
| wgrant | Great. | 07:45 |
| noodles775 | 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. | 07:59 |
| wgrant | noodles775, $LOSA: Thanks. | 08:00 |
| * wgrant has a look through the new code for anything suspicious. | 08:02 | |
| wgrant | It was the building build without a builder again, right? | 08:02 |
| adeuring | good morning | 08:17 |
| noodles775 | 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:27 |
| wgrant | noodles775: Do we have the state of build/buildqueue/job before it was repaired? | 08:42 |
| noodles775 | wgrant: other than the above, no, but I'll update the wiki page so that we have it next time. | 08:44 |
| wgrant | noodles775: Great. | 08:44 |
| wgrant | It might tell us where in the build it actually was. | 08:44 |
| bigjools | g'morning | 09:00 |
| wgrant | Morning bigjools. | 09:05 |
| mwhudson | hello europe | 09:06 |
| bigjools | morning wellington | 09:07 |
| wgrant | You know you're in trouble when the Americans (apart from deryck) show up. | 09:07 |
| mwhudson | wgrant: even more so for me i guess | 09:08 |
| mwhudson | haven't stayed up that late in a while | 09:09 |
| wgrant | bigjools: Speaking of download stats... | 09:09 |
| bigjools | heh | 09:10 |
| * 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:12 | |
| wgrant | mwhudson: In time to get the incremental import repo pull fix onto staging? | 09:14 |
| mwhudson | wgrant: exactly | 09:14 |
| jelmer | moin mwhudson | 09:17 |
| jelmer | hi wgrant | 09:17 |
| wgrant | Morning jelmer. | 09:17 |
| wgrant | jelmer: Are you running LP on Lucid? | 09:17 |
| jelmer | wgrant, yep | 09:17 |
| wgrant | jelmer: Can you 'bin/test -t questiontarget.txt' on db-devel, please? | 09:18 |
| wgrant | jelmer: I get a strange ordering failure here, but not on devel, and I wonder if anybody else can reproduce it. | 09:18 |
| jelmer | wgrant: ok | 09:19 |
| wgrant | It's one of only two lucid test failures. | 09:19 |
| * jelmer hates how slow 'make schema' is on this machine | 09:22 | |
| wgrant | It's slow everywhere. | 09:22 |
| jelmer | wgrant, running now | 09:32 |
| wgrant | jelmer: Thanks. | 09:32 |
| jelmer | wgrant, failing here too because of the ordering | 09:35 |
| wgrant | jelmer: excellent except not. | 09:36 |
| jelmer | "daf" is now the first entry rather than the second | 09:36 |
| wgrant | jelmer: Yep, same failure is seen here. | 09:36 |
| wgrant | But the query is explicitly ordered, and running it in that transaction gets the right result. | 09:37 |
| jtv | henninge: feel free to replace the intltool-debian line with plain intltool, or use them both. | 09:53 |
| henninge | jtv: I am still not convinced they are the same. | 09:54 |
| henninge | jtv: ah, now I see | 09:55 |
| jtv | 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:55 |
| henninge | jtv: so why is it that you install it manually from the script and not just add a dependency to the package? | 09:56 |
| jtv | 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 |
| jtv | Also, IIRC this gets installed into the chroot whereas the buildd package lives outside it. | 09:57 |
| henninge | jtv: oh, we have a chroot inside the buildd? | 09:58 |
| henninge | to build | 09:58 |
| jtv | 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 | 09:59 |
| henninge | jtv: frankly, translationtemplates.py looks a bit over-engineered ... ;) Mind if I change it or is this some common pattern? | 10:02 |
| henninge | jtv: using a state machine this way, I mean. | 10:03 |
| jtv | henninge: that's how the base class wants it. The job runs asynchronously in twisted, so it doesn't hold everything up. | 10:03 |
| jtv | It is _possible_ to do the whole thing in one go, but not much easier. | 10:04 |
| jtv | And this way helps provide progress information, I believe. | 10:04 |
| wgrant | You need to either use the state machine or have a single subprocess that does all of the work. | 10:05 |
| wgrant | bigjools: Given the earlier discussion, I guess you don't have time to discuss PPA download stats today? | 10:24 |
| bigjools | wgrant: next week would be better - I really need to get the rebuild work done | 10:24 |
| bigjools | or maybe on Friday if I am done by then | 10:24 |
| wgrant | Yep, OK. | 10:25 |
| wgrant | 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:25 |
| wgrant | Hm, rebuild archives have the same permission rules as PPAs when they're disabled. Damn. | 10:28 |
| wgrant | bigjools: Is there a good reason for that, or can I submit a branch to fix it? | 10:33 |
| bigjools | wgrant: which rule is a problem? | 10:35 |
| wgrant | bigjools: Disabled copy archives are not accessible except by their owners and admins. | 10:37 |
| wgrant | This is awkward, since they normally get disabled when they're done. | 10:37 |
| bigjools | there's a bug about not being able to see them when they get disabled | 10:38 |
| wgrant | Bug #488468 | 10:41 |
| mup | Bug #488468: Disabled rebuild archives are not shown anywhere <Soyuz:Triaged by jelmer> <https://launchpad.net/bugs/488468> | 10:41 |
| bigjools | there ya go | 10:42 |
| deryck | Morning, all. | 11:04 |
| === jtv is now known as jtv-afk | ||
| deryck | BjornT, ping. | 11:26 |
| deryck | 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:38 |
| deryck | I say "assuming" not to question noodles775, just that I don't know much about screen readers. | 11:39 |
| adeuring | deryck: yes and no. I think it is a bit like expoiting a bug in screen readers ;) | 11:39 |
| adeuring | they should not present non-visible text, I'd argue | 11:40 |
| deryck | adeuring, hmmm, that would make me concerned then. img alt tags are the standard way to handle this. | 11:40 |
| adeuring | deryck: that's my main point indeed. | 11:40 |
| deryck | adeuring, let me look closer at the comments in the MP again. | 11:41 |
| deryck | 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 |
| adeuring | deryck: no, I had not looked yet. | 11:45 |
| deryck | 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:47 |
| adeuring | deryck: well, ok. I am not 100% convinced, but it does not matter that much. | 11:48 |
| === jtv-afk is now known as jtv | ||
| deryck | adeuring, ok, thanks. sorry to send you back to work again. | 11:48 |
| adiroiban | 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 | 11:51 |
| BjornT | deryck: pong | 12:07 |
| jtv | Oh wow, a "here's your compensation from the Nigerian government for being scammed" Nigerian scam. | 12:43 |
| === jtv is now known as jtv-eat | ||
| gmb | intellectronica: If you want to chat about a logarithmic scale for bug heat, I'll be free in 5. | 13:12 |
| intellectronica | gmb: excellent. i'm just firing an MP for my first branch and will ping you in ~5m | 13:12 |
| gmb | Cool. | 13:12 |
| beaver | www.search2.net | 13:14 |
| intellectronica | now that must be the mossad ^^^^^ | 13:16 |
| intellectronica | gmb: ready when you are | 13:23 |
| gmb | intellectronica: Cool. Skype? | 13:24 |
| intellectronica | gmb: yup | 13:24 |
| deryck | intellectronica, just FYI, I'm changing my max_heat branch to have max_bug_heat where the default is NULL not 0. | 13:26 |
| deryck | intellectronica, but you could review as is, and I can fix it up in my branch when merging in. | 13:26 |
| === al-maisan_ is now known as al-maisan | ||
| kfogel | intellectronica: hey, you're totally right about that targetName thing -- I feel dumb. Will fix, thanks. | 14:44 |
| intellectronica | cool | 14:44 |
| intellectronica | and it was easy to confuse that one | 14:44 |
| intellectronica | maybe it's even worth a comment, so that the next reader won't get confused. i nearly missed it myself | 14:45 |
| intellectronica | kfogel: ^^^ | 14:45 |
| kfogel | 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:46 |
| kfogel | intellectronica: maybe an explanation of why, though, yeah. | 14:47 |
| intellectronica | 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 |
| deryck | intellectronica, sounds good. thanks for the info. | 14:48 |
| deryck | intellectronica, sorry to leave you out, too. Still trying to find a good rhythm with the board. | 14:49 |
| intellectronica | that's oright. it's also not like the call is our one and only opportunity to update | 14:50 |
| deryck | right | 14:50 |
| intellectronica | i wonder if we can get a feed or something of the updates on the kanban and spew it here | 14:50 |
| deryck | intellectronica, there is RSS for the board. | 14:51 |
| intellectronica | it's nice how the kanban shows a notification when someone changes something, but you can't really follow it | 14:51 |
| deryck | yeah | 14:53 |
| deryck | we need some kind of commit email or something. | 14:53 |
| deryck | this would also make sharing in the open better. | 14:53 |
| deryck | flacoste, is there something like the above for the board? ^^ Or some way to come up with that. | 14:54 |
| flacoste | deryck: there is | 14:55 |
| flacoste | each line has an email icon | 14:55 |
| flacoste | to subscribe to events there | 14:55 |
| flacoste | there is also a RSS feed for the whole board | 14:55 |
| flacoste | and there is an email notification option for the whole board also | 14:55 |
| flacoste | look under the Options tab | 14:55 |
| deryck | ah, ok. thanks flacoste | 14:56 |
| deryck | intellectronica, see that ^^. You can subscribe your email to board events. | 14:56 |
| intellectronica | deryck: thanks. i'll give that a try. | 14:57 |
| deryck | I find the per lane rss or email useless, really. But the global option is nice. | 14:58 |
| intellectronica | ah, and i found out why i didn't see avatars. there's a global option to show or hide them | 14:58 |
| flacoste | deryck, intellectronica: the option to turn off the white board markers is also nice to get more screen real-estate | 14:59 |
| deryck | ah, right. sorry. I didn't realize that was per user. | 14:59 |
| intellectronica | flacoste: indeed | 14:59 |
| deryck | yes, nice. | 15:00 |
| deryck | 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. | 15:01 |
| === danilo__ is now known as danilos | ||
| deryck | flacoste, would make it less private. | 15:01 |
| flacoste | deryck: they should implement a "public board" option soon | 15:01 |
| deryck | flacoste, ah, ok. cool. | 15:01 |
| kfogel | 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:20 |
| kfogel | intellectronica: anyway, review when ready | 15:21 |
| intellectronica | kfogel: looks good. r=me | 15:23 |
| kfogel | intellectronica: thx | 15:23 |
| kfogel | intellectronica: you think any need for UI review on this one? | 15:25 |
| * kfogel answers his own question | 15:25 | |
| kfogel | no. the ui change is trivial and unambiguously an improvement :-) | 15:25 |
| intellectronica | kfogel: never hurts, but since this was such a small change i don't think it's strictly necessary | 15:25 |
| intellectronica | kfogel: normally i wouldn't even ask for a first ui review for something like this, tbh | 15:26 |
| kfogel | intellectronica: what, you mean for the whole feature? | 15:26 |
| intellectronica | i only added the keyword because we did discuss it a bit in the review | 15:26 |
| kfogel | intellectronica: keyword? | 15:26 |
| * kfogel confused | 15:26 | |
| kfogel | intellectronica: where? | 15:27 |
| intellectronica | 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 |
| intellectronica | kfogel: keyword in the review signature. i used 'code ui'. | 15:27 |
| intellectronica | maybe it's called review type | 15:27 |
| kfogel | intellectronica: oh, didn't refresh, didn't see that yet | 15:28 |
| kfogel | 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 |
| intellectronica | kfogel: if so then that's a complete surprise to me. i never used it like that. | 15:29 |
| kfogel | hmmm. | 15:29 |
| intellectronica | let me know if it works for you :) | 15:29 |
| kfogel | intellectronica: well, I don't want to risk a change landing with a bogus message. I'll ask around. | 15:30 |
| kfogel | deryck: do you regularly use 'ec2 land'? | 15:33 |
| deryck | kfogel, I do | 15:33 |
| kfogel | 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:33 |
| deryck | kfogel, it will. do `ec2 land --dry-run` and you can see what it will do. | 15:34 |
| kfogel | 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 |
| deryck | kfogel, it does | 15:34 |
| kfogel | deryck: thx | 15:34 |
| deryck | kfogel, np | 15:34 |
| === jtv-eat is now known as jtv | ||
| cbx33 | hey peeps | 15:46 |
| === salgado is now known as salgado-lunch | ||
| === matsubara is now known as matsubara-lunch | ||
| === Guest5903 is now known as NCommander | ||
| bdmurray | could somebody review my branch for bug 527174? | 16:56 |
| mup | Bug #527174: logo_link missing from "team" object in API <Launchpad Registry:In Progress by brian-murray> <https://launchpad.net/bugs/527174> | 16:56 |
| thumper | rockstar: I have a branch now that refreshes the status table on the mp page when the status is updated | 16:57 |
| thumper | rockstar: it is awesome | 16:57 |
| rockstar | thumper, we're refreshing the whole table? | 16:58 |
| thumper | rockstar: I'll make a movie :) | 16:58 |
| rockstar | bdmurray, #launchpad-reviews is what you want. | 16:58 |
| === matsubara-lunch is now known as matsubara | ||
| kfogel | intellectronica: in my launchpad.dev instance, default batch size for +patches view seems to be 5 bugs per page instead of (say) 50. Is this a dev thing we do? I don't remember setting that param anywhere, and it's not in my URL. | 17:27 |
| intellectronica | kfogel: yes, that's a dev env setting | 17:38 |
| kfogel | intellectronica: thanks | 17:38 |
| jtv | Wasn't there an easy way to add a person to a team? | 18:19 |
| === gary_poster is now known as gary-lunch | ||
| salgado | jtv, the team's home page should allow you to do that. there's an ajaxy link there | 19:05 |
| jtv | salgado: I should've said: in code. | 19:08 |
| salgado | oh, code | 19:08 |
| salgado | jtv, team.addMember(person), then? | 19:08 |
| jtv | salgado: ah, thanks! Yes, that's what I was looking for. I missed it somehow (did grep for addPerson of course) | 19:09 |
| === mpt_ is now known as mpt | ||
| === gary-lunch is now known as gary_poster | ||
| maxb | OOI, are there any estimations on when the datacentre Lucid upgrades are planned? | 20:25 |
| sinzui | jtv: you are still awake? | 21:02 |
| thumper | maxb: IIRC some get upgraded at beta time | 21:03 |
| thumper | maxb: others shortly after release i think | 21:03 |
| maxb | To put it another way: When is edge or staging likely to running on lucid? :-) | 21:04 |
| maxb | * to be | 21:04 |
| mwhudson | i would guess staging would be pretty soon after release | 21:06 |
| mwhudson | totally a guess though | 21:06 |
| === salgado is now known as salgado-afk | ||
| sinzui | bac: EdwinGrubbs: I just sent a request for sql/ddl help to launchpad-dev. Can both of you read it and provide your thoughts. | 21:22 |
| bac | ok | 21:23 |
| * sinzui is now thinking about how to move the packaging portlet to staging-only and update the bug heat script to add info to sourcepackagename | 21:24 | |
| lifeless | mwhudson: was the bzr-git patch sufficient? | 21:26 |
| mwhudson | lifeless: i haven' | 21:27 |
| mwhudson | t tested it actually | 21:27 |
| mwhudson | i guess it would be easy enough | 21:27 |
| thumper | mwhudson: you have much QA to mark off :) | 21:29 |
| mwhudson | thumper: see earlier griping about staging | 21:29 |
| thumper | mwhudson: yeah, but there are some we can check off right? | 21:30 |
| mwhudson | thumper: no? | 21:30 |
| mwhudson | thumper: all the 'landed' things are code import related | 21:30 |
| === matsubara is now known as matsubara-afk | ||
| lifeless | mwhudson: it would be good to get it tested and done | 21:38 |
| lifeless | mwhudson: one less thing in progress ;) | 21:38 |
| EdwinGrubbs | sinzui: can you do an EXPLAIN ANALYZE on that query? EXPLAIN can often be misleading with its cost numbers. | 21:55 |
| sinzui | EdwinGrubbs: just explain as I showed | 21:55 |
| EdwinGrubbs | sinzui: I'm asking whether you can rerun it with EXPLAIN ANALYZE? | 21:56 |
| sinzui | sent | 21:57 |
| sinzui | EdwinGrubbs: The numbers look roughly the same. | 21:57 |
| EdwinGrubbs | sinzui: the costs will look the same, but I would like to see the times, which are easier to understand. How many times is this query run on the page? just once? | 21:58 |
| sinzui | EdwinGrubbs: We pay a terrible cost scanning all bugs and the join to bugtask is also expensive | 21:59 |
| sinzui | check your email | 21:59 |
| * sinzui is trying to understand how bugs are queued in the new bugjob system. | 21:59 | |
| sinzui | EdwinGrubbs: the query is run once for every page that uses it. | 22:06 |
| EdwinGrubbs | sinzui: I don't think it will be possible to get much better results if 3/5 of the bugs have a sourcepackage. Caching the heat in sourcepackage is definitely the best bet if it is ok for the data to be a little stale. If it needs to be absolutely up to date, caching it on the BugTask table would be safer to implement via a trigger, and eliminating the join should speed it up greatly. | 22:14 |
| EdwinGrubbs | sinzui: as a shot in the dark, you could try "set enable_seqscan = false;" before you run explain analyze to see if it cuts down the times. It probably won't help since so many of the bugs in the table are being read. | 22:15 |
| sinzui | EdwinGrubbs: agreed. bug heat is updated using the bugjob system. The mechanism for jobs is quite elaborate. I was hoping to append a rule for sourcepackagename to something. | 22:16 |
| EdwinGrubbs | makes sense | 22:16 |
| sinzui | I bug heat and po messages scoring is fuzzy, I think it is fine to cache it. I think I need to consider disabling the problem calls in the views; the work to build a cronscript correctly may be mroe than 8 hours. I need a schema change approval too | 22:18 |
| thumper | rockstar: ping | 22:25 |
| rockstar | thumper, pong | 22:26 |
| thumper | rockstar: skype? | 22:26 |
| rockstar | thumper, sure. | 22:26 |
| thumper | rockstar: https://code.edge.launchpad.net/~thumper/launchpad/use-last-rev-id/+merge/20023 | 22:27 |
| sinzui | is salgado an admin in sample data? | 22:31 |
| mwhudson | sinzui: i think so, not sure though | 22:32 |
| sinzui | We cannot expire our oauth tokens. I see a typo in the security checker, yet the test passes, implying it works because salgado has god-like qualities. | 22:33 |
| mwhudson | yep, he's an admin | 22:34 |
| mwhudson | i remember griping at this because the webservice tests are/were done with salgado by default | 22:34 |
| mwhudson | or something like that | 22:34 |
| sinzui | yes, the same is true for oauth | 22:34 |
| === jelmer__ is now known as jelmer | ||
| === jelmer is now known as Guest75587 | ||
| thumper | rockstar: http://people.canonical.com/~tim/magic.ogv | 22:42 |
| === Guest75587 is now known as ctrlsoft | ||
| jtv | sinzui: I'm here | 23:04 |
| sinzui | jtv: I was looking for help improving a query. I sent a request to launchpad-dev for help. EdwinGrubbs concluded that changing the schema was the only viable option to improve the query performance. | 23:05 |
| jtv | sinzui: the fix for the translations was simple; cp'ed yesterday | 23:06 |
| jtv | sinzui: where is this query you posted used? | 23:07 |
| sinzui | jtv: [Launchpad-dev] SQL/DDL help wanted to fix a distrosseries timeouts | 23:08 |
| jtv | sinzui: yes, I just read it. But where is the query that you posted used in the code? | 23:08 |
| sinzui | registry.model.distroseries._current_sourcepackage_joins_and_conditions() it is used in the packaging portlet on the distroseries, and in the +needs-packaging report | 23:10 |
| sinzui | ^ jtv https://edge.launchpad.net/ubuntu/lucid/+needs-packaging | 23:10 |
| thumper | Quick straw poll: Rename +junk to +personal? | 23:10 |
| * thumper leaves to collect Maia | 23:10 | |
| lifeless | 'meh' | 23:10 |
| lifeless | more clear | 23:11 |
| lifeless | less sexy | 23:11 |
| wgrant | thumper: Hasn't this been discussed to death lots of times? | 23:11 |
| sinzui | thumper: +1 | 23:11 |
| wgrant | Also, +personal doesn't really work for teams. | 23:11 |
| lifeless | +misc | 23:11 |
| lifeless | actually, delete +junk | 23:11 |
| jtv | sinzui: but that view is batched. | 23:11 |
| lifeless | create a junkcode project; move everything to it. | 23:12 |
| sinzui | yes, but the query behind it is a monster | 23:12 |
| thumper | wgrant: yes, but I'm willing to move now | 23:12 |
| jtv | sinzui: then leave the counting to the browser code. | 23:12 |
| thumper | +personal doesn't work so well for team branches does it? | 23:12 |
| jtv | sinzui: You're probably doing the counting for _all_ sourcepackages even though you're only showing 20. | 23:13 |
| sinzui | jtv: This is an actual query used by the portlet...it only wants the top 10, but learning the top ten by bug heat and po messages is terrible: http://pastebin.ubuntu.com/383302/ | 23:14 |
| * jtv whistles | 23:14 | |
| sinzui | jtv: that came from https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1516S98 | 23:14 |
| sinzui | thumper, I close 3 projects a week because the user does not know +junk. The word they use to describe it is "personal" and "sandbox" | 23:16 |
| jtv | sinzui: that is a monster. | 23:16 |
| sinzui | jtv: yes, it took me four days to create a query that had viable results. It was a sad week for me | 23:17 |
| lifeless | sinzui: so we should create a sandbox project perhaps? | 23:18 |
| sinzui | jtv: I think I want to change sourcpackagename to store reporing data that Is updated daily. | 23:18 |
| jtv | sinzui: I see that total_bugs and total_messages can be left out... does that help any? | 23:18 |
| jtv | We have a cache like that for POFiles. It's necessary, but keeping it up to date is sheer hell. | 23:19 |
| sinzui | lifeless: I have approved a few when the user decided to focus the code on a single problem. I think project registration to explain to the user what a project is in launchpad and point him to +junk when he wants a sandbix | 23:20 |
| mwhudson | sinzui: sourcepackagename doesn't have any connection to a distro | 23:20 |
| sinzui | jtv, no, but yes they can be left out now | 23:20 |
| mwhudson | sinzui: are you proposing just caching the values for ubuntu on there? | 23:21 |
| lifeless | sinzui: I'm saying lets delete +junk /from launchpad/ and replace it with an actual project, called - 'sandbox' or 'personal' (or even a few such things) | 23:21 |
| lifeless | sinzui: owned by registry; bugs turned off; no trunk series, or an empty one. | 23:21 |
| lifeless | sinzui: we can simplify our code and make it more discoverable at the same time. | 23:22 |
| sinzui | mwhudson: sourcepackagename is nothing but a key in our schema, but we do not think about it that way. We think about source packages having bugs and being in a distro, but launchpad does not think that way | 23:22 |
| wgrant | Excellent. | 23:22 |
| wgrant | Er. | 23:22 |
| wgrant | Gah, thought the other Lucid failure had fixed itself :( | 23:22 |
| wgrant | But no. | 23:22 |
| mwhudson | sinzui: what you say is undoubtedly true, but i don't see the connection with what i said | 23:23 |
| sinzui | mwhudson: I am proposing that sourcepackagename have new columns that can be used to store the total bug heat or total messages so that these do not need to be recalculated. | 23:24 |
| mwhudson | sinzui: are you proposing actually having a "source package" concept in the databgase? | 23:24 |
| jtv | sinzui: I take it the part you posted took the bulk of the time though? | 23:24 |
| lifeless | jtv: look at the oops itself. (and yes) | 23:24 |
| mwhudson | sinzui: but nowhere do we show the bugs targeted to a sourcepackagename | 23:24 |
| lifeless | next highest question was 576ms | 23:24 |
| lifeless | sorry, 592 | 23:24 |
| mwhudson | sinzui: we show those targeted to a sourcepackage | 23:24 |
| sinzui | lifeless: I think your general proposal is right, but creating exceptions is costly. I think we want this repo space more visible, and have a mechanism to promote a branch to be the basis of a new project | 23:25 |
| mwhudson | sinzui: so i guess i'm saying i don't really understand your proposal | 23:26 |
| sinzui | mwhudson: no, just extending the sourcepackagename. | 23:26 |
| sinzui | jtv: yes, the bugheat for a sourcepackagename is the main problem by a vast magnitude | 23:26 |
| sinzui | mwhudson: I am using sourcepackagename as a key to join many objects (because there is not really a source package object). I think it would be easier for many queries if the sourcepackagename had additional data with it that would allow me to make simpler queries | 23:28 |
| jtv | sinzui: I don't suppose you could ignore (or treat separately) packages without any bugtasks? | 23:29 |
| jtv | At least you'd have an inner join instead of an outer one | 23:30 |
| sinzui | jtv: bug heat is the best indicator that a package needs linking to an upstream project, but we do not have that data in a convenient place. | 23:31 |
| jtv | sinzui: why is Bug in that join? | 23:31 |
| jtv | Is there no way to get it out? | 23:32 |
| jtv | It's used for counting heat and ids. For ids you don't actually need it. | 23:32 |
| jtv | (Because you can count the bugs' primary keys as the bugtasks' foreign keys) | 23:32 |
| sinzui | jtv: bugs have heat, not tasks, which are linked to a sourcepackagename, that is in a publishing table that says the package is in a series | 23:32 |
| jtv | sinzui: ok, so can you limit the Bug join to ones that have heat? | 23:34 |
| sinzui | jtv: removing count is inconsequential: http://pastebin.ubuntu.com/383310/ | 23:34 |
| mwhudson | sinzui: so what data would you attach? | 23:34 |
| sinzui | all bugs have heat, Would limiting it to heat > 0 woek | 23:35 |
| sinzui | mwhudson: sum of bugheat and po messages | 23:35 |
| jtv | Looks like most bugs have heat. :( | 23:35 |
| mwhudson | sinzui: across all distros? | 23:36 |
| sinzui | all? yes, because only Ubuntu is really present | 23:36 |
| mwhudson | ok | 23:36 |
| mwhudson | that's all i wanted to check | 23:36 |
| jtv | sinzui: if you dropped bugs with heat <= 10 from the heat count, you would make a serious dent in the number of Bugs the query has to churn through. | 23:37 |
| sinzui | mwhudson: we claim to support all distro, but we only support Ubuntu. If we change distro(series).getSourcePackage() to only return what we know exists, several hundred bugtasks disapear, and 60 packaging links tpp | 23:38 |
| wgrant | abentley: You pinged me yesterday? | 23:38 |
| * sinzui tries | 23:38 | |
| * sinzui hugs jtv | 23:39 | |
| jtv | sinzui: or maybe it's not me; in your post with the subquery, "explain analyze" only reported a cost of about 2 seconds. The larger query as shown in the pastebin and the timeout takes 12.5 seconds. | 23:40 |
| jtv | So are we barking up the wrong tree because there are too many digits in the millisecond counts? | 23:41 |
| sinzui | jtv: This is the largest junk from the whole query: http://pastebin.ubuntu.com/383314/ | 23:42 |
| jtv | whoa, thanks for splashing _that_ across my eyes in the wee hours of the night! | 23:42 |
| sinzui | jtv: I did try to show only what was needed | 23:42 |
| sinzui | jtv heat > 200 is great. I can lower it a bit | 23:43 |
| wgrant | jtv: Hm, you probably don't want to use makeGPGKey. The user needs to hold the matching private to make an upload... | 23:43 |
| jtv | sinzui: I'm just messing with you. But AFAICS the part you posted accounted for 2 seconds out of 13. | 23:43 |
| jtv | wgrant: drat. Any alternatives you know of? | 23:43 |
| sinzui | jtv: This listing is a heuristic. We just want the most problematic packages being seen by users | 23:44 |
| jtv | sinzui: don't forget to count(BugTask.bug) instead of count(Bug.id) though | 23:44 |
| wgrant | jtv: Not really. | 23:45 |
| jtv | wgrant: so makeGPGKey doesn't even create a proper key pair and hide the private side somewhere? | 23:45 |
| sinzui | jtv: did you ping-bomb me? I saw your name then pidgen went belly-up | 23:45 |
| jtv | sinzui: I didn't ping you at all | 23:46 |
| sinzui | jtv: yes, makeGPGKey() is bogus. | 23:46 |
| EdwinGrubbs | bac: I have a question regarding the formatting of the upstream assoc portlet. | 23:46 |
| wgrant | jtv: No. | 23:46 |
| sinzui | jtv: I had to hack it last release to get a test to work | 23:46 |
| wgrant | Maybe sinzui knows what to do. | 23:46 |
| jtv | wgrant: would it be possible to let the user provide an email address that they have a proper key for? | 23:46 |
| jtv | Just fork gpg to do the interesting work? | 23:47 |
| sinzui | wgrant: repeat the question, I lost my scrollback when irc restarted | 23:47 |
| jtv | (Or invoke some gpg library, but to the same effect) | 23:47 |
| === EdwinGrubbs is now known as Edwin-brb | ||
| jtv | sinzui: a script needs to create a user with a proper GPG key | 23:47 |
| wgrant | jtv: There is code already in LP to take a fingerprint and look it up. That's how we add gpg keys. | 23:47 |
| wgrant | jtv: So you can find that code, and take a fingerprint on the command line. | 23:47 |
| wgrant | The only caveat is that zeca needs to be running before that will work. | 23:48 |
| jtv | drat | 23:48 |
| jtv | what _is_ zeca, anyway? | 23:48 |
| jtv | the keyserver? | 23:48 |
| wgrant | See PersonGPGView.claim_gpg for the code you need to replicate. | 23:48 |
| sinzui | pr_BR for test? | 23:48 |
| jtv | wgrant: thanks | 23:48 |
| wgrant | It's a mostly braindead test keyserve.r | 23:48 |
| jtv | sinzui: meanwhile, did you say there was progress? | 23:50 |
| wgrant | I would have liked to have had all this functionality in the script at the start, but I'd had the LP code for less than 24 hours and didn't really know my way around yet. | 23:50 |
| wgrant | Thanks for adding it. | 23:50 |
| sinzui | jtv: yes, filtering the lower bug.heat will make the query fast enough for now. | 23:50 |
| jtv | wgrant: pretty impressive. | 23:51 |
| jtv | One day. | 23:51 |
| jtv | sinzui: \o/ | 23:51 |
| sinzui | wgrant: jtv: I do not understand the gpg question, I only know that the kerys we make in testing are not unique. I had a test failure and I make a quick hack to the factory to make them unique enough for me to test | 23:52 |
| wgrant | sinzui: jtv is extending one of my scripts to add a user's real GPG key. | 23:53 |
| sinzui | ah | 23:53 |
| jtv | or at least, _a_ real GPG key that the LP user can use. | 23:53 |
| wgrant | True. | 23:54 |
| jtv | sinzui: oh, I said count(BugTask.bug) but I guess that should be count(DISTINCT BugTask.bug) | 23:58 |
| * sinzui tries that too | 23:58 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!