=== 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 [01:01] New bug: #62375 in launchpad "_dynarch_top.DynarchMenu has no properties" [Untriaged,Unconfirmed] http://launchpad.net/bugs/62375 === 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 [02:22] mpt, if you like, I can do that removal for you.. [02:25] 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] without putting too much stress on the app server [02:26] jamesh, that is so cool! [02:26] I have.. errr.. a branch which is half-broken which intends to refactor translations :-( [02:27] it is possible that implementing the "lp:" URI scheme could be done in a similar fashion [02:27] rather than relying on special redirection handling in bzr [02:29] well.. [02:29] yeah, ISWYM. lp: would still need handling in bzr of course [02:30] but it could be dead simple and launchpad would do the redirecting necessary [02:30] quite cool actually [02:31] kiko: I know, but the lp: transport could just serve up branch branch references, which would work even with bzr-0.8 [02:31] as a plugin [02:32] the solution I worked out is to use a branch reference, similar to what you get from "bzr checkout --lightweight" [02:35] yeah, I saw your email. pretty ingenious if I may say so [02:35] anyway, time to hit the z-factory === 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] [03:20] 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 === merriam_ [n=merriam@84-12-154-102.dyn.gotadsl.co.uk] has joined #launchpad [03:28] IntegrityError [03:28] A server error occurred. [03:29] When accessing https://launchpad.net/distros/ubuntu/+source/kdeutils/+bug/58049/+upstreamtask in mozilla firefox [03:29] Malone bug 58049 in kdeutils "Kgpg crashes when I sign/verify clipboard" [Untriaged,Confirmed] [03:37] what data did you enter into the form? === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [03:41] jamesh: kdebase and http://bugs.kde.org/show_bug.cgi?id=129267 [03:41] KDE bug 129267 in general "Kgpg editor crashes when decrypting" [Crash,New] [03:42] did you get an OOPS number? [03:42] nope [03:42] just the two lines above... [03:43] ryanakca, did you enter the whole bugs.kde.org URL, or just the bug number? [03:43] whole URL === ryanakca wonders if he's being ignorant [03:43] ryanakca, at the moment you need to enter just the bug number [03:43] 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] We should accept the whole URL, but we don't yet [03:44] kk, fixed, thanks [03:44] we should definitely have something better than "integrity error" if you enter a URL there ... [03:45] yes... :) [03:45] it's confusing... maybe a "We're sorry, but we do not accept URL's at the moment, please..." page [03:55] New bug: #62393 in malone "Should be able to add a bug watch by entering the URL" [Untriaged,Unconfirmed] http://launchpad.net/bugs/62393 === jml [n=jml@ppp200-172.lns1.hba1.internode.on.net] has joined #launchpad [04:03] yippeee [04:04] lol, thanks mpt *heads off to bed* === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad [05:01] 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:02] lifeless: it makes Launchpad URLs that could represent a branch usable with bzr [05:10] I shall read on the train home - is that ok ? [05:12] sure. [05:12] 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:15] oh I see [05:16] yeah, please do an HTTP Redirect, not a simulated format. [05:17] will that still result in bzr hitting the webapp for every request? [05:21] no [05:22] maybe today, but its on the TODO to fix redirect handling [05:24] what do you think of using it as a temporary solution? Switching over to redirecting .../.bzr would involve changing browser/branchref.py [05:37] danilos, ping [05:45] danilos, unping [05:45] jamesh, ping [05:45] mpt: pong [05:45] jamesh: we're discussing it now in rl [05:45] lifeless: thanks [05:46] jamesh, I've done a very foolish thing and tried once more to change something in some Python code [05:46] but I think whatever I'm doing wrong must be fairly simple [05:47] one moment, I'll pastebin the diff [05:48] jamesh, https://devpad.canonical.com/~andrew/paste/file4ae6ux.html [05:49] (this is to fix bug 56570 in the way requested by sabdfl) [05:49] Malone bug 56570 in rosetta ""You are not an official translator" should be informational, not warning" [Medium,Confirmed] http://launchpad.net/bugs/56570 [05:51] I get "AssertionError: Can't index with type . (Must be unicode.)" [05:51] mpt: one small stylistic note: rather than doing "if CONDITION: return True else: return False", just do "return CONDITION" [05:51] heh, that's what I had first :-) [05:51] I made it more explicit in case the shorthand was the problem [05:52] mpt: are you sure it shouldn't be "not: view/user_is_official_translator" ? [05:52] That, also, I had originally [05:52] That gives a TraveralError instead of an AssertionError [05:52] TraversalError, rather [05:53] It seems like it should be view/, I agree [05:54] you've added a method in browser/pomsgset.py, but are using that method in pofile-translate.pt [05:54] are you sure the view class you modified is the one being used by the page template? [05:55] 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:56] IPOFile implements __getitem__(), which is where the assertion error would be coming from [05:56] class="canonical.launchpad.browser.POFileTranslateView" [05:56] pofile['user_is_official_translator'] [05:56] so this should be in pofile.py [05:57] probably. [05:57] in class POFileTranslateView(), no less [05:58] yep [05:58] Is there any rule for the order in which to put functions in a class? [05:58] /guideline [05:59] no general rule. It is good to group related methods together though, and have __init__ at the top [05:59] mpt: consistent with existing ordering, which might be roughly grouped by logical function, or alphabetical. Or random :/ [05:59] Here the @properties seem to be grouped [06:00] then follow the existing style [06:00] ok, now in POFileTranslateView(), but still a TraveralError [06:01] jamesh: what url is recorded as the parent when you branch using this. [06:01] lifeless: the bazaar.launchpad.net one [06:07] ahhhhh-haaaa === poolie [n=mbp@ozlabs.org] has joined #launchpad === bradb [n=bradb@modemcable077.58-130-66.mc.videotron.ca] has left #launchpad [] [06:23] lifeless, PQM claims that the time is 05:23 UTC, when it's actually 04:23 [06:24] mpt: it is using daylight savings UTC [06:24] I thought UTC was immune to that sort of nonsense [06:24] it is [06:25] it is probably displaying local time and mislabeling it as UTC [06:28] ok, spiv, want to volunteer for a five-minute review? (perhaps I've pestered jamesh too much today) [06:32] lifeless: https://devpad.canonical.com/~andrew/paste/filem2ViBA.html [06:34] stub: huh [06:35] stub: did you do an uncommit or something ? === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad [06:35] Nope [06:35] Just what you see there [06:35] Well... rsynced a copy of rocketfuel-built in there first to prime the tree [06:40] hmm [06:40] poolie: can you chat with stub about how to track the cause of this down ? [06:40] stub: can you give me some context? [06:42] oh, that paste link before? [06:43] 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] poolie: yes [06:43] poolie: The process worked fine last rollout, about three weeks ago [06:44] 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] jamesh, do you have time for a 5-minute review? [06:46] stub: and what do you mean you rsync'd in there? [06:47] We have a tree built containing a branch of launchpad HEAD, along with all the other necessary branches such as zope, sqlobject etc. [06:48] I rsynced that in place [06:51] what does bzr st in that directory do? [06:52] can you do 'bzr log --show-ids |less' in the destination and tell me if that revision id is present? [06:53] bzr st gives no output [06:54] pqm@balleny:~/production/launchpad$ bzr log --show-ids [06:54] bzr: ERROR: Branch KnitRepository(u'/home/pqm/production/launchpad/.bzr/') has no revision pqm@pqm.ubuntu.com-20060926041927-ad64e43333dd568a [06:54] I'm going to rsync in a fresh copy of the tree [06:54] mpt: okay [06:55] jamesh, https://devpad.canonical.com/~andrew/paste/filefkpSTE.html [06:55] 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:56] ok [06:57] stub: any reason not to use sftp when going between data centre machines? [06:57] jamesh: Because I need a built tree, not a branch [06:57] okay [06:58] config_manager might work on balleny now, but rsync is generally fine. [07:01] jamesh: Do you recall where the OOPS id matching code lives that is used to hyperlink them? [07:01] stub: lib/canonical/launchpad/webapp/tales.py [07:02] in the fmt:text-to-html code [07:04] Got it [07:05] mpt: the branch looks fine. Do you think there is any need to highlight the message at all (e.g. an info icon?) [07:07] Bah. There is no word break escape in posix regular expressions :-( [07:08] Oh... there it is. \m [07:09] \b matches the boundary [07:09] between alphanumeric and non-alphanumeric [07:10] jamesh, not really, I'm trying to confine use of the info icon to cases where something interesting has just happened [07:11] mpt: fair enough. The branch looks fine to merge. [07:11] thanks jamesh === 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 [07:52] lifeless, PQM has fallen over === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad [08:00] jamesh: I get a test failure with your cherry pick request. How urgent is that fix? [08:01] morning [08:01] yo [08:01] 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] Failure in test_bzrsync [08:01] stub: currently it doesn't do any logging (other than sending status info back to the authserver) [08:02] I didn't touch test_bzrsync in that revision ... [08:02] ah. kiko found a bug in that test that showed up after some sqlobject changes he made [08:03] https://devpad.canonical.com/~andrew/paste/file0N3olS.html [08:03] and he didn't revert the changes? [08:03] Hmm... [08:03] does that mean we can't check in via pqm to RF/launchpad/devel now? [08:03] SteveA: if stub is using head sqlobject with old launchpad, I guess he'd run into the problem. [08:03] I see, so launchpad head + sqlobject head works [08:03] I'll revert SQLObject a revision [08:04] stub: I'll see if kiko's fix is self contained ... [08:05] stub: looks like r4091 has the fix for that test failure [08:05] and nothing else === 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 [08:41] pqm back on line - production branch tests all passing [08:45] yay [08:54] 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. === 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 [09:26] morning [09:26] hi carlos [09:35] jamesh: product-release-finder.py should be enabled in production? [09:35] stub: not yet [09:36] k [09:36] there are a few more small things to fix === 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 [09:53] hello, when will launchpad be back again ? [09:56] yvesd: 8:55 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:57] Couple more mins [09:57] thank you danilos :) [09:57] np ;) [10:01] Launchpad is back up [10:03] cool, works :) [10:04] 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. === 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 [10:49] jamesh: I just deleted the email with your review of kiko's recent selectAlso changes [10:49] but I have a comment about it [10:49] oh? [10:49] how about a standard helper function called uniq_list [10:50] that encapsulates getting a list of stuff in the same order as an input sequence [10:50] but omitting duplicates [10:50] it's the kind of thing I'd hope to find in python's itertools, actually [10:50] but there is no such thing [10:50] it could as easily be an iterator [10:50] sounds useful [10:50] but I don't think we need it as an iterator [10:51] 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] yes [10:51] you'd want ideally to be able to supply a function [10:51] that gets a suitable memo of an object [10:51] I think all the existing itertools helpers' memory usage isn't dependent on the number of items in the iterator [10:51] for our sqlobjects, it would be its id, or in somecases (class, id) === xenru [n=Miranda@85.192.12.132] has joined #launchpad === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad [10:52] effectively the same as the "key" argument to sort/sorted [10:53] jamesh: itertools.cycle depends on the number of items in the iterator [10:53] as it needs to store them [10:53] yes, same as the key [10:53] so it does. [10:54] _thumper_: yes, could be a simple generator, as in http://docs.python.org/lib/itertools-functions.html examples [10:55] <_thumper_> it does depend on your complexity and storage constraints though [10:55] <_thumper_> I really should be working :( === xenru|clone [n=Miranda@85.192.12.132] has joined #launchpad === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has joined #launchpad [11:06] morning [11:07] morning! [11:08] matthewrevell: hi === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad [11:11] spiv: nice https://devpad.canonical.com/~andrew/paste/fileywRJCw.html [11:11] I had no idea it was so much the same as svn === 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 [12:15] how do i close my launchpad account === KeithWeissha [i=KeithWei@pool-70-111-232-241.nwrk.east.verizon.net] has left #launchpad [] [12:23] malcc: Should I update dreschers code, or restart soyuz using the existing code? === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [12:31] New bug: #62423 in launchpad "The 'appoint driver' form is broken for projects" [Undecided,Unconfirmed] http://launchpad.net/bugs/62423 [12:39] BjornT: ping? [12:39] jamesh: pong [12:40] BjornT: I was looking at moving the $productseries/+source form over to the form machinary [12:40] 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:41] jamesh: that cleanup would be great [12:41] 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] this page scares me [12:41] do you know of a way to handle that? [12:46] jamesh: did the mail about "Landing bzr-0.11 on rocketfuel" catch your attention? [12:46] New bug: #62425 in launchpad-support-tracker "Users should be able to change source package" [Undecided,Unconfirmed] http://launchpad.net/bugs/62425 [12:46] ddaa: yeah [12:46] 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:47] the third is probaby simplest for now [12:47] stub: ping? === dsas [n=dean@host-84-9-170-139.bulldogdsl.com] has joined #launchpad === siretart [i=siretart@tauware.de] has joined #launchpad [12:49] did launchpad eat all the uploads that have been done during the downtime? [12:51] 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] BjornT: good point. === BjornT -> lunch [01:02] fabbione: that would be a question for malcc [01:02] or cprov-ZzZ [01:03] ddaa: we should talk over those bugs you mentioned in the meeting yesterday === Kamion [n=cjwatson@83-216-156-196.colinw664.adsl.metronet.co.uk] has joined #launchpad [01:05] Did the LP update and database maintenance from today go normally? [01:05] fabbione: pong [01:05] Because drescher is acting very weirdly, and it's not clear that the deployment was completed [01:05] stub: what Kamion says [01:06] SteveA: ok thanks.. Kamion found everything :) [01:06] SteveA: sure [01:06] 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] stub: well, package removals aren't working due to a permission error on BinaryPackagePublishing [01:06] so either it needs to be updated, or it's just broken [01:06] Could be either [01:07] SteveA: bug 50569 has been taken by jamesh, as it's the one that's blocking PRF [01:07] 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] okay [01:07] SteveA: bug 46240 is caused by the source-package input on the +source page not understanding that empty string means "ignore that" [01:07] Malone bug 46240 in launchpad-bazaar "posting $series/+source yields a confusing warning" [High,Confirmed] http://launchpad.net/bugs/46240 [01:08] should probably be fixed by just removing that input from this form, I see no reason for it being there [01:08] there is already a separate form to associate a sourcepackage to a productseries [01:08] right [01:08] so it is old, from the original VCS imports days [01:09] 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] Malone bug 2649 in launchpad-bazaar "CVS branch details should not be editable or displayed." [High,Confirmed] http://launchpad.net/bugs/2649 [01:09] ok, I agree with that. we shouldn't encourage expectations we can't fulfil [01:10] who will fix 46240? [01:10] it's not even that, most users do not even understand what a cvs branch is [01:10] who will fix 2649? [01:10] 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] jamesh: absolutely no reason [01:10] jamesh: except that this page was virtually written by a million monkeys [01:11] then I'll definitely move it over to the main edit form [01:11] SteveA: those bugs are not assigned yet, taken in isolation they are not hard to fix. [01:11] can they be fixed in isolation? [01:11] sure, they are meaningful incremental improvements [01:12] what would you think about doing one today, and one tomorrow? [01:12] I can review for you immediately [01:12] can do that [01:12] ok [01:12] next bug... bug 48813 [01:12] Malone bug 48813 in launchpad-bazaar "Efficiently mirroring sftp hosted branches with minimal latency" [High,In progress] http://launchpad.net/bugs/48813 [01:13] SteveA: this specific bug refers to a number of improvements to the supermirror === SteveA reads [01:14] 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:15] is this causing a problem right now? [01:15] there are sporadic reports of sftp branches not being mirrored, or being mirrored too slow [01:15] it's more of a placeholder to mean "we need to fix sftp mirroring" [01:15] ok, later [01:16] maybe we should do this at the same time as installing the smartserver? [01:16] would that make sense? [01:16] it's quite essential IMO, but not easy [01:16] Mh... [01:16] sure it is essential. but is it urgent? [01:16] I think it is. [01:17] tell me the steps required to fix it === ddaa reads the bug to refresh memory [01:19] mh, I think that bug was not well chosen to convey what I think is urgent [01:19] stub: Sorry. Yes, update drescher's code [01:20] ddaa: ok. what do you think is urgent? [01:20] malcc: ok [01:21] 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] The same applies to importd, but it's less important. [01:22] One issue here is that some issues cause the branch puller to crash and burn. [01:22] And not report the error. [01:23] 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] what do we do now? [01:24] We should also display the last mirror attempt date, the last successful mirror date, the next scheduled mirror time. [01:24] I'm confused by what you mean by "sftp branch being mirrored" [01:24] I don't see how that could fail [01:24] SteveA: I mean branch puller copying the data from the sftp area to the http-published aread. [01:24] how could that fail? [01:25] SteveA: bad branch data, internal service failures [01:25] New bug: #62428 in soyuz "can't remove packages any more" [Undecided,Unconfirmed] http://launchpad.net/bugs/62428 [01:25] so, if I have a branch, I can mangle my branch, sftp it up, and then get a problem at this stage [01:25] SteveA: that's the least likely scenario, but it's valid [01:26] what is more likely? [01:26] fabbione: A bunch of uploads this morning are waiting to be processed once the deployment is finished, they haven't been lost [01:26] 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:27] bzrlib in some cases will produce data that it cannot pull. I had it once with importd. [01:27] the point of my example was [01:27] that I upload bad branch data [01:27] not that I maliciously break the data [01:27] SteveA: ha, okay. Then yes. That's an important case. [01:27] so, when you said "that's the least likely scenario" then [01:28] Kamion: Code has been updated, so things might work now [01:28] did you mean "my breaking my data on purpose" is [01:28] yes [01:28] or did you mean "my uploading bad data" is? [01:28] "breaking data on purpose and putting it manually on the sftp server" [01:28] ok [01:29] so, is there any circumstance where someone uploads bad data, and the mirroring fails, and we have an idea why? [01:29] SteveA: nope [01:29] 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] stub: yes, it's fine now - thanks [01:29] " [01:30] you mean that actually whenever a branch is not being mirrored, we have no idea why [01:30] SteveA: sometimes we have an error report [01:30] does the mirroring process produce any kind of a log? [01:30] why only sometime? [01:30] that seems strange to me, to sometimes get an error report, and sometimes not === jinty [n=jinty@39.Red-83-37-139.dynamicIP.rima-tde.net] has joined #launchpad [01:31] 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] just bail out? [01:31] so when an unknown error happens, we do not put the error in the database [01:31] or bail out, but log something first [01:31] do errors normally end up in the database [01:31] ? [01:32] 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] 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] "just bail out" means "let the error bubble up, do not write anything to the db" [01:33] 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] When I say "no idea why" I mean exactly that. [01:33] ok [01:33] so we have a number of problems here [01:34] 1. sometimes we have a failure in the system, but no record of that failure [01:34] we should fix that very soon [01:34] otherwise, we have no way of measuring our progress or our service level [01:35] 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] ddaa: stub cherry picked the branch puller logging patch [01:35] 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] because only the user can fix that [01:36] now, this can sometimes be a fault in our system that causes the user data to fail to be handled [01:36] but even then, it is a production cycle before we can fix it === Kamion [n=cjwatson@83-216-156-196.colinw664.adsl.metronet.co.uk] has left #launchpad [] [01:36] so, relative to the system in production, it is still the user that needs to deal with it [01:36] maybe by filing a bug or support request [01:37] ddaa: what do we have to do to fix these two problems? [01:38] 1. no: I do not think we even have a good definition of the service level we aim at === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad [01:38] ddaa: I'm not talking about aiming at a particular service level [01:39] I'm saying that with the system as it is, we can't even say "we achieve XXX level of service" [01:39] because we're losing error reports [01:39] so we just can't know [01:39] that's what I want fixed [01:40] I think I understand, but I'm not sure how to formulate that. [01:40] think of the OOPS system in launchpad [01:40] if there's a problem loading a page in the webapp, there is an OOPS report generated on the filesystem [01:41] and we have a reliable system for getting these onto a central location [01:41] and being analyzed daily [01:41] there are very few classes of error that will cause no OOPS to be generated [01:41] ddaa.nicotin ++ [01:41] and these classes of error occur very rarely [01:42] how it works is the "render a page in response to a request" code has a big try: except: around it [01:42] and if there is an exception, an OOPS report is generated [01:42] now, can we do something equivalent, maybe not so fancy, for the imports/ mirroring? [01:42] thinnk about it over your cigarette break [01:43] I think we can do it by spawning a subprocess for each branch [01:43] ping me after your cigarette break === Spads [n=spacehob@217.205.109.249] has joined #launchpad [01:43] I need to get a drink of something, because I ate too much chili for lunch [01:44] 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] SteveA: okay, ping me when the fire is off === ddaa thinking aloud [01:47] ddaa: letting it go on in the same run is orthogonal to the logging/error reporting. [01:48] 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] 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:49] Not that I am convinced that we should worry about that, but lifeless apparently thought we should. [01:50] I want to know the simplest change that gives us reliable error reporting [01:50] all this other stuff may well be good [01:50] but the urgent thing is reliable error reporting [01:50] I don't think subprocesses helps there as such [01:50] 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] I think what we need is something as simple as a try:: except: log raise [01:50] SteveA: I think a catchall try/except will do it [01:51] and make the "log" step really really simple [01:51] don't rely on a databaes connection even, if possible [01:51] 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] it has worked well to write out files in a standard directory structure [01:51] so, you might use the OOPS format [01:51] mh [01:51] that can then be rsynced across to devpad [01:51] Right, just write to a file with a reasonably unique name in a particular location, OOPS-style. [01:52] you can even reuse the oops coeds [01:52] um, codes [01:52] I'm going to get that in my spam soon [01:52] if you use oops codes, then we can rsync them together with the other oopses [01:52] and use analysis and reading scripts [01:53] jamesh: maybe you can give ddaa some pointers on this? [01:53] the reason to keep the "log" step simple is that we can still log problems when the database or databaes connection has problems [01:54]