| === xenru|clone [n=Miranda@85.192.13.231] has joined #launchpad | ||
| kiko | ddaa, I think that caching of images/other references would be a much greater speed improvement than your former suggestion, tbh. | 12:32 |
|---|---|---|
| ddaa | I think that the caching issue is tied to the https issue, isn't it? | 12:33 |
| ddaa | And they are two sides of the same coin. Improving perceived speed involves improving actual speed, but also providing early feedback. | 12:34 |
| kiko | ddaa, yeah, it is tied to the https issue. but that would be the largest speed gain we could produce today. | 12:38 |
| ddaa | ack, I thought that streaming pages could be magically produced by the right zope incantations. | 12:39 |
| ddaa | I certainly see nothing in TAL that would prevent that. | 12:39 |
| elmo | ehm, so. lightweight checkouts are cool and all | 01:02 |
| kiko | elmo, but...? | 01:03 |
| elmo | ah, nm, let me try something before making myself look stupid(er) | 01:04 |
| LarstiQ | elmo: you have quite some credit to burn through before that happens though. | 01:05 |
| === bradb heads home | ||
| lifeless | elmo: also, #bzr may be better | 01:26 |
| elmo | lifeless: I doubt it ;-) it was how do I implement this on sodium question | 01:28 |
| elmo | but I'm muddling through | 01:28 |
| elmo | p.s. y'all suck at documenting LP development, kthx | 01:28 |
| === erdalronahi_ [n=erdal@p5087746D.dip.t-dialin.net] has joined #launchpad | ||
| lifeless | elmo: on sodium? | 01:30 |
| === niemeyer [n=niemeyer@200-163-195-183.ctame7006.dsl.brasiltelecom.net.br] has joined #launchpad | ||
| elmo | lifeless: I'm trying to work out how to do lightweight checkouts without having to sync my lightweight-but-still-way-too-large-for-my-adsl repo directory up to sodium | 01:35 |
| lifeless | elmo: have a local repo, use a lightweight checkout from that, rsync the repo to sodium | 01:36 |
| lifeless | as jamesh documents | 01:36 |
| lifeless | lightweight checkouts are only of use within a LAN/local disk | 01:36 |
| elmo | rsync which repo? | 01:36 |
| elmo | the one with the 200Mb .bzr? | 01:37 |
| lifeless | https://launchpad.canonical.com/WorkingWithSharedRepositories | 01:38 |
| elmo | yeah, I know, I've read it | 01:39 |
| lifeless | maybe the question I should ask is 'why do you want to have a lightweight checkout' ? | 01:39 |
| elmo | because the last time I did anything with LP, I ran out of disk space on my laptop | 01:39 |
| elmo | so having them locally is very attractive | 01:39 |
| lifeless | do you mean 'not having..' ? | 01:40 |
| elmo | blink | 01:40 |
| elmo | no, I mean "having light weight checkouts as opposed to space sucking heavyweight ones, is very attractive" | 01:41 |
| elmo | anyway, don't worry about it, I'm probably being stupid - I'll try again tomorrow morning when I'm awake, and go back to normal branches which I know to handle with pqm if I fail | 01:41 |
| lifeless | do you have a local repository ? | 01:42 |
| lifeless | sabdfl: btw - https://launchpad.net/products/bzr/+roadmap - is not optimal for us at the moment | 02:02 |
| lifeless | there are specs scattered all over by priority. is it possible to get jamesh or someone to look at tuning the roadmap algorithm ? | 02:03 |
| lifeless | I would, but I'm a little short on time | 02:03 |
| sabdfl | lifeless: it's certainly way off base there | 02:15 |
| sabdfl | by all means ask him to redo it | 02:15 |
| sabdfl | he's welcome jsut to reimplement rather than trying to unparse the illogic | 02:15 |
| lifeless | thanks | 02:16 |
| === jml [n=jml@203-217-8-89.perm.iinet.net.au] has joined #launchpad | ||
| lifeless | jamesh: ping | 02:30 |
| === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad | ||
| lifeless | BjornT: around ? | 02:56 |
| jamesh | lifeless: pong | 03:52 |
| lifeless | hi | 03:54 |
| === mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #launchpad | ||
| lifeless | I've filed a bug on the spec roadmap | 03:55 |
| jamesh | okay | 03:55 |
| lifeless | are you interested in making it display useful things ? :) | 03:55 |
| lifeless | if you are, I'll ask steve about scheduling of it | 03:55 |
| jamesh | I'll be doing some spec/sprint tracker stuff between now and the next conf | 03:56 |
| jamesh | so I can probably look at it | 03:56 |
| jamesh | what's the bug? | 03:56 |
| lifeless | just look at blueprint | 03:56 |
| lifeless | latest-bugs :) | 03:56 |
| jamesh | https://launchpad.net/products/blueprint/+bug/56398 | 03:57 |
| Ubugtu | Malone bug 56398 in blueprint "roadmap should be useful" [Untriaged,Unconfirmed] | 03:57 |
| lifeless | assuming you are interested, I'll chat with steve. IMO it should be 1.0 for blueprint | 03:58 |
| lifeless | because its really a bad shock to look at that page at the moment | 03:58 |
| jamesh | lifeless: just replied to the bug with a short description of what it is doing now and what you are probably asking for it to do | 04:07 |
| lifeless | thank you! | 04:08 |
| jamesh | does what I wrote sound like what you're experiencing? | 04:22 |
| === MrX- [n=freebsd@unaffiliated/mrx] has joined #launchpad | ||
| lifeless | jamesh: I've replied | 05:15 |
| jamesh | lifeless: (a) I don't think specs get attached to series, do they? and (b) milestones can have dates attached, so can have order | 05:31 |
| lifeless | yes, specs get targets at series | 05:32 |
| lifeless | see https://launchpad.net/products/bzr/+specs for instance | 05:32 |
| jamesh | so they do. That must be new :) | 05:32 |
| jamesh | looks like SteveA will be able to carry his laptop on as hand luggage | 05:49 |
| === stub [n=stub@ppp-58.8.4.216.revip2.asianet.co.th] has joined #launchpad | ||
| lifeless | they are relaxing again ? | 06:00 |
| jamesh | one piece of hand luggage measuring 45cm by 35cm by 16cm | 06:01 |
| jamesh | can put a laptop in, but need to remove it from the bag for screening | 06:01 |
| jamesh | still can't take a bottle of water on | 06:01 |
| jamesh | unless it is prescription water :) | 06:02 |
| lifeless | is 45/35/16 the old size? | 06:07 |
| lifeless | or have they resized it ? | 06:07 |
| === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad | ||
| jamesh | I think that's a fair bit smaller than before | 06:16 |
| jamesh | 16cm is not very thick for luggage | 06:16 |
| lifeless | meh, I'll need to get new travel gear then | 06:32 |
| lifeless | sucks | 06:32 |
| === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad | ||
| === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad | ||
| === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad | ||
| === Fujitsu [n=Fujitsu@c58-107-57-8.eburwd7.vic.optusnet.com.au] has joined #launchpad | ||
| === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad | ||
| === mholthaus [n=mholthau@113-118.1-85.cust.bluewin.ch] has joined #launchpad | ||
| sabdfl | lifeless: at the rate you're going you'll be able to check yourself as cargo baggage soon ;-) | 08:44 |
| sabdfl | jamesh: thanks for taking on the spec-roadmap, the idea is just to show "what you have to do to get the most important, approved specs nailed first" | 08:45 |
| lifeless | sabdfl: lol | 08:45 |
| sabdfl | showing their dependencies ahead of them | 08:45 |
| === rpedro_ [n=rpedro@87-196-74-185.net.novis.pt] has joined #launchpad | ||
| === Spads [n=crack@host-87-74-18-227.bulldogdsl.com] has joined #launchpad | ||
| === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad | ||
| === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad | ||
| === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad | ||
| === danilos [n=danilo@82.117.204.123] has joined #launchpad | ||
| SteveA | morning | 09:41 |
| jamesh | SteveA: sounds like you can carry your laptop on the plane now | 09:42 |
| jamesh | but no cosmetics | 09:43 |
| SteveA | hmm, got a URL for that? | 09:54 |
| === malcc [n=malcolm@host86-134-233-12.range86-134.btcentralplus.com] has joined #launchpad | ||
| === mpt [n=mpt@217.205.109.249] has joined #launchpad | ||
| jamesh | SteveA: www.baa.com | 10:08 |
| SteveA | thanks james | 10:59 |
| SteveA | jamesh: I want to do a bzr log, but for one particular file, and see only revisions where that file was updated | 11:03 |
| SteveA | how can I do that? | 11:03 |
| jamesh | SteveA: "bzr log filename" should do it, but it seems pretty slow | 11:04 |
| SteveA | it is giving me lots of revisions when that file was not updated | 11:04 |
| jamesh | I think it shows the log message for each mainline revision where it was changed (which includes all the log messages for merges) | 11:05 |
| jamesh | iirc they were looking at improving it for 0.9 | 11:05 |
| === Spads [n=crack@82.211.81.249] has joined #launchpad | ||
| === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad | ||
| === doko_ [n=doko@dslb-088-073-110-181.pools.arcor-ip.net] has joined #launchpad | ||
| spiv | SteveA: if you pipe the log output through 'grep -v "^ "' you'll filter out all the merged revisions. | 11:09 |
| jamesh | spiv: --short also trims the merges | 11:09 |
| SteveA | spiv thanks | 11:09 |
| SteveA | I have the revisions I'm after now | 11:09 |
| spiv | jamesh: ah, that's probably nicer :) | 11:09 |
| jamesh | but that doesn't give you the log messages for the revisions that changed the file | 11:10 |
| jamesh | it gives you the log messages of the merges | 11:10 |
| === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad | ||
| === mpt_ [n=mpt@217.205.109.249] has joined #launchpad | ||
| === dsas [n=dean@host86-143-88-20.range86-143.btcentralplus.com] has joined #launchpad | ||
| sivang | re | 11:34 |
| sivang | sabdfl: pong | 11:34 |
| sivang | spiv: pong | 11:35 |
| stub | Znarl: asuka is borked. I can't ssh in. I would suspect carlos chewing up the resources, but he isn't online, so I think it needs a power cycle unless someone happens to be in the data centre | 11:36 |
| spiv | sivang: I don't think I pinged? | 11:37 |
| sivang | spiv: ah right | 11:38 |
| sivang | 06:00 #launchpad: < spiv> sivang reported the problem. | 11:38 |
| sivang | spiv: sorry | 11:38 |
| spiv | sivang: ah :) | 11:45 |
| spiv | Hmm, that merge didn't happen. | 11:45 |
| danilos | stub: ping | 11:48 |
| stub | danilos: pong | 11:49 |
| danilos | stub: do you perhaps have the last queries carlos executed for xaraxl translation removal? | 11:49 |
| danilos | stub: or he never sent them to you (and run them only on staging so far) | 11:49 |
| stub | I haven't seen anything about xaraxl | 11:50 |
| === dsas_ [n=dean@host86-143-88-18.range86-143.btcentralplus.com] has joined #launchpad | ||
| === steph [i=steph@sgserv.net] has joined #launchpad | ||
| danilos | stub: ok, thanks | 12:02 |
| SteveA | stub: hi | 12:10 |
| SteveA | stub: would you look at bug 56397 please? I think it is a cookie naming issue or something like that. | 12:10 |
| Ubugtu | Malone bug 56397 in launchpad "App subdomains require separate login" [Untriaged,Unconfirmed] https://launchpad.net/bugs/56397 | 12:10 |
| === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad | ||
| SteveA | stub: assigned to you. | 12:32 |
| SteveA | bug 56397 | 12:33 |
| Ubugtu | Malone bug 56397 in launchpad "App subdomains require separate login" [High,Unconfirmed] https://launchpad.net/bugs/56397 | 12:33 |
| === mpt__ [n=mpt@217.205.109.249] has joined #launchpad | ||
| sivang | laters | 12:46 |
| === sivang away | ||
| jamesh | morning ddaa | 12:48 |
| stub | SteveA: Did you take down staging? | 01:03 |
| === erdalronahi__ [n=erdal@p50874922.dip.t-dialin.net] has joined #launchpad | ||
| SteveA | stub: no | 01:21 |
| === Fujitsu [n=Fujitsu@c58-107-63-43.eburwd7.vic.optusnet.com.au] has joined #launchpad | ||
| === niemeyer [n=niemeyer@200.138.32.203] has joined #launchpad | ||
| === erdalronahi_ [n=erdal@p50874CB9.dip.t-dialin.net] has joined #launchpad | ||
| === mholthaus_ [n=mholthau@113-118.1-85.cust.bluewin.ch] has joined #launchpad | ||
| sabdfl | sivang: please update your branch and fix the trivial issue I mailed about, and i'll land it | 01:51 |
| jamesh | sabdfl: for the BranchIndirection spec (lp:... URLs for bzr), are you attached to lp://$product, or would you be happy with lp:/$product or lp:///$product? | 01:53 |
| sabdfl | jamesh: whats the semantic difference in url-speak? | 01:54 |
| jamesh | the latter two leave the door open for talking to non-default launchpad instances (e.g. staging) | 01:54 |
| sabdfl | and what's the difference between the latter two? | 01:54 |
| jamesh | sabdfl: if you have a URL like "scheme://foo/bar", the "//foo" bit is the authority component which generally refers to a host | 01:55 |
| jamesh | "lp:/$product" is a URL without an authority component, and "lp:///$product" is a URL with a blank authority -- I was thinking it would be good to accept either of them and treat them as the default LP instance | 01:56 |
| sabdfl | are there cases where people have agreed to treat scheme:///bar and scheme:/bar differently? | 01:56 |
| jamesh | not to my knowledge (there are only a few schemes using blank authority sections like file:///) | 01:57 |
| sabdfl | who has a landing due today? i have a one-line .pt fix that i'd like to get it | 01:57 |
| sabdfl | ok, +1 on your recommendation, and thanks | 01:58 |
| jamesh | while lp:///$product is one extra character to type, if we accept lp:/$product as a synonym it can be one less character to type :) | 01:59 |
| === Znarl [n=znarl@dark.roundabout.org] has joined #launchpad | ||
| sabdfl | stub: ping | 02:24 |
| stub | sabdfl: pong | 02:24 |
| sabdfl | stub: did you take a look at that idea of keeping a spare test_db handy at all times? | 02:24 |
| sabdfl | to reduce test runner time? | 02:24 |
| stub | It seemed a valid idea. Only trying it will let us know how much of a saving it would be. | 02:25 |
| stub | It will increase complexity in parts of the code (need a daemon or thread that creates and drops the dbs), but will simplify some of the existing code that needs to deal with race conditions in creating and dropping databases. | 02:27 |
| stub | (Hmm... although the daemon will likely need to deal with this too...) | 02:28 |
| === lfittl [n=lfittl@85-125-147-132.dynamic.xdsl-line.inode.at] has joined #launchpad | ||
| === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #launchpad | ||
| stub | SteveA: We will likely have trouble testing cookies with our existing development domain setup | 03:07 |
| stub | btw. If you follow the documented procedure for setting up /etc/hosts, Gnome will blow it away when you reconfigure your network through the configuration applet. | 03:08 |
| stub | Hmm... actually should be fine | 03:09 |
| stub | Anyone know the difference between request.getURL and request.getApplicationURL ? | 03:13 |
| SteveA | stub: yes | 03:55 |
| SteveA | stub: the application URL is the root, taking virtual hosting into account | 03:55 |
| stub | ta | 03:55 |
| SteveA | there are args you can apply to count up URL segments and include them. or is it down? whatever. not all that useful. | 03:55 |
| SteveA | getURL gets you the currnetly published URL. gets weird if you ask for it during traversal, as in, during the process of publication | 03:56 |
| SteveA | basically, the zope3 model of a request is rather too bound to "traversal" in a zope2-ish-way | 03:56 |
| SteveA | well, not really a zope2-ish-way | 03:56 |
| SteveA | more of a zope3-ish-way | 03:56 |
| === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad | ||
| === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| salgado | stub, ping? | 04:19 |
| === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad | ||
| === lbm [n=lbm@cpe.atm2-0-75146.0x535a2f1e.vgnxx2.customer.tele.dk] has joined #launchpad | ||
| === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad | ||
| === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad | ||
| bradb | BjornT: ping | 06:13 |
| === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad | ||
| sabdfl | anybody have a landing due shortly and willing to slipstream in a 1-line template fix? | 06:52 |
| sivang | sabdfl: I'm sending the patch shortly | 06:53 |
| sivang | sabdfl: send it to your email ? | 06:53 |
| sivang | sabdfl: I have the patch ready, after applying kiko's and your comments. Sending it to you now via email. | 07:15 |
| sivang | sabdfl: sent, kiko CC'd | 07:19 |
| sivang | be back alters. | 07:22 |
| sivang | argh, that is - laters. | 07:22 |
| === MaSa69 [n=MaSa69@dsl-jklbrasgw1-fe1cfb00-100.dhcp.inet.fi] has joined #launchpad | ||
| ddaa | Call for bikeshedding | 07:35 |
| ddaa | I'm modifying branch/+edit to allow changing the product and name of a branch | 07:35 |
| ddaa | Now, when changing those attributes, we can have an unique-name constraint violation if there is already a branch existing with that owner, product and name. | 07:36 |
| ddaa | So, when the user just changed the name, it's easy, the error should be displayed on the name field. | 07:36 |
| ddaa | But when the user changed the product, that probably means the user _really_ means that branch should be in the product. | 07:36 |
| ddaa | So the right way to get that done is to change the name... | 07:37 |
| ddaa | But... displaying an error for the name field, which was not modified would probably be confusing... | 07:37 |
| ddaa | Same problem if the user changed the product _and_ the name. | 07:37 |
| ddaa | Does anybody have an idea to make that non-confusing? | 07:37 |
| salgado | ddaa, maybe displaying a custom "The project you've chosen already has a branch with this name, you'll have to either rename this branch or the existing one" (or something to that intent) at the top of the page? | 07:39 |
| salgado | s/project/product | 07:39 |
| ddaa | Alternatively, we could show the same error on both the product and name fields, saying "There is already a branch registered by $owner in product $product with name $name. We suggest you change the name of this branch to avoid the conflict." | 07:40 |
| ddaa | salgado: two remarks: the owner of the branch is as important as the product, and in the general case the user does not own the branch with the conflicting name. | 07:40 |
| ddaa | And so cannot change its name. | 07:40 |
| salgado | I think that gives the impression that the user has to change both fields, when in fact changing only one would be enough | 07:40 |
| ddaa | Right. | 07:41 |
| ddaa | That's my concern, but showing an error on name when the user just modified product would be confusing IMO. | 07:41 |
| === erdalronahi [n=erdal@p50874CB9.dip.t-dialin.net] has joined #launchpad | ||
| salgado | agreed | 07:41 |
| salgado | that's why I suggested a message on the top of the page | 07:42 |
| salgado | (using top_of_page_errors of GFV/LFV) | 07:42 |
| ddaa | I see. But don't you think we should also provide a marker on the field to change? | 07:43 |
| ddaa | It's going to be a pretty large form, so some assistance would be welcome. | 07:43 |
| salgado | yes, that would be like the ideal solution, but if this is not a hand-crafted form, this is not going to be trivial, as I don't think we have the necessary infrastructure | 07:44 |
| salgado | (maybe I'm wrong and there's something new with zope3.2, but I can't tell for sure) | 07:44 |
| ddaa | jamesh: can any of your new magic help me there? | 07:45 |
| ddaa | Mh... +addbranch does not appear to handle name conflicts anyway... | 07:52 |
| === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad | ||
| === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has left #launchpad [] | ||
| === rpedro [n=rpedro@87-196-74-185.net.novis.pt] has left #launchpad ["Ex-Chat"] | ||
| === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad | ||
| === danilos [n=danilo@82.117.204.123] has joined #launchpad | ||
| === jinty [n=jinty@121.Red-83-56-157.dynamicIP.rima-tde.net] has joined #launchpad | ||
| === Spads [n=crack@host-87-74-18-227.bulldogdsl.com] has joined #launchpad | ||
| kiko | SteveA, BjornT: ping? | 09:12 |
| kiko | ValueError: Unknown SQL builtin type: <type 'zope.security._proxy._Proxy'> for <Person at 0x31c18450> | 09:12 |
| kiko | SteveA, BjornT: this error occurs when we try to do a selectBy(person=self) when the object we have is actually a security proxy. | 09:12 |
| kiko | SteveA, BjornT: is it possible to work around this? Can I simply allow __sqlrepr__ in some base interface? | 09:13 |
| kiko | SteveA, BjornT: or is there somewhere else where I can allow __sqlrepr__ to be called on all our objects? | 09:14 |
| bradb | kiko: personID=self.id? | 09:14 |
| kiko | bradb, that is the bug I am trying to work around. | 09:14 |
| kiko | err fix. | 09:14 |
| kiko | using personID=self.id is arguably a bug | 09:14 |
| kiko | we should be able to do person=self | 09:14 |
| kiko | and in most cases it works | 09:14 |
| kiko | however, in code which uses a proxy object as its argument.. | 09:15 |
| bradb | we should, i agree. i thought you were asking if you could work around person=self | 09:15 |
| kiko | well, I don't want to work around that error -- I want to fix it (that was the purpose of my current branch :) | 09:15 |
| BjornT | kiko: what's the traceback? | 09:16 |
| kiko | BjornT, one moment. | 09:16 |
| kiko | https://sodium.ubuntu.com/~andrew/paste/file4mJIz8.html | 09:16 |
| BjornT | kiko: i'd guess, that in _SO_columnClause, obj.id should be replaced with getID(obj) | 09:19 |
| BjornT | kiko: we override getID to make it aware of security proxies | 09:19 |
| kiko | BjornT, a bug in SQLObject? aha. | 09:19 |
| BjornT | kiko: actually, the whole if-else clause could probably be replaced with getID(obj) | 09:19 |
| BjornT | kiko: i leave it to you to decide wheter it's a bug in SQLObject or not. i'm trying to stay away from the SQLObject code as much as possible :), so i'm not 100% sure what's the correct thing to do. | 09:23 |
| === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad | ||
| === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad | ||
| === bradb thinks it is an sqlobject bug. sqlobject should support duck typing. | ||
| === jamesh [n=james@203-59-20-109.dyn.iinet.net.au] has joined #launchpad | ||
| === lfittl [n=lfittl@85-125-147-132.dynamic.xdsl-line.inode.at] has joined #launchpad | ||
| ddaa | bradb: I think Launchpad demonstrates that sqlobject has quite a thorough support for duct taping. | 09:46 |
| bradb | sqlobject is some craaazy glue | 09:46 |
| === ddaa is concerned that his import statements are soon going to exceed 79 chars | ||
| ddaa | from canonical.launchpad.scripts.importd.tests.sourcetransport_helpers import ( | 10:04 |
| ddaa | ImportdSourceTarballTestCase, ImportdSourceTransportTestCase) | 10:04 |
| ddaa | that's sick | 10:04 |
| ddaa | somebody said that "flat is better than nested", maybe we should flatten the canonical namespace a bit... | 10:05 |
| kiko | BjornT, so I ended up doing something different, which does work. the issue is that I don't want to just cut sqlrepr() out of there completely. | 10:06 |
| kiko | (it may be a high-impact change) | 10:08 |
| === stub [n=stub@ppp-58.8.4.216.revip2.asianet.co.th] has joined #launchpad | ||
| kiko | stub! | 10:29 |
| kiko | good that you showed up | 10:29 |
| lucasvo | does LP have some sort of a source viewer? | 10:56 |
| lucasvo | for bzr branches | 10:57 |
| kiko | lucasvo, not yet. is there a source viewer for bzr at all? what does #bzr say? | 10:58 |
| lucasvo | crap, I am in a discussion about what to use as a dev-plattform lp and bzr or svn and trac | 10:59 |
| === mpt [n=mpt@george.kkhotels.co.uk] has joined #launchpad | ||
| lucasvo | can a bug be closed on lp by stating "fixes #18" in a commit message? | 11:03 |
| kiko | lucasvo, not yet, but it will be possible in the short term. | 11:04 |
| ddaa | not yet, but we do plan to do that soon | 11:04 |
| ddaa | I should be there three months from now | 11:04 |
| ddaa | s/I/it/ | 11:04 |
| ddaa | same for the branch viewer | 11:05 |
| lucasvo | in three months? | 11:05 |
| ddaa | yeah, same time frame | 11:05 |
| lucasvo | I guess that's kinda too late for a project starting now :( | 11:06 |
| lucasvo | ddaa: but linking a bugfix to a bzr ci is not possible now? | 11:06 |
| ddaa | there was some work done before on that, but it was overriden by work to make hosted branches and mirrors faster | 11:06 |
| ddaa | lucasvo: yes it's possible now | 11:06 |
| lucasvo | ddaa: how? | 11:06 |
| ddaa | from the bug page, click "Add Branch" | 11:07 |
| ddaa | the branch must already be hosted or mirrored on Launchpad | 11:07 |
| ddaa | what's missing is adding some smarts to e.g. create bug-branch links, or updating bug status by scanning commit messages and merges. | 11:08 |
| kiko | bradb, is the XMLRPC interface to +filebug actually deployed? | 11:09 |
| bradb | kiko: it should be, but I haven't tested it yet, because I didn't want to send my p/w over the network | 11:09 |
| kiko | bradb, even over https? | 11:10 |
| kiko | or is xmlrpc not over https? | 11:10 |
| ddaa | bradb: mh, eventually we should put an easy path to registering an external branch and explaining how to host one from the bug/+addbranch page. | 11:10 |
| ddaa | it's a bit mysterious at the moment | 11:10 |
| lucasvo | are there any plans that LP will have a wiki per project? | 11:11 |
| lucasvo | such as trac? | 11:11 |
| ddaa | lucasvo: not AFAIK, but there are plan to add a simple wiki langage to the specifications tracker. | 11:11 |
| lucasvo | ok | 11:11 |
| bradb | kiko: it's over https, but, aiui, the credentials seem to be passed in the URL, which i thought might be a security concern. maybe that doesn't matter? | 11:12 |
| sabdfl | it does | 11:12 |
| lucasvo | btw, on https://launchpad.net/products/harmony/+specs "mozilla specifications" is more or less a deadlink | 11:13 |
| kiko | bradb, the credentials are passed in the URL? really? | 11:13 |
| ddaa | mpt: copy that? ^^ | 11:13 |
| ddaa | mh.. crap mpt is likely not around at this time | 11:13 |
| mpt | hi ddaa | 11:14 |
| bradb | kiko: yes, and no, i think. /me verifies the xmlrpclib docs | 11:14 |
| ddaa | mpt: see last message from lucasvo | 11:14 |
| bradb | Both the HTTP and HTTPS transports support the URL syntax extension for HTTP Basic Authentication: http://user:pass@host:port/path. The user:pass portion will be base64-encoded as an HTTP `Authorization' header, and sent to the remote server as part of the connection process when invoking an XML-RPC method. You only need to use this if the remote server requires a Basic Authentication user and password. | 11:14 |
| mpt | lucasvo, good point, report a bug and assign it to sabdfl :-P | 11:15 |
| mpt | It's hard to show a good example until upstreams start using Blueprint, though | 11:15 |
| kiko | bradb, it seems to suggest that you use that syntax to /specify/ a user and password, but that an Authorization: header is what's shipped to the remote server. | 11:15 |
| bradb | yeah | 11:15 |
| mpt | bzr specs would be a good example | 11:15 |
| bradb | so, perhaps it's ok | 11:15 |
| === bradb tries it on production, in failure mode first | ||
| kiko | sabdfl, bradb, why would the URL be an issue, btw? it is also encrypted in HTTPS traffic. | 11:16 |
| sabdfl | mpt: woncha fix that with your long-approved-conflict-free-but-unlanded-bazaar UI cleanup? and that oneliner I gave you earlier? | 11:16 |
| mpt | okie dokie | 11:16 |
| lucasvo | mpt: I still don't really get what a spec is, maybe writing a doc would be better than linking to upstream | 11:17 |
| mpt | lucasvo, like a bug report on steroids | 11:17 |
| sabdfl | kiko: if it's passed in url arguments it would be logged, for a start | 11:17 |
| sabdfl | it it's in an auth header, that's different, but not what bradb said | 11:18 |
| sabdfl | mpt: thanks | 11:18 |
| kiko | sabdfl, logged by.. whom? | 11:18 |
| sabdfl | kiko: by us | 11:19 |
| sabdfl | remember we don't as a rule know anybody's password | 11:19 |
| sabdfl | it's not evern recoverable from the db, given the digesting we do | 11:19 |
| kiko | ah | 11:19 |
| sabdfl | however, if it were logged, it would be at risk of lying around | 11:20 |
| sabdfl | and being exposed | 11:20 |
| kiko | I don't think the password is ever passed over the URL, though | 11:20 |
| sabdfl | we should not be loggin in through xmlrpc | 11:20 |
| bradb | sabdfl: not in url args, just in the URL, as per the syntax taken from the xmlrpclib docs | 11:20 |
| sabdfl | it should be a key that can be exchanged | 11:20 |
| sabdfl | so that scripts etc can keep the key in the clear | 11:20 |
| sabdfl | without exposing a password | 11:20 |
| kiko | user-agents allow specifying the user/password that way | 11:20 |
| sabdfl | make sense? | 11:20 |
| sabdfl | bradb: as long as it turns into auth headers, that's no problem for now | 11:21 |
| sabdfl | but the proper xmlrpc interface needs keys | 11:21 |
| kiko | sabdfl, the server doesn't actually receive the URL the client is accessing though! | 11:21 |
| kiko | it receives the path and host portions | 11:21 |
| kiko | the path in the GET or POST line | 11:21 |
| kiko | and the host portion (post HTTP/1.0) in a header | 11:21 |
| kiko | ah | 11:22 |
| kiko | I see, you were confused by brad's suggestion of "URL arguments". | 11:22 |
| sabdfl | (22:12:37) bradb: kiko: it's over https, but, aiui, the credentials seem to be passed in the URL, which i thought might be a security concern. maybe that doesn't matter? | 11:22 |
| kiko | right | 11:22 |
| sabdfl | that's all i was commenting on | 11:22 |
| kiko | sorry :) | 11:22 |
| kiko | as for the token idea. | 11:22 |
| sabdfl | it would be perfeclty possible to write an xmlrpc interface this way if you did not know better | 11:23 |
| sabdfl | i have seen worse done | 11:23 |
| kiko | so the user would post an auth header and get back a token which he could then keep on using for a while? | 11:23 |
| sabdfl | kiko: no, the user goes to lp.net, goes to a page in their account, requests a key and is given one | 11:23 |
| sabdfl | it has a lifespan of n days | 11:23 |
| sabdfl | it can be revoked | 11:24 |
| kiko | ah. | 11:24 |
| bradb | bug 56523 | 11:24 |
| Ubugtu | Malone bug 56523 in malone "xmlrpc works" [Untriaged,Unconfirmed] https://launchpad.net/bugs/56523 | 11:24 |
| bradb | w00t | 11:24 |
| kiko | VF | 11:24 |
| sabdfl | we correlate the key to the account, and use that person | 11:24 |
| bradb | kiko: that was a test with a python script | 11:24 |
| sabdfl | if a project has a special need for a long-lived key, we can give them that | 11:24 |
| bradb | https://help.launchpad.net/MaloneXMLRPC | 11:24 |
| sabdfl | we can throttle on the basis of keys without hitting the db | 11:24 |
| sabdfl | if we need to raise the throttle for a key, we can do that too | 11:24 |
| sabdfl | all making sense? | 11:24 |
| kiko | sabdfl, by throttle do you mean "time-limit"? | 11:25 |
| sabdfl | rate-of-query-limit | 11:25 |
| sabdfl | typicla limit would be 1 query per second over any given minute | 11:26 |
| sabdfl | so, you can burst, but then have to wait, or you can just slowly trawl | 11:26 |
| kiko | sabdfl, and rate-limit where in the software stack? iptables? | 11:27 |
| === bradb just updated the malone xmlrpc doc for production | ||
| === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad | ||
| sabdfl | kiko: most anything that can do rate-limiting can do it on the basis of a header like that | 11:38 |
| kiko | sabdfl, oh. apache has a mod_throttle, right? | 11:39 |
| sabdfl | kiko: yes, and i'm sure pound has something similar, and there are very good appliances that can do it too | 11:39 |
| kiko | right. | 11:40 |
| sabdfl | xmlrpc is great but also a risk, we can invest in doing it properly | 11:40 |
| sabdfl | on the icon - doh | 11:40 |
| kiko | ok | 11:42 |
| lifeless | squid-3 can throttle on anything it can filter on :0 | 11:44 |
| lifeless | so yeah, lots of things as sabdfl | 11:44 |
| lifeless | says | 11:44 |
| kiko | salgado, have you seen bug 35099? | 11:45 |
| Ubugtu | Malone bug 35099 in launchpad "feedback about karma" [Wishlist,Confirmed] https://launchpad.net/bugs/35099 | 11:45 |
| salgado | kiko, no, first time I'm seeing it | 11:47 |
| kiko | yeah, me too | 11:47 |
| kiko | sabdfl, about karma in LP: http://alligevel.blogspot.com/2006/07/karma-in-launchpad.html | 11:47 |
| kiko | salgado, assign to you? | 11:48 |
| salgado | kiko, sure | 11:49 |
| kiko | salgado, also, see the blog above. | 11:50 |
| === salgado reads | ||
| kiko | BjornT, bradb, salgado: there's no new@support.launchpad.net, right? | 11:52 |
| bradb | no idea | 11:52 |
| salgado | AFAIK, the email interface of the support tracker can only be used to add new comments | 11:53 |
| kiko | salgado, thanks. | 11:53 |
| sabdfl | we should definitely let folks create a question via email | 11:55 |
| kiko | agreed, just checking. | 11:55 |
| kiko | salgado, is there a bug filed on that? | 11:55 |
| salgado | not sure, let me check | 11:56 |
| kiko | yes | 11:57 |
| kiko | there is | 11:57 |
| kiko | https://launchpad.net/products/launchpad-support-tracker/+bug/53292 | 11:57 |
| Ubugtu | Malone bug 53292 in launchpad-support-tracker "Email submit support ticket feature" [Untriaged,Unconfirmed] | 11:57 |
| salgado | this is not really that, it's something more complex | 11:58 |
| kiko | salgado, I think aaron is just confused, that would solve his problem | 11:58 |
| salgado | yeah, maybe | 11:59 |
| kiko | if he sets the mailing list to be his support contact | 11:59 |
| kiko | and we allow replies to the support requests | 11:59 |
| kiko | and email to new@support | 12:00 |
| kiko | then, well, it would work out. | 12:00 |
| sabdfl | that's a little heath robinson, but creative and yes it would work | 12:05 |
| sabdfl | we do need mailing list integration. would you put a penny in that jar, please, kiko? | 12:05 |
| kiko | sabdfl, heh, okay. I'm not sure what that has to do with aaron's problem though. he wants to use gmane and our ticket tracker together. and we do support that already! | 12:06 |
| sabdfl | has anybody tried to run LP with python-twisted 2.4.0 in edgy? spiv? | 12:07 |
| sabdfl | i just KNOW you must have made that work | 12:07 |
| kiko | I hope spiv's still in bed! | 12:07 |
| sabdfl | one eye open, thats how it's done | 12:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!