[12:10] one minute === camilotelles [n=Camilo@20132194128.user.veloxzone.com.br] has joined #launchpad [12:30] too late, I'm going to bed. Staying connected for the scrollback. [12:31] ok [12:31] anyway, I'll have answers tomorrow [12:31] but as your scripts do not write to the sm directly, it should not matter to you or niemeyer [12:31] ditto for reading, the ids are not exposed outside the SM machine [12:32] lifeless: it would be simpler for us to read directly from the id-based FS. [12:32] and more robust as well [12:32] niemeyer: No, that internal structure isn't in place yet. [12:32] then we should change the specs [12:32] we do not want the id based FS to leak [12:32] it's not leaking... bzrsync is an internal system. [12:32] in fact, we should not use the real id based FS to read, it would make to tight coupling [12:33] we should use a flat structure exposing the ids for internal use [12:34] lifeless: this is niemeyer [12:34] niemeyer: this is lifeless [12:39] spiv: would it be feasible for you to hack something to give us that flat id namespace on an internal http? [12:40] I mean, before next week. === niemeyer [n=niemeyer@200.138.135.140] has joined #launchpad [12:46] spiv: so, did you lose the sm sftp stuff with your laptop ? [12:52] ddaa: So, that's easy... assuming the internal storage is flat ids, just run a private httpd, e.g. plain apache, on a private port serving them. [12:53] lifeless: Almost none, the vast bulk of it was mirrorred. The larger setback was the change to use just branch ids rather than person-id/product-id/branch-name ;) [12:54] spiv: re flat id space - right, but if the internal ids get path-shuffled, we'd want a mapping to keep them flat [12:55] so that the logical access and physical storage are not conflated [12:55] lifeless: So, the SFH spec currently says that an ID of abcdef12 would be stored on disk in a directory ab/cd/ef/12. [12:56] spiv: niemeyer is working on making bzrsync a good citizen of launchpad/cronscripts, and make it scan the public supermirror. For rollout monday next week at the latest. I'd like that code to to use branch id to access the bzr branches on SM regardless of what the backend FS looks like. [12:56] So the apache would need a simple mod_rewrite. [12:56] spiv: right. [12:56] If we ever change that scheme, we'd obviously need to update the mod_rewrite config in that httpd. [12:56] spiv: right. [12:57] spiv: so I'd like that published as 'http://internal/+ids/abcdef12 [12:57] i.e. I'd expect it to be serving from http://foo/bar/abcdef12 not http://foo/bar/ab/cd/ef/12. [12:57] that said, I'm heading away, thanks guys [12:57] Sorry, I'm obviously not awake enough, I assumed you read my mind and thought that was obvious ;) [12:57] ddaa: Good night. [12:58] night ddaa [12:58] I'm not sure that the branches on the supermirror currently have branch records in Launchpad... [12:58] spiv: lifeless: btw, while you are around with niemeyer, can you fill him with the specific testing requirements for cronscripts, if any? [12:59] spiv: they do not [12:59] spiv: abcdef12? [12:59] spiv: if they don't they bzrsync do not care. [12:59] spiv: Isn't it just 12? [12:59] niemeyer: we are defining a new publishing address for branches on the supermirror [12:59] Hu, I mean bzrsync do not care abotu branch that are not in launchpad. [12:59] lifeless: Yeah, I got that part.. ;) [12:59] niemeyer: if the database id was 'abcdef12' [12:59] lifeless: Ah, ok.. database ids are numbers always. [12:59] then the url would be 'http://internal/+ids/abcdef12' [01:00] niemeyer: this is true, and thus confusing as an example ;) [01:00] niemeyer: abcdef12 is a number in base 16 ;) [01:00] spiv: Ah, of course. My fault.. :) [01:02] (the librarian's on-disk storage uses that scheme, also with hex) [01:03] spiv: I think to http publish decimal is easier to debug [01:04] spiv: Yes, but they're hashes, while database ids are not (as we're talking in the other window :) [01:04] niemeyer: No, they're not, as I'm saying in the other window :) [01:05] It won't be fantastic, but it'll be good enough. [01:05] Each directory will have a maximum of 256 entries at any level. [01:05] So while the existing entries won't be evenly distributed, it will avoid the major suckage of having thousands of entries in a single directory. [01:05] I guess a cheap way to improve that would be to reverse the segments: [01:05] 12/ef/cd/ab [01:05] spiv: Interesting [01:05] hmm [01:06] lifeless: I don't see how it would be easier to debug -- it's just a number either way. Converting to and from hex isn't hard: python -c "print 0xabcdef12, hex(12345678)" ;) [01:06] spiv: one has to do that === niemeyer leaves for some food, bbiab.. [01:06] spiv: postgres gives you decimal output [01:06] lifeless: How about this. [01:07] lifeless: You figure out how to write the rewrite rule to do the conversion, and I won't care ;) [01:07] heh [01:07] well, lets do hex then [01:07] as I don't care *that* much [01:08] postgres has a to_hex() function, if that helps [01:09] jamesh: Beat me to it :) === Alinux [n=Ubuntu@d83-176-98-71.cust.tele2.it] has joined #launchpad [01:10] hello [01:11] can tell me someone, if .po files translated in lauchpad are syncronized with original .po files? [01:12] perhaps /+hexids/abcdef12 [01:12] so its clear to someone debugging [01:13] Alinux: if the upstream maintainers export them from rosetta and include them, yes [01:14] Alinux: for Ubuntu, the rosetta data is also exported as language packs [01:14] lifeless: That's a good idea. [01:15] yes I know... but it measn that for example "nautilus" translated in Georgian in Ubuntu will never appear in "nautilus" of Debian or SuSE etc... [01:15] = [01:16] Alinux, it depends on the georgian gnome translating team [01:16] Alinux: you could request an export and then ask someone on the gnome-i18n list to commit it [01:16] if they export them, then they will be included [01:17] Alinux: if you are part of the gnome translation project, you could commit updated PO files easily too [01:17] gnome gnome, or ubuntu gnome? [01:17] gnome gnome [01:18] I'm in Ubuntu Georgian translators team [01:18] Alinux, here is how it works [01:18] not in gnome. [01:18] GTP [01:18] Gnome translators have their own procedure about which translations/translators they accept [01:18] so Ubuntu can't force them to use its translations [01:19] if they want to, they can [01:19] they generally will, if they think they are good enough, and are aware that they exist [01:20] mdke, sei tu ? :) [01:20] yes [01:20] ciao bro :) [01:20] hi === AlinuxOS [n=Ubuntu@d83-176-98-71.cust.tele2.it] has joined #launchpad === Alinux [n=Ubuntu@d83-176-98-71.cust.tele2.it] has left #launchpad [""] === zygis [n=zygis@clt-84-32-129-122.dtiltas.lt] has joined #launchpad [02:14] looks like ddaa's branch added a patch-25-99-0.sql [02:14] which doesn't look like an approved patch number [02:35] jamesh: shouldn't be a problem, we're on a -40- baseline now? === Kinnison beds [02:36] ciau [02:39] Kinnison: it still gets applied by "make schema", without any errors [02:39] just makes me think it hasn't been approved [02:39] (not that it wouldn't get approved) === egi [n=egi@202.153.241.101] has joined #launchpad [03:54] spiv: around? [03:55] jblack: Yeah. [03:56] Remember that config class we made back at UBZ? [03:56] we replaced Config.get() with a __getattr__(self, var) [03:57] Hmm, I don't remember that at all. [03:57] Perhaps you're thinking of someone else, or perhaps you just need to jog my memory more :) [03:57] Never mind. I figured it out. [03:58] THanks for the help. :) [03:58] Excellent :) [04:16] jblack: I think I was the one helping you out then. [04:16] Oh, yes. That's right. === stub [i=stub@sweep.bur.st] has joined #launchpad === Keybuk [n=scott@descent.netsplit.com] has joined #launchpad === dewd [n=dewd@201009186135.user.veloxzone.com.br] has joined #launchpad === robitaille [n=robitail@ubuntu/member/robitaille] has joined #launchpad === fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad === lbm [n=lbm@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #launchpad === fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad === Burgundavia [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad === fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad === raketti [n=kikkeli@a80-186-162-192.elisa-laajakaista.fi] has joined #launchpad === raketti [n=kikkeli@a80-186-162-192.elisa-laajakaista.fi] has joined #launchpad === SteveA_ [n=steve@195.182.78.95] has joined #launchpad === netjoined: irc.freenode.net -> brown.freenode.net === stub [i=stub@sweep.bur.st] has joined #launchpad [09:31] morning everyone [09:32] hi [09:34] yo [09:57] jamesh: how's the error reporting stuff looking? [09:58] jamesh: bizarre, I didn't think we applied patches except within the baseline. [09:59] SteveA_: okay. I've got the hooks in place, just need to finish off the code that writes out the exception files [09:59] Kinnison: maybe that's a bug too ... [09:59] jamesh: perhaps. I'd mail stub if I were you [10:04] Kinnison: no need: see item 3 on http://pqm.ubuntu.com/ [10:06] aha [10:06] coolio === Ubugtu [n=bugbot@ubuntu/member/seveas] has joined #launchpad === GoRoDeK [n=gorodek@p5083D9AE.dip.t-dialin.net] has joined #launchpad [10:17] Morning all [10:18] hi sivan [10:18] Kinnison: Hey Daniel, what's cooking? [10:19] sivang: not much, just sorting through my TODO [10:19] Had to get up early today to take the car in for its MOT [10:19] Kinnison: ah, good [10:19] so I'm still under-caffeinated [10:19] Kinnison: MOT ? [10:19] sivang: it's a test which all cars over a certain age take each year to ensure they're road-worthy [10:20] something that has to be done every 6 or 12 months here, for every car === Kinnison nods === Kinnison expects something will need fixing [10:21] maybe a tyre or two will need replacing [10:21] Kinnison: oh, right. we have this here as well [10:22] Kinnison: what brand of car is that? [10:22] sivang: I have a Daewoo === carlos [n=carlos@243.Red-83-47-24.staticIP.rima-tde.net] has joined #launchpad [10:22] s'not brilliant, but it works [10:23] morning [10:24] Maybe they should do the same for politicians. [10:24] ddaa: what, check every year that their brake pressure is high enough and that their tyres have enough tread? [10:24] In substance. [10:24] ddaa: for politicians, it's called an election [10:25] jamesh: nah, an election is like crossing an intersection. [10:26] That a car crosses an intersection means neither that the driver is awake (i.e. crossing when the traffic light is green) nor that the car is able to turn or brake (it just needs to go straight ahead). [10:27] Occasionally, a policitician crashes when crossing an election. That's called a Watergate. [10:27] or it crosses all right but then roll over a few pedestrians. [10:27] That's called Dubia. [10:28] Or Tony Blair if you want. [10:29] Oh BTW, apparently the fellow was caught having a phone conversation where he suggested bombing Al-Gesira :) [10:30] more practically [10:30] ddaa: LOL [10:31] jamesh: I have few questions for you about the where and whys of launchpda cronscripts. [10:31] jamesh: got a few minutes? [10:31] ddaa: sure. [10:32] So context: we need to have a new cronscript for bzr branch scanning. niemeyer is the guy that's going to work on actually doing it. [10:33] What are the requirements for new cronscripts, in terms of integration with launchpad, testing, deployments, etc. ? [10:35] Actually, It's just one big sweeping question ATM. I have more pointed ones, but I'd like if you could generally, "tell me what you know". [10:35] ddaa: best practice is to put the meat of the script in lib/canonical/launchpad/scripts as a module, and write it in a form where it can be tested [10:35] ddaa: then make the actual script in cronscripts/ a small program that uses the above module [10:36] i think niemeyer talked with spiv yesterday about this also [10:37] did not see much relevent talk in the backlog... maybe it was a private discussion? [10:37] dunno. i just read it on gustavo's activity report. [10:38] The public log has much talk about SMFSH, which is orthogonal to the cronscripting. [10:39] SteveA_: I also wonder what's the purpose of the ./cronscript/tests directory [10:40] it's empty here === koke [n=koke@ubuntu/member/koke] has joined #launchpad === carlos [n=carlos@216.Red-83-49-58.dynamicIP.rima-tde.net] has joined #launchpad [10:43] jamesh: is there a cronscript template somewhere? In the current collection of scripts, it hard to tell what's best practice and what's this way just because it's the way it is. [10:45] ddaa: scripts/bugzilla-import.py in https://chinstrap.ubuntu.com/~jamesh/pending-reviews/jamesh/launchpad/bugzilla-import/full-diff isn't too bad [10:48] Mh... I guess that means the bzrsync should move out of lib/importd and become a good citizen of the launchpad testing framework... [10:51] jamesh: is there a set of required command line options? [10:52] ddaa: not really. [10:53] ddaa: if you are producing log messages, it is good to use canonical.launchpad.scripts.logger_options() and c.l.s.logger() to set up logging [10:53] ddaa: that'll give consistent handling of --verbose and --quiet args [10:53] Wel... if you remove mysql and and optparse, there's not much left of your script... [10:54] mh... ok [10:55] Is there anything tricky I should now about launchpad.conf integration? [10:55] * I should know [10:56] not really [10:56] edit lib/canonical/config/schema.xml to define new keys, set appropriate values in the various configs under configs/ [10:57] well, separate db user, so will probably need a rework of security.cfg, I figured out. [10:57] Has schema.xml, thanks! [10:57] Did not notice that before. [10:58] Mh.... I think that completes the integration questions. Now, the deployment questions :) === dewd [n=dewd@201009186135.user.veloxzone.com.br] has joined #launchpad [10:59] Who is in charge of rolling out a cronscript and setting up the cronjob? [11:00] I mean, is that centralised (stub/elmo/etc. does them all), or is that everybody does its own? And on which system? [11:04] ddaa: Talk with stub, I think. [11:04] stub: ping! [11:05] ddaa: Even if it's something that doesn't run on the same machines as the production webapps, it's still likely he'll need to know about it for rollouts and planned outages. [11:06] spiv: well, ATM I'm try to figure out what's the general policy and whether there's any policy. [11:07] one question related to that, is what is the recommended procedure for cronscript feedback? Email? And then to who, configured in which way? [11:08] I can imagine many combinations there, but I'd like to know what's currently being done before asking niemeyer to do something that will waste his time in review. [11:08] The other cron scripts mail to the launchpad error reports list. [11:08] ddaa: assuming you are using the standard logging framework, setting the log level to the appropriate level should result in only errors getting printed [11:08] ddaa: so if you run the script at that logging level, cron will mail out the output [11:09] I think this is done by making the cron jobs themselves look for output on stderr, and mail if appropriate. [11:11] jamesh: mail the output to the launchpad-error-reports mailing list? [11:12] ddaa: I think that's how it works [11:14] SteveA: can you approve my subscription to launchpad-error-reports, please? === raketti [n=kikkeli@a80-186-146-96.elisa-laajakaista.fi] has joined #launchpad [11:17] ddaa: no [11:17] ddaa: i'm not manager of that list [11:17] oh, aparently i am [11:17] how odd [11:19] ddaa: you're approved [11:26] ddaa: Pong [11:26] (had the sound down sorry) [11:29] ddaa: I'm generally the person who turns on the various cron stuff, and am the point of contact for that. [11:30] ddaa: cronscripts generally just spit their output to stdout/stderr and cron takes it from there (sending the output to launchpad-error-reports) [11:32] ddaa: Which makes the scripts testable. Ideally your script will not produce any output if run with '-q' to avoid needless spamming, unless it is important for people to be aware that it actually *did* run (such as backups or critical stuff) [11:32] Hu... define critical? [11:35] ddaa: Stuff you will be explicitly checking for in your in tray every day. [11:36] In my specific case, the task is scanning bzr branches to populate the database. I expect that sooner or later we'll want to be able to see what has been done during the last few runs (for diagnostic, in case something smells fishy). What would be the way of handling this sort of logging? [11:36] ddaa: I can't think of any of our existing systems that are like that, except for possibly the shipit exports (and marileze gets that status through another mechanism anyway) [11:37] ddaa: Sure. Just output overview stuff using log.info(), verbose debugging noise using log.notice() [11:37] ddaa: Then we roll it out and, when we are happy with how it is performing, we can add the '-q' option to reduce the daily noise. Or add the '-v' option if things are screwing up and we need the debug noise. [11:38] ddaa: So just use the launchpad.scripts.logger stuff jamesh mentioned above [11:39] Which gives you nice timestamps and stuff in your output, which is very useful for stuff running as a cronjob [11:42] ddaa: Will your script run happily on the standard production servers, or need to run on a specific server or a dedicated server? [11:42] Do you usually run jobs as a specific user on a specific system? I'm used to having a lot of control over the bazaar-related subsystem so I can do rollout or tweak this kind of diagnostic knobs myself. === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [11:44] ddaa: No, but we should be ;) [11:44] I do not expect that specific script is going to have exotic requirements. It's mostly running bzrlib over sanitised branches to extract metadata (so I do not expect high CPU or memory usage) and fill the database. [11:44] ddaa: If you want to run it yourself, that is fine. I just need to give DB access to the relevant accounts and possibly do test runs for you on the staging server. [11:46] Though, it can potentially run a large number of transactions when new branches are published. [11:46] carlos, quick question... dapper translations will change a lot soon? i.e., something like breezy imports? or is more or less stable by now? [11:46] WaterSevenUb, will change a lot soon [11:47] carlos, ok:-) thanks. How about saying those things on Rosetta-users?:) I'm afraid translators get mad loosing their work... [11:47] no work will be lost [11:48] ok, great ;) [11:48] stub: oh BTW, somebody pointed out that I merged my patch as patch-(something)-99.sql :) [11:48] ddaa: I noticed ;) There is a patch in PQM to fix that (failed to land it yesterday) [11:48] Should I fix that myself or leave you make it dbadmin kosher? [11:49] nice, thanks [11:49] ddaa: It is running on staging if you want to confirm the new schema works with launchpad happily [11:53] I fully expect there will be no problems. [11:53] Had a quick look though. [11:53] The code is very thouroughly tested. [11:54] stub: is there a rollout policy for cronscripts? [11:54] I mean, is that bound to the launchpad rollout schedule, or can we nag you randomly to update or rollout new cronscripts? [11:56] ddaa: I like to be nagged. Just because the script has landed doesn't mean it should be turned on yet, as there may still be outstanding dependancies (eg. debbugs syncing waiting on Gina) [11:57] ddaa: Turning them on isn't bound to the launchpad rollout schedule, and if you are maintaining the codebase that runs it it doesn't even have to be the production branch you are running (which could cause issues with our mutating database schema, but if you want the rope you can have it) [11:57] Thinking of which. I think I'd like to to be able, at least, to kick the script by hand now and then. For example when an interesting community member just registered a branch I'd like to be able to cause an immediate scan. [11:58] ddaa: interesting choice of sample data, btw ;) [11:58] I'm pretty much in control of the db schema bits relating to this. And I'm used to having massive version skew with production on importd... [11:59] For example, I'm about to rollout the new importd, and it's expectd to work seamlessly with the old and new schemas. [12:00] stub: So, I think it would be nice to have a new user we can both login into for controlling bzrsync. [12:00] sounds reasonable? [12:01] ddaa: Sure. Macquarie would be a good choice then since we both already have accounts there and it already has other connections to the production db. [12:01] jamesh: well, gnome-terminal was one of the few sampledata products that were not already "polluted" by hct sampledata :) [12:02] ddaa: Just stick an issue into rt for elmo/znarl [12:03] oh, BTW I need to go scream because it (and the importd systems) do not have bzr yet :( [12:04] ddaa: We are building it from source to avoid having to keep rolling out the dailies (with is a pita, and blocked me updating staging yesterday and production today :-( ) [12:04] that does not sound that much a PITA... [12:05] ddaa: rollout.py in the main config tree is what I'm using [12:05] ddaa: It is a pita when the current version we are supposed to use doesn't work with our archives ;) [12:06] Cannot use that. [12:06] Robert seemed happy with installing 0.7 though when it is released [12:06] The importd stuff requires some uncommitted changes (builbot's private.py) and some non-source files to be preserved (though it could be argued that's a bug). [12:07] Mh... I guess I could w/o bzr... [12:08] I can move the critical data "by hand". [12:08] Sounds like a bug - I would say private.py and the non-source files needing preservation should not be in the tree. Makes rollouts and the corresponding documentation much easier === matsubara [n=matsubar@201-27-7-58.dsl.telesp.net.br] has joined #launchpad [12:08] good morning! [12:08] stub: IMO using buildbot at all is a bug. [12:09] We already do this for the main production launchpad instances (there is a ZCML script that lives outside of the tree that contains the IMAP password) [12:09] And I'm not sure at all we can move the private.py away. [12:09] mh... yes we can... === niemeyer [n=niemeyer@200-140-230-173.ctame7043.dsl.brasiltelecom.net.br] has joined #launchpad [12:13] hey niemeyer [12:13] ddaa: Hello === beyond [n=beyond@201-27-7-58.dsl.telesp.net.br] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === cprov [n=cprov@201-27-7-58.dsl.telesp.net.br] has joined #launchpad [12:19] good morning === _Rappy_ [n=hunt-pre@dsl-253-122.monet.no] has joined #launchpad === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:40] a translator asked me if his work was being lost somehow since his "karma" was going down... how is Karma measured ? [12:40] Karma decays over time [12:40] So you have to keep doing work in order to keep it up [12:40] yeah.. that's what I thought... [12:40] .) [12:40] kinnison, ok thx [12:40] No problem [12:45] kinnison, see bottom https://wiki.ubuntu.com/NewTranslatorQuestions - answer to the karma question. More or less fine?:) [12:47] seems fine [12:47] salgado: does it look right to you? [12:51] yep, it's okay [12:54] hmm, can anyone tell me why I am getting "orry, you don't have permission to access this page." on https://launchpad.net/distros/ubuntu/+spec/dapper-desktop-plan/+status? It wsa suggested as an example in an email to u-d sent by JaneW === KenWeill [n=admin@203.189.11.2] has joined #launchpad [12:58] oh, and another question - why is my Karma dropping in launchpad? :) === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [01:07] lifeless, Is there any trick to do a bzr mirroring fast? [01:07] carlos: use bzrtools and its rsync push rather than sftp:// push [01:08] Kinnison, tried a local mirror and then direct rsync but the local mirror is still slow [01:08] Kinnison, what should I use? rsync:// ? [01:08] bzr push rsync://.... ? [01:09] bzr push chinstrap.ubuntu.com:/home/warthogs..... === carlos tries it.. [01:15] Kinnison, seems to work as I wanted. Thank you! [01:16] carlos: You're welcome [01:16] bzr: ERROR: bzrlib.errors.NoSuchRevision: Branch BzrBranch(u'/home/dsilvers/dev-canonical/rocketfuel-mirror-of-launchpad/launchpad') has no revision pqm@pqm.ubuntu.com-20051122113309-82dcc8325c5c0d19 [01:16] urgh :-( [01:17] sounds bad... [01:17] I *think* this is a known issue with bzr === Kinnison tries to remember how to fix it [01:26] stub, around? === SteveA [n=steve@85.206.173.85] has joined #launchpad [01:28] Kinnison: I think lifeless fixed it last time [01:29] jamesh: hmm [01:36] jamesh: Is it easy to have the same remedey you suggested for #3600 be applied to the whiteboard text handleing of the specification tracker? :-) [01:43] funny, googling for "introduction to quilt" gave me a document with exactly the title I was looking for, but not the content === Kinnison grins and goes to prep lunch [01:46] Kinnison: bon appetite! === carlos -> lunch [01:48] salgado: yes [01:48] stub, is it possible to optimize this: https://chinstrap.ubuntu.com/~dsilvers/paste/file6sINHz.html [01:49] ? === _Rappy_ [n=hunt-pre@dsl-253-122.monet.no] has joined #launchpad [01:56] salgado: Nothing obvious. I'll have a closer look later === stub buggers of for an hour [01:57] stub, ok, thanks. :) === thisfred [n=thisfred@a80-127-80-154.adsl.xs4all.nl] has joined #launchpad [02:16] ddaa: Great job on the document [02:28] carlos: ping [02:51] brb, gotta reconnect the router [03:02] salgado: https://chinstrap.ubuntu.com/~dsilvers/paste/filewrXAog.html === Kinnison [n=dsilvers@haddenham.pepperfish.net] has joined #launchpad [03:02] salgado: The way you have is only taking 3 or 4 seconds to execute though, so perhaps there is another query on that page that is causing the time to be chewed up? === mgalvin [n=mgalvin@host-66-202-95-170.spr.choiceone.net] has joined #launchpad === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad === zygis [n=zygis@clt-84-32-129-122.dtiltas.lt] has joined #launchpad === kiko [n=kiko@201-27-7-58.dsl.telesp.net.br] has joined #launchpad === raketti_ [n=kikkeli@a80-186-146-96.elisa-laajakaista.fi] has joined #launchpad === raketti_ [n=kikkeli@a80-186-146-96.elisa-laajakaista.fi] has left #launchpad ["Lhdss"] === zerokarmaleft [n=zerokarm@ip68-12-45-133.ok.ok.cox.net] has joined #launchpad === SteveA [n=steve@195.182.78.95] has joined #launchpad === matsubara is now known as matsubara-lunch === lamont [n=lamont@mib.fc.hp.com] has joined #launchpad [04:13] hello guys [04:13] how is everybody? === carlos [n=carlos@81.Red-83-49-60.dynamicIP.rima-tde.net] has joined #launchpad [04:15] Kinnison? [04:16] hi carlos [04:16] we have a few code things to talk through. and i have another 2/3 of the review to do [04:16] SteveA, pong [04:16] hi [04:17] kiko: hey [04:17] kiko: what can I do for you today? [04:18] Kinnison, let's talk soyuz some, shall we? [04:20] kiko: sure, can I have a few mins to finish up this function? [04:20] yeah sure [04:20] take off the tuxedo etc [04:21] what? [04:26] SteveA, ? [04:26] carlos: can we talk in 30 mins or so? [04:27] SteveA, sure [04:27] Kinnison, the function you're finishing. === Kinnison is confused [04:30] Okay, what do you want to talk about? [04:30] Kinnison, guess and win 5$? I think elmo would be helpful here as well -- elmo, are you available? [04:43] Kinnison, well, let's try again in 1h. can you please try and get hold of elmo? I'd like to see if we are moving to drescher. [04:43] kiko! [04:43] Welcome back [04:43] stub suggested we shouldn't [04:43] hey niemeyer [04:43] did you not see that mail? [04:44] Kinnison, not yesterday. I know he suggested that -- he said so at UBZ as well. I was wondering if he had reconsidered [04:44] he's suggesting living without staging then? [04:45] Seems to be what he's advocating === kiko scratches head [04:45] well, if that's the case. [04:46] Kinnison, at any rate, we should talk status and see how I can help you [04:47] Okay, give me 2 mins and we'll talk status [04:47] Kinnison, 1h is better, I need lunch [04:48] kiko: okay, one sec... 17:00 UTC? 1h13m from now [04:48] that's perfect [04:48] thanks [04:53] hmmmm. is pqm borked again? === matsubara-lunch is now known as matsubara [04:55] salgado: I think it's due to the load on chinstrap. But it's not always easy to tell if pqm is down or just unbelievably slow. === diegor_ [n=diegor@141.250.103.68] has joined #launchpad === diegor_ [n=diegor@141.250.103.68] has left #launchpad ["Client] === Kinnison takes advantage of this gap to retrieve his car from the garage [05:13] ciao === lbm [n=lbm@x1-6-00-13-10-7a-d1-e4.k233.webspeed.dk] has joined #launchpad === jinty [n=jinty@205.134.224.215] has joined #launchpad === heyko [i=tor@tor/session/x-41ba7e10114506c8] has joined #launchpad [05:18] jamesh: around? === camilotelles [n=Camilo@20132194128.user.veloxzone.com.br] has joined #launchpad === bradb writes email instead [05:26] hmm [05:26] someone added a wrong db patch to launchpad... [05:26] carlos@aragorn:~/Work/Canonical/trivial/database/schema$ ls patch-* [05:26] patch-25-99-0.sql patch-40-00-0.sql patch-40-02-0.sql [05:26] carlos: shall we talk about the translation queue stuff now? [05:27] ddaa, I think it's about your work on launchpad, not sure who added them... [05:27] SteveA, sure === heyko [i=tor@tor/session/x-d5505d8df3e8e96f] has joined #launchpad [05:28] 'lib/canonical/launchpad/browser/translationimportqueue.py' [05:28] carlos: can we look at that first? [05:29] sur [05:29] sure [05:29] so, i made some comments about this set of 4 methods [05:29] has_things_to_import, has_pending_reviews, readyToImport, pendingReview [05:29] first two are properties, actually [05:30] right [05:30] I don't see why a raw SQL query should be used there... [05:30] raw sql? [05:31] "Maybe this should go to an SQL query?" isn't it what you are suggesting? [05:31] no [05:32] first of all, the code to has_things_to_import looks almost the same as readyToImport [05:32] @property [05:32] def has_things_to_import(self): [05:32] """Return whether there are things ready to import or not.""" [05:32] for entry in self.context.getEntries(): [05:32] if entry.import_into is not None: [05:32] return True [05:32] return False [05:32] def readyToImport(self): [05:32] """Iterate the entries that can be imported directly.""" [05:32] for entry in self.context.getEntries(): [05:32] if entry.import_into is not None: [05:32] yield entry [05:32] [05:33] yes is the same [05:33] so, why not write has_things_to_import in terms of readyToImport ? === Turicas [i=justen@200141097237.user.veloxzone.com.br] has joined #launchpad [05:33] I thought it was easier to understand that way [05:34] maybe. it will also make people wonder if they've missed something, seeing the repeated code [05:34] SteveA, well, it's not exactly the same, but it's quite similar [05:34] the returned value is different [05:34] you could do this: [05:34] @property [05:34] def has_things_to_import(self): [05:34] """Return whether there are things ready to import or not.""" [05:34]