| wgrant | Hm, nearly four hours since that ec2test probably started. Is PQM turned off, or does my branch just suck? | 00:20 |
|---|---|---|
| spm | wgrant: it's stopped atm. not sure what/where/why yet... | 00:31 |
| wgrant | spm: Ah, thanks. Is the queue visible somewhere | 00:32 |
| wgrant | +? | 00:32 |
| spm | https://pqm.launchpad.net/ - I belivee it's still openid locked tho | 00:33 |
| mwhudson | it's not, but for no good reason | 00:33 |
| wgrant | :( | 00:33 |
| mwhudson | i guess we sometimes want to land security fix branches while they're private, but those should probably be cowboyed first anyway | 00:33 |
| thumper | mwhudson: possibly | 02:05 |
| thumper | mwhudson: probably even | 02:05 |
| thumper | mwhudson: skype? | 02:53 |
| mwhudson | thumper: sure | 02:57 |
| thumper | https://devpad.canonical.com/~lpqateam/oops-summaries/lpnet-2009-10-14--2009-10-20.html | 03:04 |
| mwhudson | stub: hello | 03:05 |
| stub | hi | 03:05 |
| mwhudson | stub: do you have any idea how to diagnose a timeout that is probably to do with locking? | 03:06 |
| mwhudson | https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1385XMLP15 | 03:06 |
| * stub has a look | 03:08 | |
| stub | mwhudson: I'd agree that you are probably attempting to update a locked row. | 03:10 |
| stub | mwhudson: What do you need to diagnose? Do you need to confirm this, or track down what is holding the lock? | 03:10 |
| mwhudson | stub: i guess there's no way to find out what locked the row after the fact | 03:10 |
| stub | After the fact, yes. We would have to work out what needs to be logged to diagnose further, and add that to the OOPS reports, and wait for it to happen again. | 03:11 |
| mwhudson | stub: i see | 03:12 |
| mwhudson | stub: what/how can we log stuff? | 03:13 |
| mwhudson | stub: is it possible to find out what has locked the row in an except TimeoutError: block or something? | 03:13 |
| thumper | https://lp-oops.canonical.com/oops.py/?oopsid=1396EC76 | 03:16 |
| mwhudson | <stub> After the fact, yes. We would have to work out what needs to be logged to diagnose further, and add that to the OOPS reports, and wait for it to happen again. | 03:18 |
| mwhudson | <mwhudson> stub: i see | 03:18 |
| mwhudson | <mwhudson> stub: what/how can we log stuff? | 03:18 |
| mwhudson | <mwhudson> stub: is it possible to find out what has locked the row in an except TimeoutError: block or something? | 03:18 |
| stub | mwhudson: We should be able to get something that may be useful - a dump of the current locks if nothing else. We won't want it for all oopses, but I guess we could use a heuristic to decide when to log it. | 03:24 |
| wgrant | What is the process for a DB patch these days? | 03:28 |
| stub | Put it up for review, type 'db' to be reviewed by me and jml. | 03:30 |
| stub | preferably a branch containing nothing but the database changes, before you spend time coding | 03:30 |
| wgrant | Should I have the patch both in database/schema/pending/ and database/schema/ with 99 as the ID, as the README suggests? | 03:32 |
| mwhudson | wgrant: just schema | 03:36 |
| mwhudson | schema/pending is an appendix i think | 03:36 |
| jamesh | these days pending/ is stuff that hasn't been merged yet | 03:36 |
| wgrant | Ah, I see. | 03:42 |
| wgrant | Thanks. | 03:42 |
| thumper | https://code.edge.launchpad.net/~thumper/launchpad/auto-approve | 03:43 |
| wgrant | I like the sound of that, I think (the branch is private) | 03:45 |
| wgrant | Why is the title of the 403 page now 'Error: Launchpad system error'? | 03:48 |
| wgrant | I think that changed from 'Error: Forbidden' around 3.0. | 03:48 |
| thumper | wgrant: :) | 04:00 |
| thumper | wgrant: I pasted that there just to frustrate you :) | 04:00 |
| thumper | wgrant: it's public now | 04:01 |
| stub | mwhudson: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/461661 | 04:22 |
| mup | Bug #461661: OOPS reports should log database locks <Launchpad Foundations:New> <https://launchpad.net/bugs/461661> | 04:22 |
| mwhudson | stub: thanks | 04:23 |
| wgrant | After three months, Ohloh just finished processing lp:launchpad/devel. | 04:28 |
| mwhudson | wgrant: so you were bouncing on that page too eh? | 04:31 |
| mwhudson | it's not clear that anything has yet happened that you can see | 04:31 |
| thumper | wgrant: yes, but now I still don't see anything | 04:31 |
| wgrant | It says the update has finished, but IIRC the report run is seperate from that. | 04:32 |
| wgrant | Uhoh. | 04:33 |
| wgrant | It just started updating again. | 04:33 |
| thumper | https://www.ohloh.net/p/launchpad/analyses/latest | 04:33 |
| thumper | there now | 04:33 |
| wgrant | So it is. | 04:34 |
| wgrant | Nice code volume graph. | 04:34 |
| thumper | -4,430 lines of html | 04:34 |
| wgrant | ... indeed. | 04:34 |
| thumper | I love the 95% comment ratio for the 3 lines of perl | 04:35 |
| jamesh | too bad ohloh doesn't show code:test ratio | 04:36 |
| wgrant | That's odd. | 04:36 |
| wgrant | There are several thousand lines of really foul Perl. | 04:36 |
| mwhudson | stub: is #461661 something you're going to be able to work on at all soon? | 04:36 |
| mup | Bug #461661: OOPS reports should log database locks <Launchpad Foundations:New> <https://launchpad.net/bugs/461661> | 04:36 |
| stub | mwhudson: Depends on how gary prioritizes it | 04:36 |
| mwhudson | stub: ok | 04:37 |
| stub | We will need it for zero oops I imagine | 04:37 |
| mwhudson | stub: indeed | 04:39 |
| thumper | according to ohloh, I've changed 62,690 lines of Launchpad :) | 04:41 |
| wgrant | I think that's all the aliases sorted out. | 04:45 |
| wgrant | stub: Could you please review https://code.edge.launchpad.net/~wgrant/launchpad/bpr-ddeb_package-db/+merge/14008 at some point? | 04:47 |
| * mwhudson eods | 04:48 | |
| * thumper too | 04:48 | |
| jamesh | spot the XSS bug on https://www.ohloh.net/p/launchpad/aliases | 04:48 |
| wgrant | Indeed. | 04:49 |
| wgrant | jamesh: We collided on the creation of two aliases. I wonder if it will die. | 04:50 |
| jamesh | which one? | 04:51 |
| wgrant | Sidnei and Cody. | 04:51 |
| jamesh | it's a Ruby on Rails app. They never have problems | 04:52 |
| wgrant | Heh. | 04:52 |
| wgrant | Launch Pad appears to be malcc, I think. | 04:54 |
| wgrant | No idea about Launchpad Developers, though. | 04:54 |
| jamesh | looks like commits from an external design company | 04:54 |
| wgrant | Odd that there is no Cyrillic version of Danilo. I guess they must automatically merge on email address. | 04:56 |
| wgrant | jamesh: Have you reported the XSS? | 04:57 |
| jamesh | no | 04:57 |
| * jamesh sends | 05:01 | |
| === stub1 is now known as stub | ||
| === dpm-afk is now known as dpm | ||
| danilos | jtv, hi, it seems we've got more permissions issues on the bzr import, did you fix the last ones we've seen? | 09:02 |
| jtv | danilos: think so, yes. Is it in the oopses? | 09:02 |
| jtv | (In call) | 09:02 |
| mrevell | Morning! | 09:03 |
| danilos | jtv, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1393RSBR1 | 09:04 |
| danilos | mrevell, morning | 09:04 |
| jtv | danilos: thanks | 09:04 |
| danilos | jtv, please also comment on https://bugs.edge.launchpad.net/rosetta/+bug/459836 if this wasn't in yet on 24th, and mark appropriately | 09:13 |
| mup | Bug #459836: No templates are getting imported from my branch <Launchpad Translations:Triaged> <https://launchpad.net/bugs/459836> | 09:13 |
| jtv | danilos: will do | 09:13 |
| === danilos is now known as danilo-brb | ||
| === danilo-brb is now known as danilos | ||
| deryck | Morning, all. | 10:06 |
| intellectronica | i need some help working with buildout. i've got a lazr.restful fix which i want to test with a local lp branch. how do i make my lp branch use the code in my restful branch, rather than the egg? | 11:12 |
| intellectronica | allenap: maybe you know? ^^^ | 11:13 |
| allenap | intellectronica: I do know, but it's a bit ugly. | 11:14 |
| allenap | intellectronica: As in, my solution is ugly. | 11:14 |
| intellectronica | allenap: i didn't expect it to be beautiful | 11:14 |
| allenap | intellectronica: In the lazr.restful branch I do python setup.py sdist. | 11:14 |
| allenap | Then copy the tarball into my download-cache. | 11:15 |
| allenap | Then make sure that all existing eggs have been removed, or that the version of the lazr.restful branch is distinct. | 11:15 |
| intellectronica | wow, yes, that's pretty awful | 11:15 |
| allenap | Then update setup.py in the lp branch to refer to the version of the lazr.restful distribution. | 11:16 |
| allenap | intellectronica: That's not all. When you're done you have to remember to remove it all :) | 11:16 |
| allenap | intellectronica: There must be a better way, but I don't know it. | 11:16 |
| intellectronica | allenap: there must be. i thought buildout is supposed to make life easier for us, not harder | 11:16 |
| allenap | Ah, the versions are in versions.cfg. | 11:17 |
| intellectronica | BjornT_: maybe you know how to use a lazr.restful branch in development instead of an egg? | 11:17 |
| allenap | intellectronica: There is the develop-eggs setting, which sounds like it should help, but I don't really understand what it does. | 11:17 |
| intellectronica | oh | 11:17 |
| === matsubara-afk is now known as matsubara | ||
| allenap | intellectronica: Ah, the setting is "develop" in buildout.cfg. The docs say "This tells the buildout to install a development egg for our recipes. Any number of paths can be listed. The paths can be relative or absolute." | 11:22 |
| allenap | intellectronica: "recipes" is a directory in the documentation, not a general reference to recipes. | 11:23 |
| intellectronica | allenap: hmmmm ... i'm not sure i understand how i would use it | 11:24 |
| intellectronica | allenap: what should i specify as the value of develop. is it the path to the external branch? | 11:25 |
| allenap | intellectronica: It's already set as "develop = ." in buildout.cfg. I guess it might work to say "develop = . ${path-to-your-lazr.restful-branch}" (those settings might have to be on separate lines. | 11:25 |
| intellectronica | allenap: yeah, i wonder how you separate paths in this case. maybe a semicolon? | 11:26 |
| allenap | intellectronica: This is all guesswork though, I've not done this before. | 11:26 |
| allenap | intellectronica: indented, on a new line. | 11:26 |
| intellectronica | allenap: no, that doesn't seem to have any effect. maybe i need to somehow tell it to forget about the released eggs? | 11:32 |
| allenap | intellectronica: Yeah, something like that. I'm going to play around with it now and see what I can discover. | 11:33 |
| intellectronica | allenap: oh, it must have done something, because now in develop-eggs i have a new file, lazr.restful.egg-link | 11:35 |
| intellectronica | which seems to point to the right place | 11:35 |
| allenap | intellectronica: Cool, that sounds promising. | 11:35 |
| allenap | intellectronica: I had to comment out the version specification in versions.cfg too. | 11:37 |
| allenap | intellectronica: Then running bin/buildout used the "develop" version. | 11:38 |
| allenap | intellectronica: If you confirm that works for you I'll add it to the wiki. | 11:40 |
| intellectronica | allenap: well, i can confirm that _something_ happens. after doing that i get all sort of errors that seem unrelated. let me play with it a bit | 11:41 |
| intellectronica | oh, leonardr, i bet you can help me! | 11:41 |
| allenap | Good timing :) | 11:41 |
| leonardr | intellectronica, what's going on? | 11:42 |
| intellectronica | leonardr: i have a lazr.restful branch with a fix for a problem creating an etag for entries with non-unicode values. i want to test it with a development launchpad branch, but can't figure out how to do that with buildout | 11:43 |
| intellectronica | leonardr: good morning, b.t.w :) | 11:43 |
| leonardr | intellectronica: | 11:44 |
| leonardr | 1. symlink your lazr.restful branch to the root of your launchpad branch | 11:44 |
| leonardr | eg. [launchpad root]/lazr.restful | 11:44 |
| leonardr | 2. add the name of the symlink to buildout.cfg's 'develop' section | 11:44 |
| leonardr | for instance, i have a branch i use to test launchpadlib development | 11:47 |
| leonardr | and its develop section looks like this | 11:47 |
| leonardr | develop = | 11:47 |
| leonardr | . | 11:47 |
| leonardr | launchpadlib | 11:47 |
| leonardr | 3. run bin/buildout | 11:48 |
| intellectronica | leonardr: no, that doesn't seem to have worked. after doing that it still uses the released egg | 11:48 |
| leonardr | intellectronica: another thing you can do is do a release of lazr.restful with setup.py sdist, copy that tarball into download-cache, and update versions.cfg to point to the new tarball | 11:49 |
| mzz | that's what I did, and iirc it worked | 11:50 |
| mzz | although at some point I had to update that release and that took some prodding | 11:50 |
| leonardr | i don't know why the buildout.cfg doesn't work for you, you should ask gary about it | 11:52 |
| intellectronica | leonardr: yes, i'll do that | 11:52 |
| intellectronica | thanks a lot leonardr, allenap | 11:52 |
| allenap | intellectronica: Cool. | 11:52 |
| * henninge lunches | 12:30 | |
| === henninge is now known as henninge-lunch | ||
| jtv | allenap: I'm trying your ec2 workaround on jaunty (yes I do run karmic but on another machine, thank you) but for "ec2 land." It's not finding lazr.uri though! Any ideas? | 12:37 |
| === Ursinha-afk is now known as Ursinha | ||
| allenap | jtv: If it's available, install python-lazr-uri :-/ | 12:53 |
| jtv | no eggs? | 12:53 |
| jtv | allenap: quod non :-( | 12:54 |
| allenap | jtv: You could muck around with eggs I suppose. Or just bzr branch lp:lazr.uri foo and add foo/src to PYTHONPATH. | 12:55 |
| jtv | allenap: oh, that's not _too_ bad. Awkward, but at least it doesn't leave forgotten crud lying around in places where it'll hurt me later. | 12:55 |
| jtv | allenap: nope, not working either... I did setup.py build, then used the build dir as part of my python path. That leaves me with: type object 'Launchpad' has no attribute 'login_with' | 13:00 |
| allenap | jtv: Okay, that's an issue with launchpadlib. You may have an out of date lazr.restfulclient or launchpadlib. Gah.... | 13:03 |
| allenap | jtv: The following: | 13:03 |
| allenap | virtualenv --python python2.5 --no-site-packages gah | 13:03 |
| allenap | gah/bin/easy_install pip | 13:03 |
| allenap | gah/bin/pip install launchpadlib # Okay, easy_install would have done it, but I like pip. | 13:04 |
| * jtv installs python-virtualenv | 13:04 | |
| allenap | gah/bin/python -c 'from devscripts.ec2test.entrypoint import main; main()' ... | 13:04 |
| allenap | PYTHONPATH=lib gah/bin/python -c 'from devscripts.ec2test.entrypoint import main; main()' ... | 13:05 |
| allenap | jtv: Gah! You might need to do gah/bin/pip install bzr too. | 13:08 |
| jtv | allenap: wasn't done downloading yet anyway :) | 13:09 |
| === mrevell is now known as mrevell-lunch | ||
| === henninge-lunch is now known as henninge | ||
| allenap | jtv: Looks like there are a few more steps: http://pastebin.ubuntu.com/302781/ | 13:30 |
| jtv | allenap: thanks! | 13:30 |
| allenap | deryck: This might also help you: http://pastebin.ubuntu.com/302781/ | 13:30 |
| deryck | allenap, ok, thanks. will try here in a sec | 13:32 |
| sinzui | EdwinGrubbs: bac: stand-up in 2 minuted | 13:33 |
| === mrevell-lunch is now known as mrevell | ||
| jtv | allenap: moving along with your recipe... now it wants bzrlib.plugin as well. | 14:06 |
| allenap | jtv: Did you pip install bzr? | 14:06 |
| jtv | allenap: no, I don't think so | 14:06 |
| jtv | trying again... | 14:07 |
| allenap | jtv: I had to also install bzr, paramiko and boto. | 14:08 |
| jtv | allenap: now it just sits there doing nothing... | 14:08 |
| jtv | allenap: oh, I did have bzr installed; it's in your pasted recipe | 14:08 |
| jtv | so must have gotten the various paths and locations wrong | 14:08 |
| allenap | jtv: Strange that it didn't find it. | 14:09 |
| jtv | I probably did something stupid... I set this up in a different place than inside the branch so I can reuse it. | 14:09 |
| jtv | Interesting: it gets stuck in SSL read() | 14:09 |
| jtv | And this time, a "no such file or directory" | 14:10 |
| allenap | jtv: Argh! Can you paste the full error? | 14:10 |
| jtv | Ah, but that's when I actually try to _use_ ec2. I can get the help text out of it. | 14:10 |
| jtv | allenap: http://paste.ubuntu.com/302812/ | 14:11 |
| allenap | jtv: Oh :( I know what that it. ec2 land actually calls utilities/ec2 test. That's not going to work. You'll need to just use ec2 land --dry-run then call ec2 test -s "..." by hand. | 14:15 |
| allenap | jtv: Now, that won't work either. :-< | 14:16 |
| * allenap despairs | 14:16 | |
| allenap | jtv: Sorry, you'll have to craft the commit message and just run ec2 test directly. | 14:16 |
| allenap | jtv: Well, where "directly" means via the long, convoluted virtualenv approach. | 14:17 |
| jtv | allenap: ec2 test won't work either, so I think I'll go with local tests & pqm-submit. | 14:19 |
| allenap | jtv: Oh, is that the SSL hang you mentioned?> | 14:19 |
| jtv | allenap: oh, with all the incantations. Yes, I'll try that then | 14:19 |
| jtv | That was probably just a hung connection that didn't happen the second time... | 14:19 |
| jtv | unless it was the browser trying to ask me for authorizations | 14:20 |
| jtv | allenap: ec2 test works this way! | 14:26 |
| === adeuring1 is now known as adeuring | ||
| allenap | jtv: Hurrah :) I'm glad it didn't all turn out to be a waste of time :) | 14:29 |
| jtv | allenap: since you seem to understand what's going on, worth a wiki page maybe? | 14:30 |
| allenap | jtv: Yeah, coming up. | 14:30 |
| sinzui | EdwinGrubbs: I have been looking into the bugtask__product__milestone__fk you saw on staging. There appears to be a bad order of events. The error implies that the milestone was not removed from the bugtask. The code shows we do. | 14:42 |
| sinzui | EdwinGrubbs: I ponder two possible faults. 1) the view did not get all the bugtasks, or 2) the order of events played by Storm is different | 14:48 |
| sinzui | danilos: ^ can you speculate as two how I go about ensuring the data is in the correct state before the milestone is deleted? | 14:50 |
| sinzui | s/two/to/ | 14:50 |
| danilos | sinzui, reading up | 14:50 |
| danilos | sinzui, you can probably use the same trick we are using for account merging (i.e. following all the references; I don't know exactly how it's done, but that's what I'd look up as an example); also, could this be related to nominations? | 14:52 |
| sinzui | danilos: not exactly. https://dev.launchpad.net/RegistryTeam/RegistryTestPlans/3.1.10 | 14:54 |
| sinzui | danilos: The code does remove series targeted bugs. This issue relates to something that has been in production for 6 months. | 14:54 |
| stub | It is possible to set foreign key references to ON DELETE NULL if we need to | 14:55 |
| stub | That may be the right thing to do here (I don't know the details of the issue) | 14:55 |
| sinzui | I'm going to delete a lot of things and see if the error is consistent. | 14:57 |
| danilos | sinzui, I was going to suggest stub is a better person to ask, but then... :) | 14:57 |
| === absoludity is now known as noodles775 | ||
| sinzui | stub: I think the issue is the size of the delete. I can delete all the items in a small series, but a large one fails. | 15:04 |
| stub | sinzui: what exactly are you deleting? | 15:05 |
| sinzui | stub: https://staging.launchpad.net/launchpad-registry/2.2 | 15:05 |
| sinzui | stub: This is not a real world example. deletion is for mistakes | 15:05 |
| sinzui | but non-the-less, I did not expect an oops | 15:05 |
| stub | I was hoping for 'rows in the foo table' rather than a spec to read :) | 15:06 |
| EdwinGrubbs | sinzui: I wonder if the problem is caused by the update not being flushed. Are you updating bugtask.milestone to NULL by setting an attribute on an object or an SQL statement. | 15:06 |
| stub | So we are deleting a product series | 15:06 |
| sinzui | stub: actually we are deleting the releases and milestones, everything else in the operation is an unlink/update | 15:07 |
| sinzui | EdwinGrubbs: stub: the issue is milestone: I get the same error when I test just the milestone case: https://staging.launchpad.net/launchpad-foundations/+milestone/2.2.1/+delete | 15:10 |
| sinzui | bugger! | 15:11 |
| === cody-somerville_ is now known as cody-somerville | ||
| stub | If you have an OOPS, you should have a statement log which will tell you if edwin is right and a flush is needed (possible storm bug) | 15:11 |
| intellectronica | gary_poster: hi, can i bother you for some help with buildout? | 15:12 |
| sinzui | stub: EdwinGrubbs I think this is a code issue The milestone +index and milestone +delete list a different number of bugs. I think some bugs are being excluded from | 15:12 |
| sinzui | params = BugTaskSearchParams(milestone=target, user=None) | 15:12 |
| gary_poster | intellectronica: hi, absolutely. what's up | 15:13 |
| EdwinGrubbs | sinzui: it probably uniques on the bug id. | 15:13 |
| sinzui | ! stub: EdwinGrubbs private bugs are not included in the results | 15:14 |
| intellectronica | gary_poster: i have a lazr.restful fix i want to test with a development lp branch, but i can't seem to make my lp branch use the lazr.restful branch instead of the egg | 15:14 |
| stub | sinzui: We wouldn't have caught that if we used a cascading foreign key constraint | 15:14 |
| sinzui | EdwinGrubbs: this has been broken for months then. I guess no one has ever tried to delete a milestone that had private bugs targeted to it (again this is not the really how we intended this feature to be used) | 15:15 |
| gary_poster | intellectronica: ok, there are two ways to do it that should work. one is to use develop egg, which is a way to use a branch; and the other is to make an sdist and test that way. Let me see if I think the buildout.txt doc describes either or both of those in sufficient detail to be helpful in our conversation... | 15:15 |
| sinzui | stub: EdwinGrubbs: thanks for you assistance, I can open a bug for this issue now. | 15:15 |
| intellectronica | gary_poster: i think that using the branch itself is my preference. i tried doing that by adding the path to the develop setting of the buildout confing, but i must be getting something wrong. and yes, documentation will be great (if it's insufficient i'm happy to extend it once i get The Knowledge) | 15:17 |
| gary_poster | intellectronica: :-) ok, cool. yeah, there are no docs for that option. thank you for the offer. so, can you pastebin your launchpad diff and I'll look at it? It sounds like you are on the right track. | 15:18 |
| gary_poster | intellectronica: and did you run make, or (even better) bin/buildout after making the change to buildout.cfg? | 15:19 |
| intellectronica | gary_poster: i did run bin/buildout | 15:19 |
| gary_poster | cool | 15:20 |
| intellectronica | gary_poster: http://pastebin.ubuntu.com/302859/ (note that lazr.restful is a symlink to the branch i want to use) | 15:21 |
| gary_poster | intellectronica: I am of two minds as to whether I hope this fixes the problem ;-) but try putting those on two different lines? e.g. http://pastebin.ubuntu.com/302862/ . It's lame if that fixes it (an error message would have been nice, for instance), but that's what I would have expected to see. | 15:23 |
| intellectronica | gary_poster: i've tried that too, and it didn't make any difference | 15:25 |
| gary_poster | intellectronica: ok, fair enough. so, I take it there are no errors when you run bin/buildout, or else you would have told me about them. The only other thing I would expect to have to do is specify the new version of lazr.restful in versions.cfg. I hoped that would raise an error too, but give that a try. Am I right in guessing that your lazr.restful branch has a different version than the one specified in versions.cfg? | 15:27 |
| intellectronica | gary_poster: no, that may be what i'm missing. how should i specify the new version of lazr.restful? | 15:28 |
| === deryck is now known as deryck[lunch] | ||
| gary_poster | intellectronica: in your lazr.restful branch, there should be a version.txt (or similar) in src/lazr/restful. Make sure that is incremented. in versions.cfg of launchpad, make sure that the version specified for lazr.restful matches that version. (fwiw, this has been more obvious in the past; maybe I introduced a regression somewhere. :-/ ) | 15:30 |
| intellectronica | gary_poster: so just increment the value in version.txt to the next minor version, and adjust versions.cfg in my lp branch to match that? | 15:32 |
| gary_poster | intellectronica: yes | 15:33 |
| gary_poster | intellectronica: (fwiw, in lazr.restful, what you are *really* doing is increasing the revision in its setup.py. We do it this way for this package) | 15:33 |
| intellectronica | wow, it gets even more complicated. the version in versions.cfg is two minor revisions behind the current restful. does it mean that i have to branch from an earlier revision? | 15:34 |
| gary_poster | intellectronica: is this for a CP? | 15:34 |
| intellectronica | gary_poster: no, why? | 15:35 |
| gary_poster | intellectronica: you would only need to branch from an earlier revision if you were making a CP (so that you are only going to change the minimal amount necessary for the change in production). In this case, you are fine. Update version.txt, change versions.cfg to match, and move on. | 15:36 |
| gary_poster | intellectronica: (more complicated? bah. :-) This sucks because I didn't document it, and because the errors are not helpful/non existent. But So far we have "symlink the branch" "add the line to buildout.cfg" "make sure your branch has an updated version (as you would normally)" and "set the new version number in versions.cfg". So, bah. :-) ) | 15:38 |
| gary_poster | (But agreed the docs and error sitation suck. :-( ) | 15:39 |
| intellectronica | gary_poster: tadaaa! :) | 15:39 |
| gary_poster | ITR :-) | 15:39 |
| gary_poster | yay! | 15:39 |
| intellectronica | thanks muchly. any suggestions on where would be a good place to document it? wiki? text file? | 15:39 |
| gary_poster | well, doc/buildout.txt would be the historical place. There have been arguments about this between various People Who Will Not Be Nicked :-) . I'd put it in doc/buildout.txt myself, unless you want to put it in the wiki, in which case you can JFDI or raise it in an email and see the fun :-) | 15:40 |
| intellectronica | nah, i also prefer buildout.txt | 15:41 |
| gary_poster | cool | 15:41 |
| sinzui | EdwinGrubbs: Can you retest the delete series + structural subscription with https://staging.launchpad.net/launchpad-documentation/2.2 . I am subscribed to the series and the 2.2.1 milestone | 15:41 |
| EdwinGrubbs | sinzui: ok, I'm deleting it now. | 15:42 |
| EdwinGrubbs | sinzui: it deleted fine. | 15:45 |
| sinzui | EdwinGrubbs: fab | 15:45 |
| sinzui | I am still reporting the bug you discovered. I realise that this fix is not trivial. It is possible for a driver to target a private bug that the milestone owner or release manager cannot see | 15:46 |
| === matsubara is now known as matsubara-lunch | ||
| === salgado is now known as salgado-lunch | ||
| === beuno is now known as beuno-lunch | ||
| henninge | Where can I find or activate a query log on launchpad.dev? | 16:24 |
| henninge | So that I can see what sql queries where issued. | 16:24 |
| henninge | danilos: ^ any idea? | 16:30 |
| henninge | danilos: btw, I think I found the problem for the templates listing but I need to verify it. | 16:30 |
| === salgado-lunch is now known as salgado | ||
| === matsubara-lunch is now known as matsubara | ||
| === deryck[lunch] is now known as deryck | ||
| === leonardr is now known as leonardr-afk | ||
| rockstar | abentley, replied to your review | 17:06 |
| deryck | BjornT_, ping | 17:15 |
| BjornT_ | deryck: pong? | 17:15 |
| sinzui | flacoste: I am ready for our call. I am idling my time refactoring a test | 17:32 |
| === beuno-lunch is now known as beuno | ||
| intellectronica | so, how do i merge a lazr.restful branch now? just do it manually? | 17:47 |
| intellectronica | also, once i do that, how do i make lp use the new revision? | 17:47 |
| intellectronica | gary_poster: maybe you can help? | 17:48 |
| intellectronica | sorry, i'm bugging you a lot today | 17:48 |
| gary_poster | intellectronica: :-) np | 17:48 |
| gary_poster | intellectronica: so, once you have a review, you merge it manually. We want to do it in such a way that we get the usual [r=foo] commit messages for the trunk. I have heard that there is a more elegant way to do this, and maybe you know it, but I just check out ``co`` the trunk, merge the reviewed branch, and commit with the desired commit message ([r=foo] blah blee bloo). | 17:51 |
| gary_poster | For making LP use the new revision, we have docs (looking...) | 17:51 |
| gary_poster | well, I don't talk about making a release, just incorporating it | 17:52 |
| gary_poster | intellectronica: for making a public release, there is a wiki page. See bottom ("Releases") section of https://dev.launchpad.net/HackingLazrLibraries. I haven't tried it. Ask leonardr for help (I am having lunch in < 5 min). You will need privs. | 17:54 |
| intellectronica | gary_poster: excellent, thanks | 17:55 |
| gary_poster | intellectronica: just for our needs, you can do step 1 (python setup.py sdist) and then move the sdist to the download-cache/dist directory. Then see the "Upgrade a Package" section of buldout.txt. Honestly, you don't have to do the fancy ./bin/buildout command from step 4 in those instructions--just bin/buildout should be fine since you have already populated the download-cache | 17:57 |
| gary_poster | intellectronica: also, note that the [TODO] section in 5 ("Test") has been done: see the -c oprion in ec2 test. | 17:57 |
| gary_poster | intellectronica: OK, I have to run to lunch. Will be back in a bit | 17:58 |
| intellectronica | gary_poster: i'll be away by then, but will continue later/tomorrow. enjoy lunch | 17:58 |
| === EdwinGrubbs is now known as Edwin-lunch | ||
| mrevell | G'night all. I'm off to cook some spag and some bol. | 18:01 |
| rockstar | abentley, hi | 18:23 |
| abentley | rockstar: hi | 18:23 |
| rockstar | abentley, did you see my reply to your review? | 18:23 |
| abentley | I did. I'm looking over it now. | 18:24 |
| rockstar | abentley, great. Can I send you a followup. | 18:24 |
| rockstar | Er, a followup branch. | 18:24 |
| abentley | rockstar: okay. | 18:24 |
| abentley | Oh, a whole 'nother branch? | 18:24 |
| rockstar | abentley, yeah, but it's really small. | 18:24 |
| abentley | rockstar: alright. | 18:24 |
| abentley | rockstar: I'm almost inclined to think it's a bug that create_branch_and_tree doesn't set target.branch_format and target.repository_format. | 18:26 |
| abentley | rockstar: replied. | 18:39 |
| === leonardr-afk is now known as leonardr | ||
| === leonardr is now known as leonardr-afk | ||
| === Edwin-lunch is now known as EdwinGrubbs | ||
| thumper | morning | 20:05 |
| === salgado is now known as salgado-afk | ||
| === leonardr-afk is now known as leonardr | ||
| * thumper has real coffee from fluid | 20:53 | |
| thumper | yum | 20:53 |
| === matsubara is now known as matsubara-afk | ||
| sinzui | thumper: abentley: I think code/browser/test_views could test everything on the DatabaseFunctionalLayer | 21:21 |
| thumper | sinzui: prolly | 21:21 |
| sinzui | thumper: I pushed two branches to lp:dev and create an MP. What do I run to scan the branches and create the diff? | 21:28 |
| thumper | sinzui: make sync_branches | 21:32 |
| thumper | sinzui: although that doesn't create the diff | 21:32 |
| thumper | sinzui: abentley was talking about making more make targets to do these | 21:32 |
| sinzui | well at least that saw my branches | 21:33 |
| thumper | sinzui: right now I think you need to run the cron script manually | 21:33 |
| sinzui | thumper: right I was doing that and am fine | 21:33 |
| thumper | flacoste: are we talking today? | 21:34 |
| flacoste | thumper: we should, i'm still on the phone with gary | 21:34 |
| thumper | ok | 21:34 |
| thumper | flacoste: afk for a few minutes | 21:43 |
| === Ursinha is now known as Ursinha-afk | ||
| thumper | rockstar: ping | 21:54 |
| rockstar | thumper, pong | 21:54 |
| flacoste | thumper: i hung up | 21:58 |
| thumper | flacoste: ok, talk now? | 21:58 |
| flacoste | thumper: yep | 21:58 |
| EdwinGrubbs | sinzui: ping | 22:07 |
| sinzui | Hi EdwinGrubbs | 22:08 |
| EdwinGrubbs | sinzui: I'm wondering if I should change "See full publishing history" to just "Full Publishing History" to avoid wrapping. https://chinstrap.canonical.com/~egrubbs/publishing_history_link.png | 22:09 |
| EdwinGrubbs | sinzui: Also, since I'm on that page already, I could add a javascript:confirm() to the delete button, but I don't know if that fits in with our general ajax style. | 22:10 |
| sinzui | EdwinGrubbs: why add a confirm. Users have not reported a bug about that feature in the two years it has been available? | 22:11 |
| EdwinGrubbs | sinzui: well, every delete button in a rails app asks you to confirm it, and it seems like a sane convention. | 22:12 |
| sinzui | EdwinGrubbs: I see what you are seeing in the menu. We see it because we are modern men who understand that a windowed GUI and multi-tasking is practical. The design we have is for maximised windows though | 22:13 |
| wgrant | sinzui: Previously it was a button. | 22:13 |
| wgrant | Now it is not. | 22:14 |
| wgrant | However, there are other 'green' delete links that have no text, so are not obviously green (the bug team unsubscription links, for example) , so it is not unprecedented. | 22:14 |
| sinzui | EdwinGrubbs: we have many delete ops in Launchpad. I would expect a page that explains the consequences of my action. | 22:15 |
| sinzui | EdwinGrubbs: I agree that confirmation is good, I do not agree with a js infobox. Linking is a part of our focus so we can fix this next release | 22:16 |
| EdwinGrubbs | ok, I won't touch it. | 22:16 |
| sinzui | EdwinGrubbs: I think the real problem with the action menu is not that we are expect to browser with window's maximised, but because we did not consider wrapping rules | 22:17 |
| sinzui | EdwinGrubbs: We might want a hanging indent style so that all the link text does not appear under the icon | 22:17 |
| sinzui | something like this may make the action menu pleasant: text-indent: -20px; padding-left -20px; | 22:20 |
| sinzui | wgrant: if you delete a packaing link, is there information you expect to see on a confirmation screen that would make you change your mind? The history of versions in the series perhaps? | 22:22 |
| wgrant | sinzui: I don't think there's anything useful besides the series and SP. | 22:25 |
| sinzui | wgrant: thanks. I too could not think of anything more than what you can see on the page already | 22:25 |
| === flacoste is now known as flacoste_afk | ||
| al-maisan | hmm .. I am getting the following error when running "make": | 23:27 |
| al-maisan | /usr/bin/python2.4: can't open file 'sourcecode/lazr-js/tools/build.py': [Errno 2] No such file or directory | 23:27 |
| al-maisan | any idea how this can be mended? | 23:27 |
| mwhudson | al-maisan: is your sourcecode directory up to date? | 23:28 |
| al-maisan | BTW, this is a brand new db-devel branch and I did a rocketfuel-get beforehand | 23:28 |
| wgrant | Did you link-external-sourcecode? | 23:29 |
| mwhudson | maybe your update-sourcecode is too up to date :/ | 23:29 |
| al-maisan | aha..? | 23:29 |
| al-maisan | wgrant: yes | 23:30 |
| wgrant | :( | 23:31 |
| al-maisan | I am missing a sourcecode/lazr-js link though.. | 23:31 |
| wgrant | That would do it... | 23:31 |
| al-maisan | .. and I don't have it in ../../lp-sourcedeps/ either | 23:32 |
| al-maisan | I guess I could pull it manually | 23:32 |
| mwhudson | is it in utilities/sourcedeps.conf ? | 23:32 |
| * al-maisan looks | 23:33 | |
| al-maisan | mwhudson: yes | 23:33 |
| al-maisan | I fetched lazr-js manually | 23:34 |
| mwhudson | al-maisan: i guess running ./utilities/update-sourcecode would work | 23:34 |
| al-maisan | mwhudson: thanks for the tip! | 23:34 |
| wgrant | But doesn't rocketfuel-get do that? | 23:35 |
| mwhudson | yeah, i wonder how rocketfuel-get does this currently | 23:35 |
| mwhudson | hmm odd | 23:36 |
| wgrant | al-maisan: Is there an existing spec somewhere for Debian source format 3.0 support? | 23:38 |
| al-maisan | wgrant: I am not aware of any .. | 23:39 |
| al-maisan | wgrant: I'll look and let you know more tomorrow .. it's getting late here :P | 23:39 |
| wgrant | 'cause as james_w says, it is getting pretty critical. | 23:39 |
| wgrant | al-maisan: Yes, just a bit... | 23:39 |
| al-maisan | wgrant: yup .. saw his email | 23:40 |
| mwhudson | time for lunch, qa for my afternoon snack... | 23:50 |
| thumper | :) | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
