| === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has left #launchpad ["Bye"] | ||
| === jelmer [n=jelmer@dyn-160-39-59-216.dyn.columbia.edu] has joined #launchpad | ||
| Ubugtu | New bug: #62375 in launchpad "_dynarch_top.DynarchMenu has no properties" [Untriaged,Unconfirmed] http://launchpad.net/bugs/62375 | 01:01 |
|---|---|---|
| === dsas [n=dean@host-84-9-169-23.bulldogdsl.com] has joined #launchpad | ||
| === doko__ [n=doko@dslb-088-073-064-199.pools.arcor-ip.net] has joined #launchpad | ||
| === crimsun [n=crimsun@dargo.trilug.org] has joined #launchpad | ||
| === WaterSevenUb [n=WaterSev@c-65-96-188-198.hsd1.ma.comcast.net] has joined #launchpad | ||
| === dsas [n=dean@host-84-9-169-23.bulldogdsl.com] has joined #launchpad | ||
| === jml [n=jml@ppp106-103.lns1.hba1.internode.on.net] has joined #launchpad | ||
| kiko | mpt, if you like, I can do that removal for you.. | 02:22 |
| jamesh | so, I have a branch now where I'd be able to do "bzr branch https://launchpad/products/bzr" and it would do the right thing | 02:25 |
| jamesh | without putting too much stress on the app server | 02:25 |
| kiko | jamesh, that is so cool! | 02:26 |
| kiko | I have.. errr.. a branch which is half-broken which intends to refactor translations :-( | 02:26 |
| jamesh | it is possible that implementing the "lp:" URI scheme could be done in a similar fashion | 02:27 |
| jamesh | rather than relying on special redirection handling in bzr | 02:27 |
| kiko | well.. | 02:29 |
| kiko | yeah, ISWYM. lp: would still need handling in bzr of course | 02:29 |
| kiko | but it could be dead simple and launchpad would do the redirecting necessary | 02:30 |
| kiko | quite cool actually | 02:30 |
| jamesh | kiko: I know, but the lp: transport could just serve up branch branch references, which would work even with bzr-0.8 | 02:31 |
| jamesh | as a plugin | 02:31 |
| jamesh | the solution I worked out is to use a branch reference, similar to what you get from "bzr checkout --lightweight" | 02:32 |
| kiko | yeah, I saw your email. pretty ingenious if I may say so | 02:35 |
| kiko | anyway, time to hit the z-factory | 02:35 |
| === jml [n=jml@ppp200-172.lns1.hba1.internode.on.net] has joined #launchpad | ||
| === stub [n=stub@ppp-58.8.13.21.revip2.asianet.co.th] has joined #launchpad | ||
| === radix [n=radix@70.91.133.157] has left #launchpad ["Bye] | ||
| Ubugtu | New bug: #62387 in soyuz "Modify the HTML code in Soyuz paget to be friendly for pagetest-helpers" [Medium,Confirmed] http://launchpad.net/bugs/62387 | 03:20 |
| === merriam_ [n=merriam@84-12-154-102.dyn.gotadsl.co.uk] has joined #launchpad | ||
| ryanakca | IntegrityError | 03:28 |
| ryanakca | A server error occurred. | 03:28 |
| ryanakca | When accessing https://launchpad.net/distros/ubuntu/+source/kdeutils/+bug/58049/+upstreamtask in mozilla firefox | 03:29 |
| Ubugtu | Malone bug 58049 in kdeutils "Kgpg crashes when I sign/verify clipboard" [Untriaged,Confirmed] | 03:29 |
| jamesh | what data did you enter into the form? | 03:37 |
| === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad | ||
| ryanakca | jamesh: kdebase and http://bugs.kde.org/show_bug.cgi?id=129267 | 03:41 |
| Ubugtu | KDE bug 129267 in general "Kgpg editor crashes when decrypting" [Crash,New] | 03:41 |
| jamesh | did you get an OOPS number? | 03:42 |
| ryanakca | nope | 03:42 |
| ryanakca | just the two lines above... | 03:42 |
| mpt | ryanakca, did you enter the whole bugs.kde.org URL, or just the bug number? | 03:43 |
| ryanakca | whole URL | 03:43 |
| === ryanakca wonders if he's being ignorant | ||
| mpt | ryanakca, at the moment you need to enter just the bug number | 03:43 |
| jamesh | so you entered "kdebase" into the product field, clicked "link to a remote bug", chose "KDE bug tracker" from the list box and typed "129267 into the remote bug box? | 03:43 |
| mpt | We should accept the whole URL, but we don't yet | 03:43 |
| ryanakca | kk, fixed, thanks | 03:44 |
| jamesh | we should definitely have something better than "integrity error" if you enter a URL there ... | 03:44 |
| ryanakca | yes... :) | 03:45 |
| ryanakca | it's confusing... maybe a "We're sorry, but we do not accept URL's at the moment, please..." page | 03:45 |
| Ubugtu | New bug: #62393 in malone "Should be able to add a bug watch by entering the URL" [Untriaged,Unconfirmed] http://launchpad.net/bugs/62393 | 03:55 |
| === jml [n=jml@ppp200-172.lns1.hba1.internode.on.net] has joined #launchpad | ||
| ryanakca | yippeee | 04:03 |
| ryanakca | lol, thanks mpt *heads off to bed* | 04:04 |
| === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad | ||
| jamesh | lifeless: do you see any problems with the implementation of this branch? https://devpad.canonical.com/~jamesh/pending-reviews/jamesh/launchpad/bug-39015/full-diff | 05:01 |
| jamesh | lifeless: it makes Launchpad URLs that could represent a branch usable with bzr | 05:02 |
| lifeless | I shall read on the train home - is that ok ? | 05:10 |
| jamesh | sure. | 05:12 |
| jamesh | It seems to work well here. I am mainly wondering if it is the kind of thing Bazaar developers wouldn't want us doing | 05:12 |
| lifeless | oh I see | 05:15 |
| lifeless | yeah, please do an HTTP Redirect, not a simulated format. | 05:16 |
| jamesh | will that still result in bzr hitting the webapp for every request? | 05:17 |
| lifeless | no | 05:21 |
| lifeless | maybe today, but its on the TODO to fix redirect handling | 05:22 |
| jamesh | what do you think of using it as a temporary solution? Switching over to redirecting .../.bzr would involve changing browser/branchref.py | 05:24 |
| mpt | danilos, ping | 05:37 |
| mpt | danilos, unping | 05:45 |
| mpt | jamesh, ping | 05:45 |
| jamesh | mpt: pong | 05:45 |
| lifeless | jamesh: we're discussing it now in rl | 05:45 |
| jamesh | lifeless: thanks | 05:45 |
| mpt | jamesh, I've done a very foolish thing and tried once more to change something in some Python code | 05:46 |
| mpt | but I think whatever I'm doing wrong must be fairly simple | 05:46 |
| mpt | one moment, I'll pastebin the diff | 05:47 |
| mpt | jamesh, https://devpad.canonical.com/~andrew/paste/file4ae6ux.html | 05:48 |
| mpt | (this is to fix bug 56570 in the way requested by sabdfl) | 05:49 |
| Ubugtu | Malone bug 56570 in rosetta ""You are not an official translator" should be informational, not warning" [Medium,Confirmed] http://launchpad.net/bugs/56570 | 05:49 |
| mpt | I get "AssertionError: Can't index with type <type 'str'>. (Must be unicode.)" | 05:51 |
| jamesh | mpt: one small stylistic note: rather than doing "if CONDITION: return True else: return False", just do "return CONDITION" | 05:51 |
| mpt | heh, that's what I had first :-) | 05:51 |
| mpt | I made it more explicit in case the shorthand was the problem | 05:51 |
| jamesh | mpt: are you sure it shouldn't be "not: view/user_is_official_translator" ? | 05:52 |
| mpt | That, also, I had originally | 05:52 |
| mpt | That gives a TraveralError instead of an AssertionError | 05:52 |
| mpt | TraversalError, rather | 05:52 |
| mpt | It seems like it should be view/, I agree | 05:53 |
| jamesh | you've added a method in browser/pomsgset.py, but are using that method in pofile-translate.pt | 05:54 |
| jamesh | are you sure the view class you modified is the one being used by the page template? | 05:54 |
| jamesh | when you do "foo/bar" in a TAL expression, it will try looking up bar as foo.bar and foo['bar'] in Python code | 05:55 |
| jamesh | IPOFile implements __getitem__(), which is where the assertion error would be coming from | 05:56 |
| mpt | class="canonical.launchpad.browser.POFileTranslateView" | 05:56 |
| jamesh | pofile['user_is_official_translator'] | 05:56 |
| mpt | so this should be in pofile.py | 05:56 |
| jamesh | probably. | 05:57 |
| mpt | in class POFileTranslateView(), no less | 05:57 |
| jamesh | yep | 05:58 |
| mpt | Is there any rule for the order in which to put functions in a class? | 05:58 |
| mpt | /guideline | 05:58 |
| jamesh | no general rule. It is good to group related methods together though, and have __init__ at the top | 05:59 |
| spiv | mpt: consistent with existing ordering, which might be roughly grouped by logical function, or alphabetical. Or random :/ | 05:59 |
| mpt | Here the @properties seem to be grouped | 05:59 |
| jamesh | then follow the existing style | 06:00 |
| mpt | ok, now in POFileTranslateView(), but still a TraveralError | 06:00 |
| lifeless | jamesh: what url is recorded as the parent when you branch using this. | 06:01 |
| jamesh | lifeless: the bazaar.launchpad.net one | 06:01 |
| mpt | ahhhhh-haaaa | 06:07 |
| === poolie [n=mbp@ozlabs.org] has joined #launchpad | ||
| === bradb [n=bradb@modemcable077.58-130-66.mc.videotron.ca] has left #launchpad [] | ||
| mpt | lifeless, PQM claims that the time is 05:23 UTC, when it's actually 04:23 | 06:23 |
| jamesh | mpt: it is using daylight savings UTC | 06:24 |
| mpt | I thought UTC was immune to that sort of nonsense | 06:24 |
| jamesh | it is | 06:24 |
| jamesh | it is probably displaying local time and mislabeling it as UTC | 06:25 |
| mpt | ok, spiv, want to volunteer for a five-minute review? (perhaps I've pestered jamesh too much today) | 06:28 |
| stub | lifeless: https://devpad.canonical.com/~andrew/paste/filem2ViBA.html | 06:32 |
| lifeless | stub: huh | 06:34 |
| lifeless | stub: did you do an uncommit or something ? | 06:35 |
| === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad | ||
| stub | Nope | 06:35 |
| stub | Just what you see there | 06:35 |
| stub | Well... rsynced a copy of rocketfuel-built in there first to prime the tree | 06:35 |
| lifeless | hmm | 06:40 |
| lifeless | poolie: can you chat with stub about how to track the cause of this down ? | 06:40 |
| poolie | stub: can you give me some context? | 06:40 |
| poolie | oh, that paste link before? | 06:42 |
| stub | I need to rollout new launchpad code, using the trunk as of last Thursday as a basis. I managed to create the branch, but I cannot pull --overwrite it into a tree built from HEAD | 06:43 |
| stub | poolie: yes | 06:43 |
| stub | poolie: The process worked fine last rollout, about three weeks ago | 06:43 |
| stub | Maybe a bit more - I think devs were using bzr 0.9 at that point so it might be a 1.0 issue? | 06:44 |
| mpt | jamesh, do you have time for a 5-minute review? | 06:44 |
| poolie | stub: and what do you mean you rsync'd in there? | 06:46 |
| stub | We have a tree built containing a branch of launchpad HEAD, along with all the other necessary branches such as zope, sqlobject etc. | 06:47 |
| stub | I rsynced that in place | 06:48 |
| poolie | what does bzr st in that directory do? | 06:51 |
| poolie | can you do 'bzr log --show-ids |less' in the destination and tell me if that revision id is present? | 06:52 |
| stub | bzr st gives no output | 06:53 |
| stub | pqm@balleny:~/production/launchpad$ bzr log --show-ids | 06:54 |
| stub | bzr: ERROR: Branch KnitRepository(u'/home/pqm/production/launchpad/.bzr/') has no revision pqm@pqm.ubuntu.com-20060926041927-ad64e43333dd568a | 06:54 |
| stub | I'm going to rsync in a fresh copy of the tree | 06:54 |
| jamesh | mpt: okay | 06:54 |
| mpt | jamesh, https://devpad.canonical.com/~andrew/paste/filefkpSTE.html | 06:55 |
| stub | poolie, lifeless: Don't worry. A fresh sync of the tree has fixed things. I must have synced it when the tree was being rebuilt, or we temporarily had a screwed tree. | 06:55 |
| poolie | ok | 06:56 |
| jamesh | stub: any reason not to use sftp when going between data centre machines? | 06:57 |
| stub | jamesh: Because I need a built tree, not a branch | 06:57 |
| jamesh | okay | 06:57 |
| stub | config_manager might work on balleny now, but rsync is generally fine. | 06:58 |
| stub | jamesh: Do you recall where the OOPS id matching code lives that is used to hyperlink them? | 07:01 |
| jamesh | stub: lib/canonical/launchpad/webapp/tales.py | 07:01 |
| jamesh | in the fmt:text-to-html code | 07:02 |
| stub | Got it | 07:04 |
| jamesh | mpt: the branch looks fine. Do you think there is any need to highlight the message at all (e.g. an info icon?) | 07:05 |
| stub | Bah. There is no word break escape in posix regular expressions :-( | 07:07 |
| stub | Oh... there it is. \m | 07:08 |
| jamesh | \b matches the boundary | 07:09 |
| jamesh | between alphanumeric and non-alphanumeric | 07:09 |
| mpt | jamesh, not really, I'm trying to confine use of the info icon to cases where something interesting has just happened | 07:10 |
| jamesh | mpt: fair enough. The branch looks fine to merge. | 07:11 |
| mpt | thanks jamesh | 07:11 |
| === stub [n=stub@ppp-58.8.4.98.revip2.asianet.co.th] has joined #launchpad | ||
| === jelmer [n=jelmer@dyn-160-39-59-216.dyn.columbia.edu] has joined #launchpad | ||
| === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad | ||
| === elmo_ [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #launchpad | ||
| === mpt [n=mpt@203-167-187-182.dsl.clear.net.nz] has joined #launchpad | ||
| mpt | lifeless, PQM has fallen over | 07:52 |
| === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad | ||
| stub | jamesh: I get a test failure with your cherry pick request. How urgent is that fix? | 08:00 |
| SteveA | morning | 08:01 |
| stub | yo | 08:01 |
| jamesh | stub: we've been having some performance problems with the branch puller, so wanted to get some idea of what branches the time was being spent on | 08:01 |
| stub | Failure in test_bzrsync | 08:01 |
| jamesh | stub: currently it doesn't do any logging (other than sending status info back to the authserver) | 08:01 |
| jamesh | I didn't touch test_bzrsync in that revision ... | 08:02 |
| jamesh | ah. kiko found a bug in that test that showed up after some sqlobject changes he made | 08:02 |
| stub | https://devpad.canonical.com/~andrew/paste/file0N3olS.html | 08:03 |
| SteveA | and he didn't revert the changes? | 08:03 |
| stub | Hmm... | 08:03 |
| SteveA | does that mean we can't check in via pqm to RF/launchpad/devel now? | 08:03 |
| jamesh | SteveA: if stub is using head sqlobject with old launchpad, I guess he'd run into the problem. | 08:03 |
| SteveA | I see, so launchpad head + sqlobject head works | 08:03 |
| stub | I'll revert SQLObject a revision | 08:03 |
| jamesh | stub: I'll see if kiko's fix is self contained ... | 08:04 |
| jamesh | stub: looks like r4091 has the fix for that test failure | 08:05 |
| jamesh | and nothing else | 08:05 |
| === Kylekf [n=Kyle@61.6.65.122] has joined #launchpad | ||
| === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad | ||
| === Kylekf [n=Kyle@61.6.65.122] has joined #launchpad | ||
| === MikaT [n=mtapoja@212.50.150.21] has left #launchpad [] | ||
| === Burgundavia_ [n=corey@ubuntu/member/burgundavia] has joined #launchpad | ||
| === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad | ||
| === siretart [i=siretart@tauware.de] has joined #launchpad | ||
| stub | pqm back on line - production branch tests all passing | 08:41 |
| SteveA | yay | 08:45 |
| stub | Launchpad will be going down in 15 minutes for a regular code update. Estimated down time is one hour. This is longer than usual to perform some extra database maintenance. | 08:54 |
| === lfittl [n=lfittl@194.50.115.210] has joined #launchpad | ||
| === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad | ||
| === jinty [n=jinty@195.Red-83-58-178.dynamicIP.rima-tde.net] has joined #launchpad | ||
| === MaSa69 [n=MaSa69@dsl-jklbrasgw1-fe1cfb00-100.dhcp.inet.fi] has joined #launchpad | ||
| === carlos [n=carlos@12.Red-83-39-60.dynamicIP.rima-tde.net] has joined #launchpad | ||
| carlos | morning | 09:26 |
| SteveA | hi carlos | 09:26 |
| stub | jamesh: product-release-finder.py should be enabled in production? | 09:35 |
| jamesh | stub: not yet | 09:35 |
| stub | k | 09:36 |
| jamesh | there are a few more small things to fix | 09:36 |
| === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad | ||
| === siretart_ [i=siretart@tauware.de] has joined #launchpad | ||
| === xenru [n=Miranda@85.192.12.132] has joined #launchpad | ||
| === yves [n=yves@lns-bzn-31-82-252-232-211.adsl.proxad.net] has joined #launchpad | ||
| === yves is now known as yvesd | ||
| === _thumper_ [n=tim@host86-141-71-114.range86-141.btcentralplus.com] has joined #launchpad | ||
| === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad | ||
| === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad | ||
| yvesd | hello, when will launchpad be back again ? | 09:53 |
| danilos | yvesd: 8:55 <stub> Launchpad will be going down in 15 minutes for a regular code update. Estimated down time is one hour. This is longer than usual to perform some extra database maintenance. | 09:56 |
| stub | Couple more mins | 09:57 |
| yvesd | thank you danilos :) | 09:57 |
| danilos | np ;) | 09:57 |
| stub | Launchpad is back up | 10:01 |
| yvesd | cool, works :) | 10:03 |
| stub | soyuz is still down - I'll wait a tick until malcc shows up and he can confirm it should still be running with the old code. | 10:04 |
| === frodon_ido [n=patrick@ip-213-49-147-165.dsl.scarlet.be] has joined #launchpad | ||
| === realist [n=realist@CPE-144-133-64-178.vic.bigpond.net.au] has joined #launchpad | ||
| === siretart_ [i=siretart@tauware.de] has joined #launchpad | ||
| === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad | ||
| === MikaT [n=mtapoja@212.50.150.21] has joined #launchpad | ||
| === JanC [n=janc@lugwv/member/JanC] has joined #launchpad | ||
| === siretart_ [i=siretart@tauware.de] has joined #launchpad | ||
| === siretart_ is now known as siretart | ||
| SteveA | jamesh: I just deleted the email with your review of kiko's recent selectAlso changes | 10:49 |
| SteveA | but I have a comment about it | 10:49 |
| jamesh | oh? | 10:49 |
| SteveA | how about a standard helper function called uniq_list | 10:49 |
| SteveA | that encapsulates getting a list of stuff in the same order as an input sequence | 10:50 |
| SteveA | but omitting duplicates | 10:50 |
| SteveA | it's the kind of thing I'd hope to find in python's itertools, actually | 10:50 |
| SteveA | but there is no such thing | 10:50 |
| SteveA | it could as easily be an iterator | 10:50 |
| jamesh | sounds useful | 10:50 |
| SteveA | but I don't think we need it as an iterator | 10:50 |
| jamesh | it probably isn't in itertools because it effectively requires you to build up a set of previously seen data | 10:51 |
| _thumper_ | could be a simple generator with stored set state | 10:51 |
| SteveA | yes | 10:51 |
| SteveA | you'd want ideally to be able to supply a function | 10:51 |
| SteveA | that gets a suitable memo of an object | 10:51 |
| jamesh | I think all the existing itertools helpers' memory usage isn't dependent on the number of items in the iterator | 10:51 |
| SteveA | for our sqlobjects, it would be its id, or in somecases (class, id) | 10:51 |
| === xenru [n=Miranda@85.192.12.132] has joined #launchpad | ||
| === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad | ||
| jamesh | effectively the same as the "key" argument to sort/sorted | 10:52 |
| SteveA | jamesh: itertools.cycle depends on the number of items in the iterator | 10:53 |
| SteveA | as it needs to store them | 10:53 |
| SteveA | yes, same as the key | 10:53 |
| jamesh | so it does. | 10:53 |
| SteveA | _thumper_: yes, could be a simple generator, as in http://docs.python.org/lib/itertools-functions.html examples | 10:54 |
| _thumper_ | it does depend on your complexity and storage constraints though | 10:55 |
| _thumper_ | I really should be working :( | 10:55 |
| === xenru|clone [n=Miranda@85.192.12.132] has joined #launchpad | ||
| === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has joined #launchpad | ||
| sivang | morning | 11:06 |
| matthewrevell | morning! | 11:07 |
| sivang | matthewrevell: hi | 11:08 |
| === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad | ||
| SteveA | spiv: nice https://devpad.canonical.com/~andrew/paste/fileywRJCw.html | 11:11 |
| SteveA | I had no idea it was so much the same as svn | 11:11 |
| === malcc [n=malcolm@host86-138-251-144.range86-138.btcentralplus.com] has joined #launchpad | ||
| === siretart [i=siretart@tauware.de] has joined #launchpad | ||
| === Spads [n=spacehob@82.211.81.249] has joined #launchpad | ||
| === zwnj|away is now known as zwnj | ||
| === KeithWeissha [i=KeithWei@pool-70-111-232-241.nwrk.east.verizon.net] has joined #launchpad | ||
| KeithWeissha | how do i close my launchpad account | 12:15 |
| === KeithWeissha [i=KeithWei@pool-70-111-232-241.nwrk.east.verizon.net] has left #launchpad [] | ||
| stub | malcc: Should I update dreschers code, or restart soyuz using the existing code? | 12:23 |
| === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad | ||
| Ubugtu | New bug: #62423 in launchpad "The 'appoint driver' form is broken for projects" [Undecided,Unconfirmed] http://launchpad.net/bugs/62423 | 12:31 |
| jamesh | BjornT: ping? | 12:39 |
| BjornT | jamesh: pong | 12:39 |
| jamesh | BjornT: I was looking at moving the $productseries/+source form over to the form machinary | 12:40 |
| jamesh | BjornT: one of the things that the form does is enable or disable some input boxes based on the value of a radio button | 12:40 |
| ddaa | jamesh: that cleanup would be great | 12:41 |
| jamesh | formlib doesn't seem to like it when no data is passed back for a form value (which happens when the widget has been disabled) | 12:41 |
| ddaa | this page scares me | 12:41 |
| jamesh | do you know of a way to handle that? | 12:41 |
| ddaa | jamesh: did the mail about "Landing bzr-0.11 on rocketfuel" catch your attention? | 12:46 |
| Ubugtu | New bug: #62425 in launchpad-support-tracker "Users should be able to change source package" [Undecided,Unconfirmed] http://launchpad.net/bugs/62425 | 12:46 |
| jamesh | ddaa: yeah | 12:46 |
| BjornT | jamesh: i'm not sure why that check is in getWidgetsData at all. i see three different option; 1) talk to upstream about removing the check 2) write our own getWidgetsData 3) filter out all widgets that don't have any input before calling getWidgetsData | 12:46 |
| BjornT | the third is probaby simplest for now | 12:47 |
| fabbione | stub: ping? | 12:47 |
| === dsas [n=dean@host-84-9-170-139.bulldogdsl.com] has joined #launchpad | ||
| === siretart [i=siretart@tauware.de] has joined #launchpad | ||
| fabbione | did launchpad eat all the uploads that have been done during the downtime? | 12:49 |
| BjornT | jamesh: when filtering out widgets that don't have input, you'd have to add errors for those widgets that are required, though. | 12:51 |
| jamesh | BjornT: good point. | 12:51 |
| === BjornT -> lunch | ||
| SteveA | fabbione: that would be a question for malcc | 01:02 |
| SteveA | or cprov-ZzZ | 01:02 |
| SteveA | ddaa: we should talk over those bugs you mentioned in the meeting yesterday | 01:03 |
| === Kamion [n=cjwatson@83-216-156-196.colinw664.adsl.metronet.co.uk] has joined #launchpad | ||
| Kamion | Did the LP update and database maintenance from today go normally? | 01:05 |
| stub | fabbione: pong | 01:05 |
| Kamion | Because drescher is acting very weirdly, and it's not clear that the deployment was completed | 01:05 |
| fabbione | stub: what Kamion says | 01:05 |
| fabbione | SteveA: ok thanks.. Kamion found everything :) | 01:06 |
| ddaa | SteveA: sure | 01:06 |
| stub | Kamion: drescher has not yet been updated - I'm waiting on malcc to determine if the code needs to be updated, and if so if the main branch is good. | 01:06 |
| Kamion | stub: well, package removals aren't working due to a permission error on BinaryPackagePublishing | 01:06 |
| Kamion | so either it needs to be updated, or it's just broken | 01:06 |
| stub | Could be either | 01:06 |
| ddaa | SteveA: bug 50569 has been taken by jamesh, as it's the one that's blocking PRF | 01:07 |
| Ubugtu | Malone bug 50569 in launchpad-bazaar "the product series page does not allow entering source or ftp details for projects without SVN or VCS" [High,Confirmed] http://launchpad.net/bugs/50569 | 01:07 |
| SteveA | okay | 01:07 |
| ddaa | SteveA: bug 46240 is caused by the source-package input on the +source page not understanding that empty string means "ignore that" | 01:07 |
| Ubugtu | Malone bug 46240 in launchpad-bazaar "posting $series/+source yields a confusing warning" [High,Confirmed] http://launchpad.net/bugs/46240 | 01:07 |
| ddaa | should probably be fixed by just removing that input from this form, I see no reason for it being there | 01:08 |
| ddaa | there is already a separate form to associate a sourcepackage to a productseries | 01:08 |
| SteveA | right | 01:08 |
| SteveA | so it is old, from the original VCS imports days | 01:08 |
| ddaa | SteveA: bug 2649 is about the cvsbranch input, that's confusing most users, and which is redundant anyway since we do not support anything but MAIN | 01:09 |
| Ubugtu | Malone bug 2649 in launchpad-bazaar "CVS branch details should not be editable or displayed." [High,Confirmed] http://launchpad.net/bugs/2649 | 01:09 |
| SteveA | ok, I agree with that. we shouldn't encourage expectations we can't fulfil | 01:09 |
| SteveA | who will fix 46240? | 01:10 |
| ddaa | it's not even that, most users do not even understand what a cvs branch is | 01:10 |
| SteveA | who will fix 2649? | 01:10 |
| jamesh | ddaa: currently the +source form essentially gets locked once a vcs-import is started. Can you think of any reason why we'd want to lock releaseroot/releasefileglob in that case? | 01:10 |
| ddaa | jamesh: absolutely no reason | 01:10 |
| ddaa | jamesh: except that this page was virtually written by a million monkeys | 01:10 |
| jamesh | then I'll definitely move it over to the main edit form | 01:11 |
| ddaa | SteveA: those bugs are not assigned yet, taken in isolation they are not hard to fix. | 01:11 |
| SteveA | can they be fixed in isolation? | 01:11 |
| ddaa | sure, they are meaningful incremental improvements | 01:11 |
| SteveA | what would you think about doing one today, and one tomorrow? | 01:12 |
| SteveA | I can review for you immediately | 01:12 |
| ddaa | can do that | 01:12 |
| SteveA | ok | 01:12 |
| SteveA | next bug... bug 48813 | 01:12 |
| Ubugtu | Malone bug 48813 in launchpad-bazaar "Efficiently mirroring sftp hosted branches with minimal latency" [High,In progress] http://launchpad.net/bugs/48813 | 01:12 |
| ddaa | SteveA: this specific bug refers to a number of improvements to the supermirror | 01:13 |
| === SteveA reads | ||
| ddaa | things like: defining Branch.pull_now, sftp server and importd setting Branch.pull_now, branch scanner being able to receive messages for immediate mirroring, handling branches that are being created | 01:14 |
| SteveA | is this causing a problem right now? | 01:15 |
| ddaa | there are sporadic reports of sftp branches not being mirrored, or being mirrored too slow | 01:15 |
| ddaa | it's more of a placeholder to mean "we need to fix sftp mirroring" | 01:15 |
| SteveA | ok, later | 01:15 |
| SteveA | maybe we should do this at the same time as installing the smartserver? | 01:16 |
| SteveA | would that make sense? | 01:16 |
| ddaa | it's quite essential IMO, but not easy | 01:16 |
| ddaa | Mh... | 01:16 |
| SteveA | sure it is essential. but is it urgent? | 01:16 |
| ddaa | I think it is. | 01:16 |
| SteveA | tell me the steps required to fix it | 01:17 |
| === ddaa reads the bug to refresh memory | ||
| ddaa | mh, I think that bug was not well chosen to convey what I think is urgent | 01:19 |
| malcc | stub: Sorry. Yes, update drescher's code | 01:19 |
| SteveA | ddaa: ok. what do you think is urgent? | 01:20 |
| stub | malcc: ok | 01:20 |
| ddaa | SteveA: When people think "this sftp branch is not being mirrored", give them the ability to understand the problem. Also give us the ability to see which sftp branches have problems. | 01:21 |
| ddaa | The same applies to importd, but it's less important. | 01:21 |
| ddaa | One issue here is that some issues cause the branch puller to crash and burn. | 01:22 |
| ddaa | And not report the error. | 01:22 |
| ddaa | One way to fix it would be to spawn a subprocess and capture its input, so when it crashes and burn, we always have something to display. | 01:23 |
| SteveA | what do we do now? | 01:23 |
| ddaa | We should also display the last mirror attempt date, the last successful mirror date, the next scheduled mirror time. | 01:24 |
| SteveA | I'm confused by what you mean by "sftp branch being mirrored" | 01:24 |
| SteveA | I don't see how that could fail | 01:24 |
| ddaa | SteveA: I mean branch puller copying the data from the sftp area to the http-published aread. | 01:24 |
| SteveA | how could that fail? | 01:24 |
| ddaa | SteveA: bad branch data, internal service failures | 01:25 |
| Ubugtu | New bug: #62428 in soyuz "can't remove packages any more" [Undecided,Unconfirmed] http://launchpad.net/bugs/62428 | 01:25 |
| SteveA | so, if I have a branch, I can mangle my branch, sftp it up, and then get a problem at this stage | 01:25 |
| ddaa | SteveA: that's the least likely scenario, but it's valid | 01:25 |
| SteveA | what is more likely? | 01:26 |
| malcc | fabbione: A bunch of uploads this morning are waiting to be processed once the deployment is finished, they haven't been lost | 01:26 |
| ddaa | SteveA: bad branch data of some sort. But one issue is that sometimes we see that a branch is not being mirrored, and we have no idea why. | 01:26 |
| ddaa | bzrlib in some cases will produce data that it cannot pull. I had it once with importd. | 01:27 |
| SteveA | the point of my example was | 01:27 |
| SteveA | that I upload bad branch data | 01:27 |
| SteveA | not that I maliciously break the data | 01:27 |
| ddaa | SteveA: ha, okay. Then yes. That's an important case. | 01:27 |
| SteveA | so, when you said "that's the least likely scenario" then | 01:27 |
| stub | Kamion: Code has been updated, so things might work now | 01:28 |
| SteveA | did you mean "my breaking my data on purpose" is | 01:28 |
| ddaa | yes | 01:28 |
| SteveA | or did you mean "my uploading bad data" is? | 01:28 |
| ddaa | "breaking data on purpose and putting it manually on the sftp server" | 01:28 |
| SteveA | ok | 01:28 |
| SteveA | so, is there any circumstance where someone uploads bad data, and the mirroring fails, and we have an idea why? | 01:29 |
| ddaa | SteveA: nope | 01:29 |
| SteveA | ok, so when you said "But one issue is that sometimes we see that a branch is not being mirrored, and we have no idea why. | 01:29 |
| Kamion | stub: yes, it's fine now - thanks | 01:29 |
| SteveA | " | 01:29 |
| SteveA | you mean that actually whenever a branch is not being mirrored, we have no idea why | 01:30 |
| ddaa | SteveA: sometimes we have an error report | 01:30 |
| SteveA | does the mirroring process produce any kind of a log? | 01:30 |
| SteveA | why only sometime? | 01:30 |
| SteveA | that seems strange to me, to sometimes get an error report, and sometimes not | 01:30 |
| === jinty [n=jinty@39.Red-83-37-139.dynamicIP.rima-tde.net] has joined #launchpad | ||
| ddaa | because the "bzr pull" operation is done in-process in the branch-puller, and lifeless insisted that on any unknown error we just bail out | 01:31 |
| SteveA | just bail out? | 01:31 |
| ddaa | so when an unknown error happens, we do not put the error in the database | 01:31 |
| SteveA | or bail out, but log something first | 01:31 |
| SteveA | do errors normally end up in the database | 01:31 |
| SteveA | ? | 01:31 |
| ddaa | There are different logging here: the one that gets sent to launchpad-error-reports, and the one that gets put in the db for users to see. | 01:32 |
| SteveA | so, when you say "we have no idea why" you mean "we need to look through launchpad-error-reports to find out why" ? | 01:32 |
| ddaa | "just bail out" means "let the error bubble up, do not write anything to the db" | 01:32 |
| ddaa | SteveA: ideally, we would find the data here. But the last time j-a-meinel reported a branch was not being mirrored nothing was even in launchpad-error-reports. | 01:33 |
| ddaa | When I say "no idea why" I mean exactly that. | 01:33 |
| SteveA | ok | 01:33 |
| SteveA | so we have a number of problems here | 01:33 |
| SteveA | 1. sometimes we have a failure in the system, but no record of that failure | 01:34 |
| SteveA | we should fix that very soon | 01:34 |
| SteveA | otherwise, we have no way of measuring our progress or our service level | 01:34 |
| SteveA | 2. we have a system that takes user input (in the form of branch data), and can fail while dealing with that user input, without giving any indication to the user that their input was faulty | 01:35 |
| jamesh | ddaa: stub cherry picked the branch puller logging patch | 01:35 |
| SteveA | our systems should not do that. if we have user input, and we can't deal with that user input, then we need to tell the user about it | 01:35 |
| SteveA | because only the user can fix that | 01:35 |
| SteveA | now, this can sometimes be a fault in our system that causes the user data to fail to be handled | 01:36 |
| SteveA | but even then, it is a production cycle before we can fix it | 01:36 |
| === Kamion [n=cjwatson@83-216-156-196.colinw664.adsl.metronet.co.uk] has left #launchpad [] | ||
| SteveA | so, relative to the system in production, it is still the user that needs to deal with it | 01:36 |
| SteveA | maybe by filing a bug or support request | 01:36 |
| SteveA | ddaa: what do we have to do to fix these two problems? | 01:37 |
| ddaa | 1. no: I do not think we even have a good definition of the service level we aim at | 01:38 |
| === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad | ||
| SteveA | ddaa: I'm not talking about aiming at a particular service level | 01:38 |
| SteveA | I'm saying that with the system as it is, we can't even say "we achieve XXX level of service" | 01:39 |
| SteveA | because we're losing error reports | 01:39 |
| SteveA | so we just can't know | 01:39 |
| SteveA | that's what I want fixed | 01:39 |
| ddaa | I think I understand, but I'm not sure how to formulate that. | 01:40 |
| SteveA | think of the OOPS system in launchpad | 01:40 |
| SteveA | if there's a problem loading a page in the webapp, there is an OOPS report generated on the filesystem | 01:40 |
| SteveA | and we have a reliable system for getting these onto a central location | 01:41 |
| SteveA | and being analyzed daily | 01:41 |
| SteveA | there are very few classes of error that will cause no OOPS to be generated | 01:41 |
| ddaa | ddaa.nicotin ++ | 01:41 |
| SteveA | and these classes of error occur very rarely | 01:41 |
| SteveA | how it works is the "render a page in response to a request" code has a big try: except: around it | 01:42 |
| SteveA | and if there is an exception, an OOPS report is generated | 01:42 |
| SteveA | now, can we do something equivalent, maybe not so fancy, for the imports/ mirroring? | 01:42 |
| SteveA | thinnk about it over your cigarette break | 01:42 |
| ddaa | I think we can do it by spawning a subprocess for each branch | 01:43 |
| SteveA | ping me after your cigarette break | 01:43 |
| === Spads [n=spacehob@217.205.109.249] has joined #launchpad | ||
| SteveA | I need to get a drink of something, because I ate too much chili for lunch | 01:43 |
| ddaa | I had an argument with lifeless about the "big exception catchall", and letting the branch puller go on in almost any case, but he strongly opposed that. | 01:44 |
| ddaa | SteveA: okay, ping me when the fire is off | 01:44 |
| === ddaa thinking aloud | ||
| spiv | ddaa: letting it go on in the same run is orthogonal to the logging/error reporting. | 01:47 |
| ddaa | I think another ingredient is tracking mirror attempts dates and status, so we can see what was the effective interval between mirror attempts for a branch, and the interval between successful mirrors. In addition to the current "time since last attempt, time since last success" data that we already have but do not display. | 01:48 |
| ddaa | spiv: I think it's parallel at the intersection point. Using a subprocess allows us to be confident in the good status of the control process when the pull failed, with any failure. | 01:48 |
| ddaa | Not that I am convinced that we should worry about that, but lifeless apparently thought we should. | 01:49 |
| SteveA | I want to know the simplest change that gives us reliable error reporting | 01:50 |
| SteveA | all this other stuff may well be good | 01:50 |
| SteveA | but the urgent thing is reliable error reporting | 01:50 |
| SteveA | I don't think subprocesses helps there as such | 01:50 |
| spiv | It sounds like you're not certain what lifeless's requirement/desire there was. It might be good to have the precise purpose clarified. | 01:50 |
| SteveA | I think what we need is something as simple as a try:: except: log raise | 01:50 |
| ddaa | SteveA: I think a catchall try/except will do it | 01:50 |
| SteveA | and make the "log" step really really simple | 01:51 |
| SteveA | don't rely on a databaes connection even, if possible | 01:51 |
| ddaa | add in display of last mirror attempt and last successful mirror (with more details to make the display nice, but you get the idea) | 01:51 |
| SteveA | it has worked well to write out files in a standard directory structure | 01:51 |
| SteveA | so, you might use the OOPS format | 01:51 |
| ddaa | mh | 01:51 |
| SteveA | that can then be rsynced across to devpad | 01:51 |
| spiv | Right, just write to a file with a reasonably unique name in a particular location, OOPS-style. | 01:51 |
| SteveA | you can even reuse the oops coeds | 01:52 |
| SteveA | um, codes | 01:52 |
| SteveA | I'm going to get that in my spam soon | 01:52 |
| SteveA | if you use oops codes, then we can rsync them together with the other oopses | 01:52 |
| SteveA | and use analysis and reading scripts | 01:52 |
| SteveA | jamesh: maybe you can give ddaa some pointers on this? | 01:53 |
| SteveA | the reason to keep the "log" step simple is that we can still log problems when the database or databaes connection has problems | 01:53 |
| ddaa | That's no something to display errors to the user, right? | 01:54 |
| SteveA | right | 01:54 |
| SteveA | that's a different issue | 01:54 |
| spiv | Right. | 01:54 |
| SteveA | I want to get problem 1 | 01:54 |
| SteveA | reliable error reporting | 01:54 |
| SteveA | sorted out before looking at other things | 01:54 |
| ddaa | I think there's even a bug about that somewhere | 01:55 |
| jamesh | https://launchpad.canonical.com/ErrorReportManagementForScripts has a very simple example of generating OOPS reports in a script | 01:55 |
| ddaa | https://launchpad.net/products/launchpad-bazaar/+bug/44205 | 01:55 |
| Ubugtu | Malone bug 44205 in launchpad-bazaar "supermirror branch puller logging" [Medium,Unconfirmed] | 01:55 |
| jamesh | although you should change the prefix in the config file, so as not to conflict with what the app servers are using | 01:56 |
| SteveA | use a longer previx | 01:56 |
| SteveA | prefix | 01:56 |
| SteveA | as it isn't user-visible | 01:56 |
| SteveA | we don't need to have a short OOPS code | 01:56 |
| jamesh | could just append PULLER to the end of the prefix from the config file | 01:56 |
| SteveA | that would really be a question for what stub wants to do about it | 01:57 |
| === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| SteveA | another advantage of integrating with oops reports is that you can start to use the launchpad QA team to help triage import problems | 01:58 |
| SteveA | oh, hi matsubara ! | 01:58 |
| ddaa | I think I get it. | 01:58 |
| matsubara | hello SteveA | 01:59 |
| elmo | random "are these known/reported bugs?" questions: | 01:59 |
| elmo | (1) lp.net/people/foobar just gives an oops page - would it be reasonable to return "no such users" and a search dialog instead? | 01:59 |
| SteveA | elmo: it gives a NotFound page | 01:59 |
| SteveA | which subtly contains an OOPS code | 01:59 |
| elmo | (2) lp.net/people/ search for 'nick moffit' doesn't find 'nick moffitt' - clearly it should? | 02:00 |
| SteveA | there is a bug open on offering a search | 02:00 |
| elmo | ok | 02:00 |
| SteveA | and we know exactly how to do it | 02:00 |
| ddaa | https://launchpad.net/products/launchpad/+bug/1500 | 02:00 |
| Ubugtu | Malone bug 1500 in launchpad "The product not found page should issue a query and allow creation" [Wishlist,Unconfirmed] | 02:00 |
| ddaa | not exactly the same, but close | 02:00 |
| SteveA | it's just a matter of someone having time for it | 02:00 |
| ddaa | ha, that one: https://launchpad.net/products/launchpad/+bug/1500 | 02:00 |
| ddaa | oops | 02:00 |
| ddaa | https://launchpad.net/products/launchpad/+bug/3942 | 02:01 |
| Ubugtu | Malone bug 3942 in launchpad "Present search results instead of NotFound pages" [Wishlist,Unconfirmed] | 02:01 |
| elmo | SteveA: that's fine, I wasn't chasing for it to be done, just asking if it was a known bug | 02:01 |
| spiv | elmo: Btw, I've updated the authserver performance bug (bug 61885) -- I think we'll need to do something by the end of the week. | 02:01 |
| Ubugtu | Malone bug 61885 in launchpad "authserver performance problems" [High,Confirmed] http://launchpad.net/bugs/61885 | 02:01 |
| SteveA | about the searching for near names, that's kind of like stemming I suppose | 02:01 |
| === ddaa forcibly subscribes elmo to that bug ;) | ||
| === zygis [n=zygis@88.118.241.103] has joined #launchpad | ||
| SteveA | stub: any comment? | 02:01 |
| elmo | SteveA: (unfortunately asking here is much more productive than searching across all possible bugs/products) | 02:01 |
| SteveA | stub: any comment on searching for "nick moffit" fails to find "nick moffitt" ? | 02:02 |
| === niemeyer [n=niemeyer@200.103.133.243] has joined #launchpad | ||
| SteveA | elmo: google only works in that case because many pages have that typo in it | 02:03 |
| stub | SteveA: I just use tsearch2 - I don't write tsearch2 | 02:03 |
| SteveA | searching google for "james trou" doesn't find any "james troup" pages | 02:03 |
| spiv | elmo: searching for bugs at https://launchpad.net/projects/launchpad-project/+bugs will find bugs in any of the various launchpad products. | 02:04 |
| stub | Steve's example could be done using phonetics (soundex or similar) matching, but I think that would do more harm than good even if we had time to implement it. | 02:04 |
| stub | We should dump all those sub-launchpad-products - it breaks our model and we don't need them now we have tags. Meeting agenda item? | 02:05 |
| SteveA | interestingly, google does find nick's launchpad page for "nick moffit lauchpad" | 02:05 |
| stub | soyuz, rosetta etc. | 02:06 |
| jamesh | ddaa: you should still get a 404 if you enter an invalid person name. Having a relevant search box on the 404 page is a good idea though. | 02:06 |
| SteveA | despite "moffit" not appearing on that page anywhere | 02:06 |
| stub | Google must have a better stemmer than us. | 02:06 |
| SteveA | I'd always thought they'd eschewed stemmers | 02:06 |
| stub | (assuming we are using a stemmer?) | 02:06 |
| ddaa | it looks like they do | 02:06 |
| ddaa | eschew stemmers | 02:06 |
| ddaa | they use the whole web has a giant collaborative stemmer :) | 02:07 |
| SteveA | stemming double trailing letters to the single equivalent looks like a decent plan | 02:07 |
| SteveA | elmo: congratulations, looks like you found an element of google's stemming algorithm | 02:07 |
| jamesh | any double letters would be good, actually | 02:08 |
| spiv | When dealing with names in searches, one idea is to weight earlier letters more than later ones in matching, because people tend to type the first e.g. 4 letters more accurately than e.g. the last 4. | 02:09 |
| ddaa | SteveA: so, you'd like to work on oopsing the branch puller this week, right? | 02:09 |
| ddaa | SteveA: can you clarify what additional info you need about the hct mess? | 02:10 |
| ddaa | Since we have spiv and jamesh handy it would be a good time to talk it out. | 02:10 |
| spiv | (an idea I saw at http://www.nist.gov/dads/HTML/jaroWinkler.html, which a previous employer of mine implemented) | 02:10 |
| elmo | help | 02:11 |
| === mjg59 [n=mjg59@cavan.codon.org.uk] has joined #launchpad | ||
| mjg59 | Dear Launchpad, | 02:11 |
| elmo | team soyuz are spamming build logs at me | 02:11 |
| elmo | and I can't leave the team? | 02:11 |
| mjg59 | Please stop sending me emails every time you build something | 02:11 |
| ddaa | spiv: jamesh: in a nutshell, the issue is that we cannot remove pybaz because hct depends on pybaz, and some things depends on hct helpers. Notably the productreleasefinder (several hct.util helpers and hct.scaffold). | 02:11 |
| mjg59 | kthxbi | 02:11 |
| mjg59 | elmo: Ah, you too? | 02:11 |
| mjg59 | I'm not even /on/ Team Soyuz, am I? | 02:11 |
| Spads | We're mostly getting failure messages | 02:11 |
| SteveA | ddaa: the further information is this | 02:12 |
| elmo | mjg59: everyone involved in launchpad-buildd-admins | 02:12 |
| elmo | mjg59: and the tech board is owner, which is how you get dragged in, I'd imagine | 02:12 |
| mjg59 | Ah | 02:12 |
| jamesh | ddaa: I've stripped a lot of the unnecessary hct stuff from product-release-finder | 02:12 |
| SteveA | you told me about some specific modules of hct that are used | 02:12 |
| SteveA | and I looked at those and saw that they are either spuriously used | 02:12 |
| SteveA | or easy to separate from the rest of the hct code | 02:12 |
| SteveA | but you were not specific about some other use of hct code | 02:13 |
| SteveA | so I'm asking you to be absolutely specific about what modules from hct the code depends on | 02:13 |
| ddaa | spiv: jamesh: IMO one issue is that we can either 1. duplicate the needed code out of hct 2. move the useful helpers in some separate module for hct to depend on 3. stub out hct to remove all the pybaz-dependent code. None of them is very satisfactory since hct has vocation to being fixed and released to the public. Since it will be released, it needs to be essentially self-contained. | 02:13 |
| SteveA | then we can make a plan for making it not depend on that code | 02:13 |
| jamesh | ddaa: it still uses the hct "Scaffold" test class for one fixture and a few of the path manipulation utils | 02:13 |
| SteveA | ddaa: hct in its current form is mothballed | 02:13 |
| SteveA | ddaa: also, I do not want us to depend on hct in launchpad, as it is unmaintained | 02:14 |
| === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| SteveA | so, we shall take the parts we need into launchpad code | 02:14 |
| SteveA | if a maintained hct appears in the future, we can look at removing duplication then | 02:14 |
| SteveA | to attempt to remove duplication between launchpad and a non-maintained tool is premature optimisation | 02:14 |
| SteveA | a non-maintained, non-used tool | 02:14 |
| ddaa | SteveA: so you suggest extracting the hct bits we really need out into launchpad, and keep them in a single place so we can easily clean out duplication later? | 02:15 |
| SteveA | that would be a good first step | 02:15 |
| SteveA | and we may find that we have better places for them than a single place | 02:15 |
| SteveA | I'm saying, don't care about whether the code is ever going back into hct | 02:16 |
| ddaa | jamesh: how essential is the use of Scaffold? | 02:16 |
| SteveA | it is your code now | 02:16 |
| === ddaa cringes | ||
| SteveA | as it is used only for this import stuff | 02:16 |
| SteveA | so make the best of it | 02:16 |
| SteveA | take only what you need | 02:16 |
| ddaa | Okay, I get it. Slice it down as the dead carcass that it is. | 02:16 |
| jamesh | ddaa: the one remaining fixture uses the wrapped() method on it (which provides a way to track method calls) | 02:17 |
| === carlos -> lunch | ||
| ddaa | jamesh: there must be half a dozen implementation of this thing in different places... | 02:17 |
| SteveA | not least in python 2.5, if it does what I imagine it to :-) | 02:18 |
| SteveA | well, there's partial function support | 02:18 |
| jamesh | ddaa: previously all the tests used Scaffold -- that was the only one that was non-trivial to switch to unittest.TestCase | 02:18 |
| jamesh | ddaa: Scaffold has useful features like hiding tracebacks when you run tests under the zope test runner | 02:19 |
| SteveA | I'm going to be away for a while. I have an interview to do. | 02:19 |
| ddaa | SteveA: it instruments an object so test cases can check that the right method calls are done without having to maintain whole collections of fake objects. | 02:19 |
| SteveA | sounds like it can be used independently | 02:20 |
| SteveA | like it has nothing to do with the domain of hct | 02:20 |
| ddaa | hct has tons of cool little helpers like that, that's the issue | 02:20 |
| SteveA | we need only those that are being used right now | 02:20 |
| SteveA | the rest, we can look at later and see if they'll be useful for launchpad development | 02:21 |
| SteveA | but really, the focus of the current task is to remove some deep but unnecessary dependencies | 02:21 |
| SteveA | and by doing so, to make the launchpad subsystem that you maintain simpler | 02:21 |
| SteveA | and so allow you to do more interesting things than maintain a complicated system | 02:21 |
| === SteveA -> away | ||
| === ddaa -> lunch | ||
| elmo | spiv: replied to the authserver bug - sorry, got distracted | 02:35 |
| === mjg59 [n=mjg59@cavan.codon.org.uk] has left #launchpad [] | ||
| === bradb [n=bradb@modemcable077.58-130-66.mc.videotron.ca] has joined #launchpad | ||
| === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad | ||
| Ubugtu | New bug: #62447 in soyuz "New deathrow code spams harmless exceptions when deleting symlinks" [High,In progress] http://launchpad.net/bugs/62447 | 03:15 |
| Ubugtu | New bug: #62452 in launchpad "ipw3945 not working (Edgy 2.6.17-9-generic #2 SMP)" [Undecided,Unconfirmed] http://launchpad.net/bugs/62452 | 03:45 |
| === bsppatricia [n=bsppatri@a-eskwadraat.nl] has joined #launchpad | ||
| kiko | mooorning. | 04:14 |
| === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad | ||
| === bsppatricia [n=bsppatri@a-eskwadraat.nl] has left #launchpad ["Leaving"] | ||
| sfllaw | Hey... Was there a change in the search form for Malone? | 04:40 |
| jamesh | sfllaw: there was a new code rollout today, so maybe. | 04:43 |
| sfllaw | Yeah, it broke a whole bunch of links to Malone searches. | 04:44 |
| jamesh | could you file a bug about it? | 04:45 |
| sfllaw | What was the version of Malone that was just pushed out? | 04:46 |
| sfllaw | So I can write it in the description? | 04:46 |
| jamesh | "the 2006-09-26 rollout" | 04:46 |
| sfllaw | Merci. | 04:47 |
| Ubugtu | New bug: #62466 in malone ""Untriaged" to "Undecided" rename broke search form URLs" [Undecided,Unconfirmed] http://launchpad.net/bugs/62466 | 05:00 |
| ddaa | kiko: any clue what is the purpose of canonical.doap.fileimporter? | 05:02 |
| ddaa | to me, it looks like unused code | 05:02 |
| kiko | ddaa, you're probably right. there's a lot of dead code like that. | 05:04 |
| ddaa | it depends on hct, and we are currently trying to get rid of hct because it has a deep dependency on pybaz | 05:05 |
| ddaa | kiko: do you think it should be just deleted, or moved to not-used? | 05:05 |
| === lbm [n=lbm@82.192.173.92] has joined #launchpad | ||
| kiko | ddaa, I think you should give it a grace period after announcing its demise on the launchpad list CC: mark, and then nuke it off the planet if nobody answers. | 05:07 |
| ddaa | my middle name is "rm", I do not give grace periods! | 05:07 |
| LarstiQ | what, a release manager wihtout grace periods!oneelevencos(0) | 05:16 |
| ddaa | I'm not a release manager, I'm a fearsome pirate^Wcoder. | 05:18 |
| jamesh | ddaa: so I've got the +source form mostly working as a LaunchpadEditFormView-based form. I was wondering if it'd be worth trying to merge the +sourceadmin form in | 05:34 |
| ddaa | I am not sure. +sourceadmin is intended to have significantly different permission restrictions. | 05:35 |
| === Spads_ [n=spacehob@217.205.109.249] has joined #launchpad | ||
| jamesh | it is really just a few extra action buttons, isn't it? | 05:35 |
| ddaa | For one thing, it should be unsable only by admin or vcs-imports. Then it should allow changing import details when the import has been put in production. | 05:36 |
| jamesh | (which we wouldn't display to people who lacked the permissions) | 05:36 |
| ddaa | Then, there are the extra checkboxes, yes. | 05:36 |
| jamesh | the main +source form becomes unusable once an import has gone into production ... | 05:37 |
| jamesh | (you can display it, but not submit it currently) | 05:37 |
| ddaa | that's on purpose, though the rationale was based on Arch constraints | 05:37 |
| ddaa | I guess we could relax that now, but there is little sense in doing it before the user has feedback on the status of an import. | 05:38 |
| jamesh | I set the form's permission to launchpad.EditSource in my branch, btw | 05:39 |
| jamesh | so it is only usable by people who could actually submit it | 05:39 |
| ddaa | mh | 05:40 |
| ddaa | I guess it's going to stay broken for a little while... | 05:40 |
| ddaa | it may as well be broken and simple | 05:40 |
| ddaa | unlike now, it's broken and complicated | 05:40 |
| jamesh | if we relax the launchpad.EditSource permission, more people will be able to load it. | 05:41 |
| ddaa | I mean, maybe we should allow users to change import details when the import has gone in production. | 05:41 |
| ddaa | though I'm not sure | 05:41 |
| === mpt [n=mpt@203-167-187-182.dsl.clear.net.nz] has joined #launchpad | ||
| ddaa | I find that a lot of people are just plain confused by what this does until somebody comes to explain to them. So they do pretty much random things. | 05:42 |
| === mpt perks up his ears | ||
| mpt | SteveA, ping | 05:43 |
| ddaa | mpt: I'm talking about series/+source, and how the whole vcs-import thing confuses everybody | 05:43 |
| ddaa | for good reason | 05:43 |
| ddaa | jamesh: so, yes for merging +sourceadmin with source, as long as you preserve the functionality and restrictions. | 05:44 |
| mpt | Yay for merging pages, in general | 05:44 |
| ddaa | mpt: +sourceadmin is only for my own use anyway | 05:44 |
| ddaa | jamesh: if you do that, remember to update /bazaar/+series | 05:45 |
| mpt | ddaa, what's the general use case? "Bob is interested in using Launchpad to host branches of his software"? | 05:45 |
| ddaa | so it links to the right stuff | 05:45 |
| jamesh | ddaa: I think the best way to represent the +sourceadmin checkboxes is as action buttons with the form framework. That shouldn't affect the workflow much (one less click, if anything) | 05:45 |
| ddaa | mpt: there are several use cases with different levels of cluefulness, not one general one | 05:45 |
| ddaa | jamesh: in any case, those extra thingies are for admin and vcs-imports only, so do whatevery you think is best, it's not going to confuse users. | 05:46 |
| jamesh | mpt: I'm looking at removing the first one and last two entry boxes from e.g. https://launchpad.net/products/launchpad/main/+source | 05:47 |
| ddaa | mpt: one use case is "I heard I need to put my software in launchpad to be packaged by ubuntu, so I go through all the forms I find and put what I guess is right." | 05:47 |
| === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad | ||
| jamesh | mpt: (the first box is already covered by the +ubuntupkg and +addpackage forms, and the last would be moved to +edit) | 05:47 |
| Keybuk | ngh. is Launchpad going to e-mail me every time a build fails? | 05:48 |
| ddaa | mpt: another use case is "I'm interested in using bzr, and I want to do a one-off conversion", though the conversion can be one-off multipe times (e.g. people are rearraging cvs repos in the process) | 05:48 |
| malcc | Keybuk: Hopefully not. We switched off the current spam until we can review the approach and/or some team memberships | 05:48 |
| ddaa | jamesh: I have a branch that removes the first box | 05:48 |
| jamesh | ddaa: I removed it in my branch because it was too much work to preserve ... | 05:49 |
| ddaa | jamesh: Steve asked me to fix the two other +source bugs. | 05:49 |
| Keybuk | malcc: heh, who did it send the mails to? I assumed buildd-admins? | 05:49 |
| malcc | Keybuk: Yup | 05:49 |
| Keybuk | ah, which includes the tech board | 05:49 |
| jamesh | malcc: perhaps a team email address should be set for buildd-admins (a mailing list) | 05:49 |
| ddaa | jamesh: in that case, just look at my branch, there's a trick about a test case that was missing in manage-ubuntu-pkging. | 05:49 |
| jamesh | malcc: that'd short circuit sending individual emails to each team member (plus transitive members) | 05:50 |
| ddaa | jamesh: it's in SteveA's review queue | 05:50 |
| kiko | jamesh, malcc: that sounds like the right idea. | 05:50 |
| malcc | jamesh: We could do that, but we had a solution using a mailing list anyway; if we're not going to use LP to manage who gets these, we could just roll back to that solution | 05:50 |
| kiko | malcc, I suggest you let me talk a bit about this with mdz once he's awake, and then I'll email you both | 05:50 |
| malcc | kiko: Sure | 05:50 |
| ddaa | mpt: another use case is "I am using bzr with that, and I want to register my branch. I go to +source because I was not able to find out about registering branches" | 05:51 |
| === ddaa workraves | ||
| jamesh | we still need to reword the message on the productseries index page for when there is no series branch. | 05:52 |
| mpt | These need testing | 05:56 |
| ddaa | jamesh: I found out it's also on some package page | 06:02 |
| ddaa | jamesh: I think maybe we could just remove that message. Now, it is mostly gibberish about HCT. | 06:03 |
| ddaa | jamesh: I also think that the user_branch input should be in the same form as the vcs details, since they address the same use case: "I want to specify where the code for this product can be found". | 06:04 |
| jamesh | ddaa: good idea. | 06:05 |
| ddaa | that would probably help people that ask about "launchpad does not seem to support bzr" | 06:06 |
| jamesh | ddaa: https://devpad.canonical.com/~jamesh/pending-reviews/jamesh/launchpad/bug-50569/full-diff <- that's what I've got so far | 06:07 |
| jamesh | haven't looked at refactoring +sourceadmin in yet. | 06:07 |
| doko_ | carlos: was the ooo-build.pot from OOo imported? | 06:07 |
| ddaa | jamesh: why make rcstype not-null? | 06:08 |
| carlos | doko_: hmm, no, I didn't see that there was a new .pot file | 06:09 |
| carlos | doko_: should I import it or block it? | 06:09 |
| doko_ | carlos: import it | 06:09 |
| carlos | ok | 06:10 |
| Ubugtu | New bug: #62338 in rosetta "Bad translation of translator-credits" [Undecided,Unconfirmed] http://launchpad.net/bugs/62338 | 06:10 |
| jamesh | ddaa: it makes things a lot easier to code having a real enum value for "no RCS details given" rather than using NULL (which is like "unknown") | 06:10 |
| === bradb & # iRootCanal | ||
| doko_ | carlos: it's in the tarball: ./source/ooo-build/po/ooo-build.pot | 06:11 |
| ddaa | jamesh: the other fix Steve asked me to do was bug 2649 | 06:11 |
| Ubugtu | Malone bug 2649 in launchpad-bazaar "CVS branch details should not be editable or displayed." [High,Confirmed] http://launchpad.net/bugs/2649 | 06:11 |
| ddaa | that is, remove ProductSeries.cvsbranch from the web ui, and set it to 'MAIN' when setting up a cvs import. | 06:12 |
| ddaa | So we could still set up non-MAIN imports by direct DB poking should we really need to. | 06:12 |
| jamesh | ddaa: okay. | 06:13 |
| ddaa | jamesh: maybe clarify "Launchpad automatically scans this directory regularly to import now releases" | 06:13 |
| ddaa | Also, I think the old releasfileglob docstring was more helpful to form users | 06:14 |
| jamesh | ddaa: I'll be merging the two fields together in this branch | 06:14 |
| ddaa | ok, in any case, giving some example would help people understand what sort of pattern is expected there. | 06:15 |
| jamesh | yep. | 06:15 |
| ddaa | okay, I did not see anything in your branch that made me jump | 06:15 |
| jamesh | ddaa: last thing: is there any reason to keep the last three items in the RevisionControlSystems dbschema around? | 06:16 |
| ddaa | jamesh: also, you probably want to be aware of https://launchpad.net/products/launchpad-bazaar/+bug/42928 and related bugs | 06:17 |
| Ubugtu | Malone bug 42928 in launchpad-bazaar "vcs-imports needs tests" [Medium,Confirmed] | 06:17 |
| ddaa | since it covers various problems with +source | 06:17 |
| ddaa | in particular, it should be possible to clear the vcs import details (that is the full set of db fields, including the timestamps, syncinterval etc.) in some circumstances | 06:18 |
| SteveA | mpt: hi | 06:18 |
| ddaa | jamesh: absolutely no reason to keep RevisionControlSystems.{ARCH,PACKAGE,BITKEEPER}. Though there might be some hidden deps on the PACKAGE import in some places, like importd. | 06:19 |
| ddaa | I gather that PACKAGE was meant for Sourcerer | 06:20 |
| ddaa | so it's part of mothballed lot | 06:20 |
| jamesh | don't see it used immediately, and the docstring for that value says not to use it :) | 06:20 |
| LarstiQ | SteveA: I feeld bad only pinging you about the rosetta copyright thing, can I do anything more? | 06:20 |
| ddaa | jamesh: please remove | 06:21 |
| ddaa | jamesh: I think I'll phrase it somewhat differently | 06:21 |
| carlos | doko_: yeah, I know, don't worry, it's just that the first time a new .pot file arrives I need to approve it manually | 06:21 |
| carlos | next time it will be imported automatically | 06:21 |
| carlos | it's done now | 06:21 |
| ddaa | If you see anything related to productseries-source that your do not know being used, it is almost certainly cruft, delete it. | 06:21 |
| carlos | now, the system should import its .po files | 06:22 |
| SteveA | LarstiQ: not at this time | 06:22 |
| doko_ | carlos: thanks | 06:22 |
| SteveA | mpt: I'm going to find some food. back later. | 06:22 |
| ddaa | jamesh: at that point, I think you are familiar with all the moving parts here | 06:22 |
| LarstiQ | ok | 06:22 |
| carlos | doko_: I will do the export then once that's imported | 06:22 |
| === ddaa needs to do some housekeeping | ||
| mpt | SteveA, ok | 06:23 |
| sabdfl | cprov: why is LP build system sending me mail these days? | 06:35 |
| cprov | sabdfl: because you are related with launchpad-buildd-admin team (via tech-board I suspect) | 06:36 |
| cprov | sabdfl: latelly we change build-failure-notification system to send email to member of the buildd-admin celebrity instead of a hardcoded mbox. | 06:37 |
| cprov | sabdfl: the notification is off now and we are working to propose a short-term solution. Sorry about the spams | 06:38 |
| doko_ | carlos: I don't have permission to set the description for the file | 06:39 |
| carlos | yeah, it's a bug in our side... | 06:40 |
| carlos | doko_: in the mean time, give me it and I will add it | 06:40 |
| doko_ | carlos: "OpenOffice desktop files" | 06:41 |
| doko_ | or menu, or whatever | 06:41 |
| carlos | ok | 06:41 |
| carlos | doko_: done | 06:42 |
| sabdfl | cprov: ok, thanks | 06:45 |
| === keescook [n=kees@mylar.outflux.net] has joined #launchpad | ||
| keescook | matsubara: 61590> should I join the lp mailing list? I didn't read the thread (it's private) | 06:53 |
| matsubara | keescook: you're welcome to read it. | 06:55 |
| SteveA | mpt: hi. I'm back, but I now need to cook the food. | 06:57 |
| keescook | matsubara: okay, thanks. | 06:58 |
| === keescook [n=kees@mylar.outflux.net] has left #launchpad [] | ||
| kiko | hey carlos | 07:27 |
| kiko | my refactoring is going very well | 07:28 |
| carlos | kiko: hey | 07:28 |
| kiko | I have one last step to do | 07:28 |
| carlos | cool | 07:28 |
| carlos | I also saw that you are fixing the suggestions performance problem | 07:28 |
| kiko | well | 07:28 |
| carlos | are you doing that in different branches? | 07:28 |
| kiko | TRYING. :) | 07:28 |
| carlos | say yes, please.... | 07:28 |
| carlos | :-P | 07:28 |
| kiko | what do you mean? | 07:28 |
| carlos | that the refactoring is not blocked on that bug fix... | 07:29 |
| kiko | what bug fix? | 07:29 |
| kiko | oh | 07:29 |
| kiko | no, I'll land the refactoring first | 07:29 |
| kiko | but one really depends on the other | 07:29 |
| mpt | SteveA, I'm awake again | 07:29 |
| carlos | kiko: https://launchpad.net/products/rosetta/+bug/30602 | 07:30 |
| Ubugtu | Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed] | 07:30 |
| carlos | kiko: yeah, I know | 07:30 |
| carlos | but I would prefer to get the refactoring merged so I can continue TranslationReview while you fix it (I was planning to take that task too but if you want it, it's all yours) | 07:30 |
| carlos | kiko: will you need my help fixing tests? | 07:32 |
| SteveA | mpt: hello | 07:37 |
| mpt | hi | 07:39 |
| mpt | voice call? | 07:42 |
| === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad | ||
| SteveA | mpt: ah, you didn't mention my name | 07:45 |
| SteveA | so I had no idea you'd replied. | 07:45 |
| SteveA | voice call, fine | 07:45 |
| === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #launchpad | ||
| === slytherin [n=Salazar@59.95.16.31] has joined #launchpad | ||
| slytherin | What is the expected behaviour in the case: The owner of the l10n team to which a bug is assigned is not able to set importance of the team. | 08:01 |
| === carlos -> out | ||
| === Spads [n=spacehob@host-84-9-51-137.bulldogdsl.com] has joined #launchpad | ||
| slytherin | bradb: Can you help me with my query? I was directed here by seb128 | 08:05 |
| Ubugtu | New bug: #62495 in malone "Milestone bug list doesn't sort properly" [Undecided,Unconfirmed] http://launchpad.net/bugs/62495 | 08:20 |
| === mpt_ [n=mpt@203-167-187-9.dsl.clear.net.nz] has joined #launchpad | ||
| === lfittl [n=lfittl@85-125-229-117.dynamic.xdsl-line.inode.at] has joined #launchpad | ||
| === carlos [n=carlos@12.Red-83-39-60.dynamicIP.rima-tde.net] has joined #launchpad | ||
| === slytherin [n=Salazar@59.95.16.31] has left #launchpad [] | ||
| === lucasvo [n=lucasvo@wservices.ch] has left #launchpad [] | ||
| === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has left #launchpad [] | ||
| ddaa | Need quick review for a cscvs fix: https://devpad.canonical.com/~andrew/paste/fileiuink0.html | 09:32 |
| === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad | ||
| ddaa | actually, ignore that | 09:43 |
| ddaa | it does not appear to work :( | 09:43 |
| === lukketto [n=lukketto@host43-106-dynamic.59-82-r.retail.telecomitalia.it] has joined #launchpad | ||
| === Spads_ [n=spacehob@host-87-74-19-214.bulldogdsl.com] has joined #launchpad | ||
| === lukketto [n=lukketto@host43-106-dynamic.59-82-r.retail.telecomitalia.it] has left #launchpad [] | ||
| === bradb returns | ||
| bradb | hm, slytherin seems nowhere to be found. but i guess our tooltip about editing perms isn't helping much. | 10:33 |
| === nixternal [n=nixterna@ubuntu/member/nixternal] has joined #launchpad | ||
| === AlinuxOS [n=alinux@d83-176-74-172.cust.tele2.it] has joined #launchpad | ||
| === Kuhrscher [n=jannick@88.134.177.107] has joined #launchpad | ||
| === nixternal [n=nixterna@ubuntu/member/nixternal] has left #launchpad ["New] | ||
| === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad | ||
| mdz | cprov: I got a batch of build failure notifications today; what's new there? | 11:22 |
| === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad | ||
| cprov | mdz: we modified soyuz to send email to members of launchpad-buildd-admin team (you are there via tech-board) | 11:23 |
| mdz | cprov: does it email the uploader as well? | 11:24 |
| cprov | mdz: no, because we hold a flag in config, it's prepared to | 11:24 |
| cprov | mdz: not sure if you already talked with kiko about it, as soon as you sort the membership of the buildd team or decide to have a new team for notification we can start the notifications again. | 11:26 |
| mdz | cprov: I haven't been able to talk with him much today | 11:27 |
| cprov | mdz: if you remove tech-board, only soyuz & sysadmins will be emailed (fair enough, IMHO) | 11:27 |
| mdz | cprov: I expect what we will want to do is create a mailing list and make it the contact address for l-b-a | 11:27 |
| elmo | cprov: no it's not | 11:27 |
| elmo | cprov: if you have the build logs spamming us, I will disable the MTA on drescher | 11:27 |
| elmo | I already told you several times that it's not acceptable | 11:28 |
| cprov | mdz: contact email for l-b-a is a good idea ! | 11:28 |
| cprov | mdz: only a single email will be sent, we can deal with ML subscription later | 11:29 |
| cprov | elmo: fine, we will find a better solution, dispatcher still off. | 11:29 |
| cprov | elmo: are you happy with mdz's suggestion ? | 11:33 |
| elmo | cprov: I'm entirely unconcerned how you do things as long as we (canonical-sysadmins) don't receive build notifications | 11:35 |
| cprov | elmo: ok, thanks | 11:36 |
| WebMaven | SteveA: AYT? | 11:57 |
| === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has left #launchpad ["Bye"] | ||
| Ubugtu | New bug: #62523 in launchpad "cannot edit the release date in a release" [Undecided,Unconfirmed] http://launchpad.net/bugs/62523 | 12:10 |
| WebMaven | SteveA: ping | 12:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!