| mtaylor | thumper: see, so you talk about me, and then you run away | 00:11 |
|---|---|---|
| thumper | mtaylor: sorry forgot about you :) | 00:11 |
| mtaylor | thumper: it happens | 00:11 |
| === mup_ is now known as mup | ||
| * mtaylor wants a tool that will connect to launchpad, grab all the users in a team and their ssh keys and make local users for each of them | 00:30 | |
| wgrant | I think my script for that is gone. | 00:30 |
| wgrant | I had one a couple of years ago, though. But there is now a tool floating around to create a user with keys from an LP username, so it'd be easy to script up. | 00:31 |
| wgrant | Plus... the API makes it nice and easy. | 00:31 |
| wgrant | No more screenscraping. | 00:31 |
| lifeless | mtaylor: why not pam_launchpad ? | 00:40 |
| lifeless | static is so 1970's | 00:40 |
| mtaylor | lifeless: speed? | 00:40 |
| lifeless | premature optimisation:) | 00:41 |
| mtaylor | lifeless: ha! | 00:41 |
| mtaylor | lifeless: I was also thinking of a hudson security module which would delegate to launchpad ... but seeing as how I'm two plugins behind, I think perhaps adding another one is also premature | 00:42 |
| wgrant | mtaylor: OpenID? | 00:42 |
| mtaylor | wgrant: yeah, that would be part of it | 00:42 |
| mtaylor | wgrant: but I was thinking similar to above- if in hudson I said "hey, deal with launchpad project X" | 00:42 |
| mtaylor | wgrant: and it knew how to do tarmac stuff with that project, but also would use launchpad user/team info to grant people hudson access to build related stuff for that project... | 00:43 |
| mtaylor | see, I think entirely too large | 00:43 |
| lifeless | you'll want to see my stalled openid patch, in that case. | 00:49 |
| === Ursinha is now known as Ursinha-afk | ||
| === vila_ is now known as vila | ||
| adeuring | good morning | 08:21 |
| === mrevell__ is now known as mrevell | ||
| jml | good morning Launchpadders | 09:17 |
| bigjools | b'jour | 09:17 |
| noodles775 | BjornT or otherwise: to run launchpad with postgresql8.4, do I just install it, update the ports so 8.4 is running on 5432, stop 8.3 and run launchpad-database-setup? | 10:28 |
| deryck | Morning, all. | 11:03 |
| thumper | jelmer: ping | 11:23 |
| jelmer | thumper: otp | 11:27 |
| thumper | jelmer: ack | 11:27 |
| jelmer | thumper: hi | 11:36 |
| thumper | jelmer: got any idea why dulwich is leaving behing uncollectable garbage in the test suite? | 11:37 |
| jelmer | thumper: no | 11:37 |
| jelmer | thumper: which files? | 11:37 |
| thumper | jelmer: see BjornT's email about the import tests | 11:37 |
| * thumper looks | 11:37 | |
| thumper | [<dulwich.pack.PackData object at 0x9e06e50>] (referenced from [(<dulwich.pack.PackData object at 0x9e06e50>,), [<dulwich.pack.PackData object at 0x9e06e50>], {'_basename': '/tmp/tmpFhvH-A/.git/objects/pack/pack-120fc662d24725ba18915fe0c17eea6644adc3fe', '_data': <dulwich.pack.PackData object at 0x9e06e50>, '_idx_path': '/tmp/tmpFhvH-A/.git/objects/pack/pack-120fc662d24725ba18915fe0c17eea6644adc3fe.idx', '_idx': <dulwich.pack.PackIndex1 | 11:38 |
| thumper | object at 0x9e06e90>, '_data_path': '/tmp/tmpFhvH-A/.git/objects/pack/pack-120fc662d24725ba18915fe0c17eea6644adc3fe.pack'}]) | 11:38 |
| BjornT | noodles775: yes, more or less. following the manual step (replacing 8.3 with 8.4) in https://dev.launchpad.net/DatabaseSetup works. haven't tried launchpad-database-setup, but please let me know whether it works | 12:27 |
| wgrant | I've done it by purging 8.3 and installing 8.4. But dropping the 8.3 cluster and installing 8.4 should be just as effective | 12:28 |
| wgrant | Then launchpad-database-setup works fine. | 12:28 |
| noodles775 | BjornT, wgrant: yes, it worked fine... I just modified the config so 8.3 isn't started. I had to install some extra 8.4 packages, but other than that launchpad-database-setup worked fine. | 12:32 |
| wgrant | Launchpad should really fix the Referer thing. | 12:39 |
| james_w | it's to prevent XSRF? | 12:42 |
| wgrant | Yes. | 12:42 |
| james_w | yeah, not ideal | 12:42 |
| wgrant | I suggested it, since i knew the real fix wouldn't be scheduled for a decade, unless there were enough complaints about the Referer check. | 12:42 |
| wgrant | Since one me complaining about security holes is probably easier to ignore. | 12:42 |
| james_w | I'm frequently surprised by how few frameworks come with built-in XSRF protection. | 12:42 |
| james_w | or at least convenience methods for doing it | 12:43 |
| wgrant | Indeed. | 12:43 |
| wgrant | It shouldn't be terribly difficult for LP, since all/most JS requests go through the JS API wrapper | 12:44 |
| james_w | not the easiest thing to apply to every form from a framework, but at least suggesting that people use it wouldn't be hard | 12:44 |
| wgrant | Right. | 12:44 |
| wgrant | JS-less Django apps can use middleware. | 12:45 |
| wgrant | (see c-i-p) | 12:45 |
| james_w | it could even be just thrown in memcached I guess? | 12:45 |
| wgrant | Possibly. | 12:45 |
| wgrant | But there is no good way to fix XSRFs : | 12:45 |
| wgrant | ( | 12:45 |
| wgrant | All of them are broken in various ways. | 12:45 |
| noodles775 | http://docs.djangoproject.com/en/dev/releases/1.2/#improved-csrf-protection | 12:45 |
| james_w | really? | 12:45 |
| james_w | \o/ for django | 12:46 |
| wgrant | Referer checking is broken, as we've seen. | 12:46 |
| wgrant | And throwing a token into every form means that distributing or caching that HTML is dangerous. | 12:47 |
| james_w | ah, I see, I thought you meant that it was consistently possible to beat the probabilities | 12:48 |
| wgrant | (plus forms probably have to time out) | 12:48 |
| === matsubara-afk is now known as matsubara | ||
| === Ursinha-afk is now known as Ursinha | ||
| g4tsu | Hi | 13:52 |
| g4tsu | I've installed my own launchpad and I want to know how to include my .deb packages | 13:53 |
| g4tsu | Because the documentation says that we have to use dput with .dsc .changes .orig.tar.gz etc and we haven't this type of file | 13:54 |
| g4tsu | Hello mars, it's ghostoyo | 13:55 |
| gary_poster | thank you lifeless | 14:01 |
| deryck | adeuring or intellectronica -- could I get a review from one of you? Should be very easy. | 14:02 |
| adeuring | deryck: yure | 14:02 |
| deryck | adeuring, thanks! https://code.edge.launchpad.net/~deryck/launchpad/subscribe-to-bug-mail-twice-577768/+merge/25532 | 14:02 |
| g4tsu | nobody can help me ? | 14:08 |
| adeuring | deryck: r=me | 14:10 |
| deryck | adeuring, thanks! | 14:10 |
| maxb | g4tsu: It seems to me that if you're uncertain of how to use dput, then attempting to set up your own Launchpad instance is a matter of attempting to run before you can walk | 14:16 |
| === henninge_ is now known as henninge | ||
| bac | reviewers meeting starting now. | 15:01 |
| mars | sinzui, please let me know if you see another ec2 suite hang. | 15:39 |
| sinzui | okay | 15:39 |
| mars | sinzui, otherwise, the situation was well-covered by Gary and the mail I sent the list yesterday. It should NOT hang now. | 15:39 |
| mars | g4tsu, I think maxb's advice is wise. Best to understand how packaging works before you attempt to set up your own private LP-hosted repository. | 15:41 |
| mars | g4tsu, to my knowledge, you would also be best off talking to maxb and wgrant about running a private LP repository that way. They know worlds more about it than I do. | 15:42 |
| maxb | g4tsu: Also, I have to ask... you're aware about the bit of the Launchpad licence which demands you replace all the images and icons if you create a private installation of any kind? | 15:43 |
| === matsubara is now known as matsubara-lunch | ||
| adiroiban | any idea what is causing and how can I fix this make link warning | 16:28 |
| adiroiban | warning: Not importing directory '/usr/share/pyshared/lazr': missing __init__.py | 16:28 |
| adiroiban | s/link/lint/ | 16:28 |
| g4tsu | maxb> yep I'm aware of that | 16:47 |
| === beuno is now known as beuno-lunch | ||
| === salgado is now known as salgado-lunch | ||
| mars | maxb, allenap, your investigation yesterday makes perfect sense: the killem() function was killing the wrong process group. Here is a healthy process tree before killem gets to it (note the PGIDs): http://pastebin.ubuntu.com/436221/ | 17:24 |
| allenap | mars: Woohoo :) | 17:29 |
| adiroiban | danilos, henninge: is there a XPI template in the testing/demo LP database? | 17:33 |
| danilos | adiroiban, it's constructed from a bunch of files for testing | 17:33 |
| danilos | adiroiban, see lib/lp/translations/utilities/tests/xpi_helpers.py | 17:34 |
| adiroiban | danilos: so the sample database does not contain such a file? | 17:34 |
| danilos | adiroiban, no, and you shouldn't use it for tests either :) anyway, you should probably not worry about exporting source_file property right now | 17:34 |
| adiroiban | danilos: it is easy to export | 17:35 |
| danilos | adiroiban, (you shouldn't use sampledata for tests is what I mean) | 17:35 |
| adiroiban | but it looks like all POTemplates | 17:35 |
| adiroiban | don't have an associated source_file | 17:35 |
| danilos | adiroiban, sure, but the branch grows and you slow down the review for something that is not critical for what you set out to do (i.e. you are widening the scope without really needing to) | 17:35 |
| danilos | adiroiban, right, we don't extend sampledata at all anymore | 17:37 |
| adiroiban | danilos: ok. I was just curious about the usage of the source_file attribute. I will not export it in this branch :) | 17:39 |
| danilos | adiroiban, oh, it's also only used for XPI files so far | 17:39 |
| adiroiban | danilos: in the sample data, all source_file attributes for potemplates are null | 17:40 |
| danilos | adiroiban, there are no imported XPI files in the sample data :) | 17:40 |
| adiroiban | danilos: I see, and I was wondering why it is not used for other templates | 17:40 |
| === matsubara-lunch is now known as matsubara | ||
| danilos | adiroiban, it would take up space in the librarian (they could not be deleted after import), and we don't need them; we need en-US.xpi files to be able to re-construct translated XPI files (though we never got far enough with implementing that) | 17:41 |
| danilos | anyway, I'm leaving now | 17:41 |
| adiroiban | danilos: thanks. have a nice evening :) | 17:41 |
| danilos | adiroiban, cheers :) | 17:42 |
| === deryck is now known as deryck[lunch] | ||
| mrevell | Night all | 17:59 |
| === beuno-lunch is now known as beuno | ||
| === salgado-lunch is now known as salgado | ||
| === deryck[lunch] is now known as deryck | ||
| === gary_poster is now known as gary-afk | ||
| Darkpsy | Is it best to go through the launchpad setup procedure as root or non-root? I tried it both ways and Apache is throwing errors. One error states it can't find /var/tmp/archive | 20:41 |
| adiroiban | Darkpsy: just create that folder ... but rocketfuel-setup should take care of everyhing | 20:43 |
| Darkpsy | adiroiban: in that case, what folder should hold the main part of launchpad? | 20:44 |
| adiroiban | devel branch | 20:44 |
| Darkpsy | ok | 20:45 |
| Darkpsy | I'm now getting this error: http://paste.ubuntu.com/436367/ | 21:02 |
| adiroiban | Darkpsy: have you uploaded your ssh key on LP ? | 21:06 |
| adiroiban | can you use bzr with LP ? | 21:07 |
| Darkpsy | i have uploaded my ssh key to LP, this is the first time i've used bzr with LP since I didn't need to before | 21:08 |
| Darkpsy | i think i found the problem. one sec | 21:09 |
| Darkpsy | got it working now. turns out I imported the wrong key | 21:12 |
| === gary-afk is now known as gary_posrer | ||
| === gary_posrer is now known as gary_poster | ||
| mwhudson | mars: so i guess i should make my backtrace thingy a project really | 21:49 |
| mars | mwhudson, well, a setup.py would be a great start :) I thought of writing one, but didn't need it. | 21:53 |
| mars | mwhudson, if it was a project with a setup.py, then we could roll it into the Launchpad distribution. I might do that anyway. | 21:57 |
| mars | mwhudson, the other problem is detecting if debug symbols are available. Without them I get a GdbError - maybe there is some way to gracefully detect if things are wrong. | 21:57 |
| mars | ahead of time | 21:58 |
| mwhudson | mars: those both sound like good ideas, they should be bugs ... which means setting up a project :) | 21:58 |
| mars | heh | 21:59 |
| === matsubara is now known as matsubara-afk | ||
| === salgado is now known as salgado-afk | ||
| wgrant | Um. | 22:39 |
| wgrant | What's the memcached work that landed this morning? | 22:39 |
| wgrant | It seems far, far, far too aggressive. | 22:39 |
| wgrant | To the point of making at least the milestone view almost useless. | 22:39 |
| wgrant | sinzui: Was it insufficient to cache each bugtask row? | 22:43 |
| wgrant | Even that is too aggressive for that view, but it's not quite so bad. | 22:43 |
| wgrant | I imagined that memcached would be used for caching links and non-critical "Latest [blah]" sort of things. | 22:44 |
| wgrant | Not for major sources of time-critical data like milestone listings. | 22:44 |
| sinzui | wgrant, it speed up the listing of milestone pages on staging. It was very impressive. | 22:45 |
| wgrant | sinzui: Yes, but it also makes them much more confusing and less useful. | 22:45 |
| sinzui | wgrant, the milestone view is one the top timeouts and the cause is the bug privacy and the number of bugs | 22:45 |
| wgrant | Of course it's going to make them much faster. | 22:45 |
| wgrant | I want my milestone view to not lie to me. | 22:46 |
| wgrant | I use it frequently. | 22:46 |
| sinzui | wgrant, yes, that is why I landed it eary in the cycle | 22:46 |
| lifeless | do we still use SQLOS in any way? | 22:46 |
| sinzui | wgrant, cool can you fix it for me then? you will be the 4th developer to wortk on this | 22:46 |
| wgrant | When my team is triaging a milestone, we refresh frequently and need to see each other's changes immediately. | 22:46 |
| wgrant | I am thinking about how best to do it. | 22:46 |
| wgrant | Is the query for finding visible bugs really that bad? | 22:47 |
| * wgrant must have a look at some point. | 22:47 | |
| sinzui | we can adjust the cache time. | 22:47 |
| sinzui | wgrant, I too refresh often. We do not have tools to invalidate cache. I would have used them if they existed | 22:48 |
| wgrant | I think until we can invalidate, we can't safely cache that sort of thing. Top contributors, latest bugs, latest uploads, sure. | 22:50 |
| sinzui | wgrant, on cache rule is to only cache anonymous. We can switch to that and make bots happy. For users, they will still get timeouts | 22:50 |
| wgrant | Aspects of the bug rows on that page (tags, for example, that caused problems when they were temporarily switched on a while ago), maybe. | 22:50 |
| wgrant | But entire bug task rows won't work sanely yet. | 22:50 |
| sinzui | wgrant, I have considered everything you have mentioned. You are correct, but I have timeouts I am responsible for ending. I will adjust the rules as best I can, and will add and removed them as needed. | 22:53 |
| mwhudson | mars: https://code.edge.launchpad.net/~pygdb-hackers/pygdb/trunk | 23:23 |
| mwhudson | mars: it's based on a bzr-svn import of the pygdb upstream, so you'll need to recreate your branches i'm afraid | 23:23 |
| mwhudson | mars: rebased the branch again i'm afraid | 23:47 |
| mwhudson | (i'll stop this now) | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!