=== Cogito_ergo_sum [n=c27@201.210.108.110] has joined #launchpad === jinty [n=jinty@132.Red-83-55-196.dynamicIP.rima-tde.net] has joined #launchpad === Fujitsu_ [n=Fujitsu@203.23.49.35] has joined #launchpad === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [01:00] did FOAF get some ungodly overhaul? [01:01] oh, nm, I'm being sdtupid === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad === Ubug2 [n=bugbot@ubuntu/bot/ubugtu] has joined #launchpad === JanC [n=janc@lugwv/member/JanC] has joined #launchpad === jkakar [n=jkakar@204.174.36.228] has joined #launchpad === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad [02:00] Goooooooooooooooooooood afternoon Launchpadders! === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [02:09] SteveA, sure, whenever you and I are next both awake === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad === Cogito_ergo_sum [n=c27@201.210.108.110] has left #launchpad ["Ex-Chat"] [02:47] we've now got new products in LP titled "Xen for Ubuntu" and "Xen for Ubuntu (really)" === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad [02:55] rock [02:58] kiko-zzz: thanks for the UWN edits. I will massage as needed [03:25] New bug: #59113 in launchpad "Person chooser doesn't enter text into the field" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59113 [03:35] jamesh, that's bug 38349 [03:35] Malone bug 38349 in launchpad "Can't delete a product you created" [Medium,Confirmed] http://launchpad.net/bugs/38349 [03:41] mpt: sure. I'm just not sure why he felt the need to create two -- there are branches associated with both of them too [04:08] bradb! [04:09] mpt: hey [04:09] bradb, would you be able to spare a couple of hours to implement Malone-wide search for the Bugs front page? [04:09] (At least, sabdfl said it would take a couple of hours:-) [04:10] mpt: hrm, don't really have time for that until 1.0 tasks are finished, i think [04:10] bradb, it is one. [04:10] mpt: I mean this definition of 1.0: https://launchpad.net/products/malone/1.0/+specs [04:13] bradb, it's a requirement for the new Bugs front page, which is a requirement for the UI [04:13] I guess I'll talk with SteveA and kiko-zzz about getting some time allocated [04:13] sure === Fujitsu_ [n=Fujitsu@203.23.49.35] has joined #launchpad === ajmitch [n=ajmitch@ubuntu/member/ajmitch] has joined #launchpad === sevrin [n=sevrin@202.75.186.154] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad === stub [n=stub@ppp-58.8.2.238.revip2.asianet.co.th] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === AstralJava [n=jaska@cm-062-241-239-3.lohjanpuhelin.fi] has joined #launchpad [07:59] kiko-zzz: you undervalued yourself! http://digg.com/tech_deals/Kiko_s_258_100_Buyer_Revealed === mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #launchpad [08:16] morning [08:21] Morning [08:22] jamesh: I'll need to bounce demo.python.org soonish as I reshuffle files on Carbon [08:23] stub: okay. I need to do a code update on it too. Could you ping me when you're done? === carlos [n=carlos@203.Red-81-35-100.dynamicIP.rima-tde.net] has joined #launchpad [08:29] morning [08:29] When I start you mean - db needs to be shutdown before I shuffle files around or i will get rather confused ;) [08:30] jamesh: Do we have a startup/shutdown script anywhere? [08:31] stub: nope. I've just been using "make LPCONFIG=demo start" and "make LPCONFIG=demo stop" [08:32] Cool [08:34] jamesh: ok. I just shut it down. I'll sort the db stuff out now - you can do your code update now if you want. [08:38] carlos: Do you want a database for language packs rebuilt daily, weekly, on demand, or what? [08:38] stub: daily [08:38] but [08:38] I think I fixed the performance problem [08:39] so I'm not quite sure whether this is needed anymore... [08:39] I still want it off staging unless you think we can run it against the production server [08:39] we had a couple of crazy queries... [08:39] no, I don't think we should move it yet to production [08:39] I think we are near [08:39] but need to be completely sure [08:39] I think it would be a matter of a couple of weeks [08:39] asuka will be gaining load with edge.launchpad.net running on [08:40] ok [08:40] at least now, we have a load of 2 in asuka instead of 15 .... [08:41] I'm surprised PostgreSQL let it get that high - I haven't seen a single connection be able to abuse the db that much before [08:41] (I've only seen staging running at about a load of 6 with vacuum processes running as well as your script) [08:42] stub: well, it's just that we were executing a view with all rows for a single distrorelease [08:42] so I guess the amount of memory and CPU needed is huge [08:42] I don't know how could I be so stupid to do it... [08:42] I changed it with a couple of joins and now it's quite fast now [08:43] also, I did some other cleanups to reduce the amount of SQLObjects held in memory at the same time so we only fetch them when we really need them [08:43] stub: you have the changes in your review queue [08:43] ok [08:45] stub: in fact... the load of '2' is not due my language pack export but due some other commands in asuka [08:46] which is good [08:46] carlos: How much RAM do you think the script will need on the client side? I suspect it will be worth you getting an account on Carbon rather than running from mawson or sodium. [08:46] well, I think it usually gets between 100 and 150MB === ryanakca [n=ryan@unaffiliated/ryanakca] has joined #launchpad [08:47] I'm running it right now on mawson [08:47] let me check what's need now [08:47] stub: between 90 and 110 === stu1 [n=stub@ppp-58.8.3.24.revip2.asianet.co.th] has joined #launchpad === stu1 assumes MB [08:49] yeah [08:56] jamesh: db is back online [08:57] carlos: What time do you want the database rebuilt btw? [08:57] stub: If it's ready around 3 - 4 AM (London time) would be enough === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [09:08] jamesh: I've restarted demo with the existing code === Spads [n=crack@host-87-74-19-213.bulldogdsl.com] has joined #launchpad === Fujitsu_ [n=Fujitsu@c58-107-62-26.eburwd7.vic.optusnet.com.au] has joined #launchpad [09:44] danilos: morning dude [09:49] carlos: morning === Fujitsu_ is now known as Fujitsu === malcc [n=malcolm@host86-138-251-144.range86-138.btcentralplus.com] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [10:10] stub: I'm getting the following error on carbon: Ident authentication failed for user "postgres" [10:10] stub: are there some permissions settings you changed during the upgrade? === ryanakca [n=ryan@unaffiliated/ryanakca] has joined #launchpad === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [10:19] ddaa: thanks for your comments on my branch. [10:22] jamesh: you're welcome [10:22] re: your reply [10:23] mh... nevermind, I'll follow up by mail [10:24] I think it would be better to add the constraint between user_branch and import_branch, and keep the series_branch logic, but I do not remember why offhand [10:25] having importd set both has the benefit that the $series/+edit form shows the vcs-imports branch if it is the current series branch [10:26] which could reduce confusion [10:26] I think we get all the safety benefits by making importd work with its own branch attribute that users can't edit [10:27] carlos: can you rerun the query I gave you yesterday on staging? [10:27] sure [10:27] done [10:28] danilos: btw, meeting time? [10:28] carlos: sure [10:36] stub: ping? === mpt [n=mpt@203-167-187-121.dsl.clear.net.nz] has joined #launchpad === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #launchpad [10:41] hi SteveA === jinty [n=jinty@132.Red-83-55-196.dynamicIP.rima-tde.net] has joined #launchpad [10:56] Launchpad Apps Server [1/2] Librarian Demo server down. [10:56] stub, stevea : ^^ === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad [11:06] Znarl: thanks [11:06] stub: Is this part of your work on carbon? [11:06] morning [11:09] ddaa: hi, could you check why https://launchpad.net/products/elisa/trunk failed to mirror the branch? thanks. [11:10] ddaa: last month, they had some problems with their Subversion repository so perhaps that's the problem and a new run would fix it [11:10] Znarl: stub was changing some stuff with the database, and the permissions don't let me log in anymore. That's why the server is down [11:11] New bug: #59147 in soyuz "apt-ftparchive hanging" [Critical,Confirmed] http://launchpad.net/bugs/59147 === ddaa looks [11:11] ddaa: thanks [11:11] carlos: "OSError: [Errno 12] Cannot allocate memory" [11:12] in our side or in their side? [11:12] our side [11:12] cscvs is a fucking memory hog sometimes [11:12] I think that the 'Cannot allocate memory' is also the error they had [11:12] I see [11:12] it's _our_ problem, it happens when trying to fork to spawn gpg [11:14] carlos: I can add it to the VcsImportRequests wiki page, if you want me to tell you when it works (likely several weeks or months from now) [11:15] I see [11:17] ddaa: yes, please, add it there === carlos will use that page next time he adds a new import === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad [11:30] stub: hmm... A full language pack export is taking much more memory than what I told you. The process is finishing and it's using 450MB [11:32] stub: If that's a problem, I think we could improve it generating the tarball with all .po files exported using hard disk space instead of generate it in memory [11:33] carlos: Just means you will need a shell account on carbon (it has 32GB ram) [11:34] ok [11:35] ... [11:35] 32GiB!? That's impressive. [11:35] jamesh: you are rebuilding demo.launchpad.net at the moment? [11:36] stub: I did the code update and was going to run the db upgrade scripts, but the db permissions are busted (see above) [11:36] FATAL: Ident authentication failed for user "postgres" [11:36] bah === stub goes and fixes [11:36] maybe the admins can spare a few memory chips for importd slave [11:37] the have to deal with a meager 4GiB [11:37] jamesh: fixed === stub has his volume on now so might hear further pings === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #launchpad === Spads [n=crack@217.205.109.249] has joined #launchpad === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad === siretart [i=siretart@ubuntu/member/siretart] has left #launchpad [] === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad === netjoined: irc.freenode.net -> brown.freenode.net === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad === carlos [n=carlos@203.Red-81-35-100.dynamicIP.rima-tde.net] has joined #launchpad === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === pygi [n=pygi@89-172-196-68.adsl.net.t-com.hr] has joined #launchpad [12:35] hello, do we have two-ways sync for trac & malone? [12:37] hi pygi [12:38] hey BjornT :) [12:38] at the moment we don't have any sync between trac and malone, but we're planning on having one-way sync at least. [12:38] what kind of two-way sync are you looking for? [12:38] we don't have 2-way sync with anything [12:39] BjornT, well, if I submit bug to malone, I want it also appear on trac, comments, status and stuff [12:39] same thing vice-versa [12:40] mostly because I am developing libburn under trac as an upstream, but considering libburn will probably go in main for edgy+1 I would like to tie it more to Ubuntu [12:40] pygi: that is quite hard to do, since we can't update trac bugs without the approval of the bug tracker owner. [12:41] BjornT, I know, I'm the owner of that trac [12:41] pygi: if you want to watch malone bugs from trac, support should be added to trac that would pull the bug information from malone. [12:41] BjornT, right, so plugin development for trac [12:42] ok, thanks BjornT :) [12:43] np === siretart_ [i=siretart@tauware.de] has joined #launchpad === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad === MaSa69 [n=MaSa69@dsl-jklbrasgw1-fe1cfb00-100.dhcp.inet.fi] has joined #launchpad [01:06] stub: ping [01:10] New bug: #59154 in malone "Don't show all tags on the bug listing page" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59154 [01:15] New bug: #59157 in launchpad "Launchpad doesn't allow people to sort bugmail" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59157 [01:16] cprov: pong [01:16] stub: hi, have you looked in my email in LPML ? [01:17] LPML? [01:17] stub: stub.test_emails are gone when I use a customized setUp [01:17] I'm just answering that now actually [01:17] stub: sorry, LP maillisting [01:18] I didn't think stub.test_emails would work at all in the Zopeless environment so it was purely luck it was working before I think. [01:19] stub: really ? where do we controls which IMailer implementation to use ? [01:20] It is loaded via ZCML. I'm not sure which .zcml is used to bootstrap by execute_zcml_for_scripts(). I'm having a look. [01:20] It uses script.zcml [01:21] New bug: #59160 in malone "The open bug count for bug tags includes duplicate bugs" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59160 [01:21] stub: wow, just in my face ... [01:22] Adding '' to script.zcml might fix it, or it might cause more trouble. I'm not sure. [01:25] stub: I see, looks like people already test stuff relying in the current behaviour (no test_emails) [01:26] New bug: #59164 in malone "When confirming a new bug tag, the source package is mentioned instead of only the distribution" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59164 [01:28] stub: if that works (i.e no conflicts), wouldn't that mean that scripts would use the test mailer to send email? [01:31] New bug: #59165 in malone "When adding two new tags, confirming one tag actually confirms both" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59165 [01:33] BjornT: is that a problems for your tests ? I see that support-tracker-emailinterface.txt, for instance, doesn't expect it === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad [01:36] cprov: now, it's not a problem for the tests, no tests would break. it could be a problem for the real scripts, though [01:37] BjornT: I don't know what it would mean really. I've only ever used the ZCML mailer stuff in the Zope3 environment and never tried loading it in Zopeless to see if or how well it works. === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad [01:38] BjornT: It would be a simple modification though to make execute_zcml_for_scripts() load a different .zcml bootstrap instead of script.zcml that does this === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:40] Might be the best way of handling it if it works. It would be nice if scripts *could* use the same mail APIs as the appserver [01:41] the main issue would be that the mailer runs in a different thread [01:41] stub: agreed. it's something that i've been planning to do, but never got around doing. there's a bug open on this, i think. [01:41] so, we'd probably want a synchronous mailer, or to have an onexit handler that ensures all mail is sent [01:42] SteveA: There is both a queued and immediate delivery mechanism shipped with Z3 - it is selectable in the zcml [01:42] well... [01:42] we'd want it to be transactional too [01:42] is "immediate" transactional? === SteveA --> lunch === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad [01:47] SteveA: yes, the immediate mailer (DirectMailDelivery) is transactional === prayforwind [n=steve@74.12.97.224] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [01:50] G'Day people, stupid me... I've forgotten/lost my shipit.ubuntu.com login ID & password :( and per instructions there I'm asking here how to recover it (or do I just make a new one?) [01:52] prayforwind: https://launchpad.net/+forgottenpassword [01:52] prayforwind: you have a link to it from the login page you get in shipit.ubuntu.com [01:54] thanks carlos, but I seem to have forgotten my ID as well as my passwd [01:54] prayforwind: your id is your email address [01:55] it's not recognised [01:55] could you tell me it? === siretart_ is now known as siretart [01:56] carlos: steve at prayforwind dot com [01:57] hmm [01:57] prayforwind: would be possible that you used another email address the first time? === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:59] prayforwind: if you don't know or have another email address, create a new account, if you manage to find it later, you can merge the accounts [02:02] once I used hogtown.net at sympatico dot ca, changed it. Anyways, neither work. Was way back at first release I used it. (both addr still good). Possible it purged due inactive? Oh well, just as easy to fill in the form again (just so long as none of the good guys at ubuntu consider it an abuse). Would just download, but I want to distribute xubuntu CD's at LUG and I figure they'll look more "official" . Thanks [02:04] prayforwind: no, it's not an abuse, don't worry [02:04] we can merge accounts later [02:04] and as far as I know, we don't purge any account [02:05] Ok, thanks :) xubuntu just what I've been waiting for for some time BTW (love ubuntu, less fond of Gnome & KDE) === cprov is now known as cprov-out [02:06] :-) === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has joined #launchpad [02:08] later === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has left #launchpad [] [02:21] SteveA: immediate is 'on commit' [02:33] stub: is there any way to know if current load in asuka is due my language export script or the other process running there? === niemeyer [n=niemeyer@200.103.152.230] has joined #launchpad [02:35] carlos: Apart from what top tells you and seeing what queries are currently being executed, not really. But I'm no linux expert. [02:35] ok [02:36] well, as far as I know the load is high when other processes are running so I guess is not my fault... let see what happens when we move to carbon === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad === carlos -> lunch === cprov-out is now known as cprov === PingunZ [n=kristof@128.184-240-81.adsl-dyn.isp.belgacom.be] has joined #launchpad === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad [03:33] where can one read about LP xml-rpc? [03:34] pygi: http://help.launchpad.net/MaloneXMLRPC for malone specific xmlrpc [03:34] matsubara, thanks === lbm [n=lbm@82.192.173.92] has joined #launchpad [03:40] bradb: is there a way to search the bugs not containing a work to their title? [03:40] word [03:40] seb128: no, sorry. [03:40] is that planned? [03:41] or is it a way to search for all the bugs on a product not using a particular tag? [03:41] seb128: boolean ops are planned: https://launchpad.canonical.com/MaloneSearch [03:42] hum [03:42] ok, thank you [03:45] np [03:46] New bug: #59179 in launchpad-support-tracker ""Tickets involving Person" listing should be batched" [Medium,Confirmed] http://launchpad.net/bugs/59179 [03:50] New bug: #59180 in launchpad-support-tracker "Allow searching through a person tickets" [Low,Confirmed] http://launchpad.net/bugs/59180 [03:55] morning [04:00] kiko: morning [04:00] how's the surf? [04:08] Morning kiko [04:08] We've got an exciting new SQLObject-related bug today: https://launchpad.net/products/soyuz/+bug/59186 [04:08] malcc! [04:08] Malone bug 59186 in soyuz "buildd-queue-builder broken with odd SQLObject problems" [Critical,Confirmed] [04:08] malcc, on mawson? [04:08] kiko: Yup [04:08] malcc, okay. I can get you a patch for that [04:09] malcc, I knew this could bite us, btw. I had to fix it up for the tests.. [04:09] kiko: We haven't got any useful comparisons of publishing results yet, because the new code doesn't work yet, but it's at least getting a good workout === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has joined #launchpad [04:09] malcc, did my patch yesterday help you any? [04:09] kiko: Yes, the memory problem appears to be gone now, and all without any very big hammers [04:10] malcc, did you end up using my expire_from_cache call? [04:10] kiko: Indeed I did [04:10] and it worked? cool. [04:10] kiko: It seems to get the job done [04:10] I'm asking if it worked because SQLObject has a try: except KeyError: that could mask failures [04:10] so when you have a moment try pdbing into it and seeing if the object is actually getting del'd [04:11] anyway let me get a patch to fix that bug for you [04:11] kiko: Thanks [04:12] kiko: Is the Fridge story okay? [04:13] kiko: Without pdbing, I can see that your method is doing something much like clearing the cache, as another join traversal to the same object gives me a new id after calling clear_from_cache. === marcus_notebook [n=mholthau@86.84.84.9] has joined #launchpad [04:15] New bug: #59186 in soyuz "buildd-queue-builder broken with odd SQLObject problems" [Critical,Confirmed] http://launchpad.net/bugs/59186 === bradb gets brane sores reading stub's optimized SQL for the pending bugwatch query [04:16] stub: Can we try and fix this right now? I can give you the details in English. [04:17] I'm mainly a bit strained on exactly how to integrate the optimized query into the existing Python code. [04:21] malcc, perfect, then. thanks! [04:22] malcc, when you say "a new id" you mean "a new id()"? [04:22] matthewrevell, yes, perfect. owe you a beer [04:22] kiko: That too, but I meant a new 0x... in the thing [04:23] is the 0x not the id()? I think it is in C Python at least. [04:24] kiko: :) [04:24] kiko: Yes I think it is, just the hex version [04:24] malcc, a patch for your bug: [04:24] https://sodium.ubuntu.com/~andrew/paste/file1shIDr.html [04:27] malcc, I love this mawson test :) [04:27] kiko: To be fair, we haven't got any of the extra testing we're hoping for yet, we're just giving the code a good workout and shaking out obvious crashing errors [04:28] malcc, giving the code a good workout is probably 75% of what we need though [04:28] kiko: That's good too, and I've learned a lot about doing it, but this is something celso already knew how to do in the past, it's not new :) === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has left #launchpad [] [04:28] malcc, well, difference being that we now have a standard process for doing it before rollout, and that we /will/ eventually have a way to compare the results! [04:29] kiko: Yup, it's an improvement [04:29] malcc: I can die, you need to know how to drive soyuz too ;) [04:29] cprov: Yes, and I think 50% of the gain this last seven working days has been me learning to drive tests on mawson [04:30] cprov: But if it all works out, and we can compare the actual published archive from a new codeline with that from a trusted codeline on mawson, I'll be so much happier [04:30] kiko: I want to send a request for feedback on the support workflow spec to launchpad-users@, where can I put the UI mock ups so that they are accessible publically? [04:31] malcc: we will [04:31] kiko: So I'm reading your patch, and I can see that it'll work, as it changes to compare ids rather than objects... [04:31] kiko: But I'm still curious; do you have any idea why the object comparison has suddenly stopped working? [04:31] flacoste, people.ubuntu.com? [04:31] malcc, the old code didn't do set operations, did it? [04:31] kiko: i have an account there? [04:32] http://people.ubuntu.com/~flacoste/ => 404 [04:32] malcc: I suspect there is something related with comparing MultipleJoin crap agains SelectResults, but I'm not expert [04:32] can you ssh to it, flacoste [04:32] ? [04:33] indeed, i can [04:33] malcc, cprov is probably right in pointing out that MultipleJoins always refetch [04:33] flacoste, you're probably just missing a public_html dir then. [04:33] kiko: indeed, that worked! [04:34] sure it did [04:34] kiko, cprov: Ah I see. I didn't realise how much this code was changed when the files were reorganised [04:35] kiko: just a thought, I could not find the code ... anyway, they should share cache [04:35] malcc, the code was changed because, well, the existing code didn't validate the architectures properly. [04:36] cprov, funny thing is that it /used/ to share the cache [04:36] cprov, when they changed the MJ to return SelectResults however [04:36] since you need to hit the table to fetch the rows once anyway, they bring in the data and just instantiate [04:36] malcc: one thing is true, _archreleases is retarded and cause this issue, we should have a methods in IDR called getValidDARs() or so [04:37] kiko: So would it be fair to say that, as a general principle, one should never compare SQLObjects directly? If various issues cause them to not be the same object, and they don't compare equal, it seems unsafe [04:37] cprov, very good point. can you file a bug for IDR.getBuildableDARs or something? [04:37] malcc, it depends. if you do "foo is bar" then you're bound to run into problems. if you do "foo == bar" then __eq__ should DTRT. === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #launchpad [04:38] kiko: yup (good name suggestion) [04:39] kiko: Well it doesn't seem to, and things like set intersections work on equal rather than is [04:40] malcc, I'll look into it. [04:40] kiko: Thanks [04:40] malcc, did the patch work, btw? [04:45] kiko: Should do, I'm just tidying up another in-place hack I made so as to keep all the patches straight on mawson [04:46] ok cool. [04:46] flacoste, ping? [04:46] kiko: pong [04:46] carlos, danilos: ping? [04:46] kiko: pong [04:47] carlos, who's busier, you or danilo? [04:47] both [04:47] what do you need? [04:47] a fix for the NameNotAvailable bug, which crashed 11 times yesterday. [04:48] and a cherry-pick request [04:48] ok [04:48] thanks [04:48] I will do it, I started debugging that problem [04:48] so it should be easier for me [04:49] please help keep our oopses under 10 a day [04:49] ok [04:49] kiko: was soyuz-pas tag approved ? don't you think it fit better in soyuz-buildd ? [04:49] kiko: Can you peek at the email reply to stub's SQL optimization? My second reply, where I show how I integrated it. I can't tell if it will run fast, but maybe you can even run it on staging. [04:49] cprov, that's fine by me [04:49] bradb, if you give me a query in a pastebin I can run it on staging, sure. [04:50] kiko: ok, coming up [04:50] kiko: did you see my email about language packs? [04:51] kiko: what is fine ? keeping soyuz-pas or move them to soyuz-build ? you sounded confusing [04:51] cprov, moving them. [04:51] carlos, uhhh, which one? [04:51] kiko: right, thanks [04:51] kiko: the one about the performance fixes I already implemented [04:52] carlos, I saw that yes [04:52] carlos, I still think running this on asuka is wrong. [04:52] it's great if it's faster on carbon though :) [04:52] asuka shouldn't run any production-related tasks [04:52] kiko: we are going to move it to carbon anyway [04:52] carlos, I am your fan [04:52] kiko: but I think we are really close to be able to move it to production [04:53] bradb, you are forgetting to spam launchpad on the SQL thread :-( [04:53] kiko: because you give me fresh air? ;-) === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #launchpad [04:54] jamesh: btw, thanks for your review [04:54] carlos: no problem. Sorry for the delay [04:54] heh [04:54] jamesh: don't worry [04:54] kiko: i didn't intend to send to lp@, but i guess it wouldn't have hurt [04:55] New bug: #59193 in soyuz "IDistroRelease should provide a method to retrieve architectures available to build" [Medium,Confirmed] http://launchpad.net/bugs/59193 [04:55] kiko: https://devpad.canonical.com/~andrew/paste/fileYuSRa7.html [04:55] bradb, in doubt, CC: the list, because list archival and open information flow is a beautiful thing [04:55] jamesh: while trying to merge that branch, the new pqm-merge doesn't see the pqm_branch information because the push_location problem [04:56] kiko: ok, sure [04:56] jamesh: do you plan to migrate your fix from 0.8 branch? [04:56] carlos: yeah. Aaron didn't particularly like the solution I did for the 0.8 branch, and I thought they'd fixed the bzrlib config issue [04:57] carlos: I might look at fixing bzrlib ... [04:57] bradb, count [04:57] ------- [04:57] 93 [04:57] (1 row) [04:57] jamesh: ok [04:58] thanks [04:58] carlos: could probably do a 0.10 series of pqm-submit with the fix in though. [04:59] kiko: good, that means it's still correct. how long does it take, compared to (pastebin coming up...) [04:59] ok, in the mean time I'm removing the push location... it sucks, but works ;-) [04:59] I've also done up a "bzr repo-push" plugin to efficiently push an entire repo of branches to a remote location [04:59] at least we don't send a merge request to bzr.dev [04:59] kiko: https://devpad.canonical.com/~andrew/paste/fileQJI0RU.html [04:59] which uses the same public_repository setting as pqm-submit for the target [05:00] jamesh: from where do you execute the push ? [05:00] bradb, first query is Total runtime: 1524.561 ms [05:01] carlos: a branch in the repository (or a checkout of a branch in the repository) [05:01] bradb, second query is Total runtime: 956.729 ms [05:01] ugh [05:01] jamesh: ok, cool [05:01] life sucks [05:01] bradb, and then you die. my advice is keep nagging stub. [05:01] yeah. i'll see what he says about my replies. [05:02] there are a few XXX's related to locking, and the progress bars don't seem to show, but it works and won't wipe diverged branches [05:02] like rsync can === cprov is now known as cprov-lunch [05:05] kiko, I've answered your questions on PersonCreationRationale [05:05] I saw salgado [05:12] kiko: I strongly support any initiative to allow users to delete things from Launchpad. But branches are tricky because they are half db-based and half filesystem-based. [05:13] So deleting stuff _needs_ to be done carefully. [05:13] ddaa, okay. I guess I was just complaining about the issue that happens when first pushes fail -- a bug LarstiQ said he was going to fix moons ago! [05:13] kiko: Fix for ZeroDivisionError is the third pending request in PQM queue [05:14] speaking of which, I could use some feedback on an rfc I sent about that [05:14] flacoste, most appreciated. please email stub revision number CC: launchpad when it hits the ground [05:14] jamesh, ddaa: perhaps one of you could look at LarstiQ's RFC? [05:14] kiko: will do [05:15] ddaa: [RFC] Failing to push to existing non-branch directories. [05:16] LarstiQ: a _while_ ago? [05:16] it's from september 2nd [05:16] and still in my bzr backlog [05:16] which is currently at a months low with only 204 msg === LarstiQ nods [05:17] I got the impression you had a bit of backlog [05:18] I'll give due consideration as soon as I catch up with it [05:19] Now need to do something else than emails for a change. === ddaa workraves [05:28] so, the rollouts are now bi-weekly or weekly again? Do we have a date for the next one? [05:29] I hope they will be bi or tri-weekly [05:39] matsubara, I think you should write to SteveA, stub and ask. add my opinion for bonus points. === matsubara nods === lbm [n=lbm@cpe.atm2-0-75146.0x535a2f1e.vgnxx2.customer.tele.dk] has joined #launchpad === cprov-lunch is now known as cprov [06:10] matsubara: rollouts are every two weeks, unless specifically requested and agreed in the launchpad meeting. [06:11] matsubara: with some room for skipping a rollout if there's nothing important to do. [06:12] hehe thanks SteveA I just sent an email to the list asking :) [06:12] carlos: any progress on your import cherrypick request? [06:12] jordi: I got the review approval [06:12] it's in the queue [06:13] yay [06:13] hmm [06:13] failed [06:13] anyway, I guess stub will cherry pick it tomorrow [06:14] SteveA: actually I mailed you, kiko and stub and forgot to add the list [06:20] grrr, .css changes suck... [06:21] do you know that launchpad is broken to comment on bugs until you force a .css reload? [06:21] matsubara: I replied, including the list [06:22] SteveA: thanks === bradb & # lunch === lbm [n=lbm@cpe.atm2-0-75146.0x535a2f1e.vgnxx2.customer.tele.dk] has joined #launchpad [06:42] carlos: good time to restart firefox :) It's still a leaky bitch anyway. [06:42] well, I restarted it this morning [06:42] I turn off my computer every day [06:42] I think the cache is not discarded when you restart it [06:42] oh, that's so eighties! === rraphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === xenru [n=Miranda@85.192.12.43] has joined #launchpad === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #launchpad === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #launchpad === jinty [n=jinty@132.Red-83-55-196.dynamicIP.rima-tde.net] has joined #launchpad === rraphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === rraphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #launchpad === lbm [n=lbm@cpe.atm2-0-75146.0x535a2f1e.vgnxx2.customer.tele.dk] has joined #launchpad [08:15] carlos, around? [08:16] salgado: yes [08:16] hi [08:17] hi carlos. I was looking at the code that imports POFiles and POTemplates and found something that is looking weird to me. maybe I'm just missing something, so I preferred to bother you here. :) [08:17] sure [08:17] tell me [08:17] carlos, do you have a few minutes to check that with me? [08:17] yeah, tell me [08:18] kiko-fud: rolled out importd and kicked production imports. Bug 37897 is phasing out into history. [08:18] Malone bug 37897 in launchpad-bazaar "renaming project, product or series breaks vcs imports" [High,In progress] http://launchpad.net/bugs/37897 [08:18] carlos, https://devpad.canonical.com/~andrew/paste/file2kvYfq.html [08:18] on the last line, there's a "is_editor = pofile.canEditTranslations(importer)" [08:19] but then later, this is_editor flag is only used in conjunction with last_translator [08:19] is it browser/pofile.py? [08:19] and the importer is never used again [08:20] components/poimport.py [08:20] function import_po() [08:21] salgado: what's wrong with that? [08:21] last_translator is the one that gets credit for the translations [08:21] kiko-fud: mh... just remembered that because of buildbot limitations, renaming things is still going to be a bit breakage prone (basically until we switch away from buildbot or add a specific hack), but less so. [08:21] salgado: importer is the one that should have rights to do such changes in Rosetta [08:21] but he doesn't need to be the author of the translations [08:22] The issue is that there will still be a race condition when reloading the botmaster while an import for a renaming series is running. [08:22] if we are not able to get last_translator from the .po file, we set the importer as such author [08:22] salgado: what do you see wrong there? [08:22] then buildbot loose track of the running jobs, and will happily start the same import again, causing concurrent access [08:23] carlos, right, but if you get the last_translator, it may be different than the importer? [08:23] salgado: yes [08:23] it usually happens with Ubuntu automatic imports [08:23] salgado: rosetta-admins is the importer but any other guy could be last translator [08:24] so we don't remove the credit of those translations from upstream [08:24] and then on updateTranslationSet(last_translator, force_edition_rights=is_editor), aren't you giving the importer's rights to the last translator? [08:25] salgado: yeah, so he gets the credit for those translations and his translations are actually used by default instead of just a suggestion from someone without permissions [08:25] s/a/as/ === j-a-meinel [n=j-a-mein@adsl-67-37-177-94.dsl.chcgil.ameritech.net] has joined #launchpad [08:27] salgado: the system is quite complex, so it's normal if you are a bit confused... [08:28] ah, I see. that brought my attention because it wasn't clear that it's intended to use the importer's rights [08:28] hmm, could you file a bug about it so I improve the comments there? [08:28] assign it to me, please [08:28] maybe if that "is_editor = pofile.canEditTranslations(importer)" line was closer to where it's actually used, with a comment explaining why it is done this way, it could be easier to understand [08:29] well, I think I can do it now, if you don't mind [08:29] hmm === Spads [n=crack@host-87-74-19-213.bulldogdsl.com] has joined #launchpad [08:29] well, the thing is that then, you will need to check again whether the context is an IPOFile [08:30] ah, right [08:30] then forget about moving it from where it is [08:30] kiko-fud: bug 59227 [08:30] Malone bug 59227 in launchpad-bazaar "importd race condition when renaming import" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59227 [08:30] I guess just the comment would be okay [08:30] ok [08:31] carlos, btw, since I already bugged you, what table can reference the last_translator after an import is finished? === Spads [n=crack@host-87-74-19-213.bulldogdsl.com] has joined #launchpad [08:32] POFile.header has that info, but without being parsed, just as a string [08:32] we also have POSubmission.person per string [08:33] ah, right. I guess this is the one I wanted [08:33] salgado: what are you trying to do? [08:33] carlos, let me explain to you what I'm trying to do [08:33] ooops [08:33] :-D [08:34] I'll write a script to try and guess why some existing accounts were created [08:34] ok, then POSubmission.person is what you need [08:34] I'll do that for unvalidated accounts, and I was thinking about looking on some key tables searching for references to these accounts [08:34] we create accounts while importing .po files if the email address doesn't exists yet in launchpad [08:35] we have a bunch of them [08:35] exactly... that's how I reached this code path [08:35] are there any other places where rosetta creates person entries? [08:35] New bug: #59227 in launchpad-bazaar "importd race condition when renaming import" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59227 [08:35] I don't think so [08:35] salgado: just when we import .po files [08:36] right. thanks for the info, carlos. :) [08:36] salgado: you are welcome === carlos -> out [08:52] see you! === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad === ddaa starts on removing Arch support [09:28] where should I start... === ddaa contemplates the Gordian Knot [09:30] first, tweak importd so it does not use arch name for working dirs, so I can remove fix the corresponding test, so I can remove the Arch-based test helpers and stuff in importd, so I can remove the cscvs support... [09:38] Then remove arch stuff from content classes, interfaces, etc [09:39] finally, database patch === belito [n=user@190.40.169.65] has joined #launchpad [09:43] ddaa: sounds practically trivial :) [09:46] I think once I'll be started it will be easy, but there are some things to untangle in the importd test suite... === stub [n=stub@ppp-58.8.5.212.revip2.asianet.co.th] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [09:59] ddaa, thanks. [10:00] kiko-fud: give me four hands, two heads, and a caffeine drip, and it's fixed next month === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #launchpad [10:00] ddaa, let's leave you human for now, it is going to be less shocking at conferences [10:01] then it's YOUR choice! === bradb gets 25 failures from pqm === lbm_ [n=lbm@cpe.atm2-0-75146.0x535a2f1e.vgnxx2.customer.tele.dk] has joined #launchpad [10:02] *only* 25 === Kuhrscher [n=jannick@88.134.176.136] has joined #launchpad [10:06] New bug: #59241 in launchpad "We need a helper function extract text from HTML" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59241 === belito [n=user@190.40.169.65] has joined #launchpad === Flex` [n=Flexiuz@lan-84-240-51-181.vln.skynet.lt] has joined #launchpad === matsubara imagines ddaa looking like Zaphod Beeblebrox... [10:30] staaaaaaaagiiiing [10:30] caaaarlooos [10:30] hmm [10:30] it's all under control [10:30] it's salgado's fault! [10:30] under matsubara's control === bradb sees blame fly through the air === doko_ [n=doko@dslb-088-073-068-115.pools.arcor-ip.net] has joined #launchpad [10:38] carlos [10:38] gah [10:40] matsubara: in my very early BBS day, that was my screen name :) [10:40] until people convinced me that was a really ugly nick :) [10:41] okay, I'm done for today [10:55] New bug: #59249 in launchpad-bazaar "Edit branch details form need input validation for non-existent product" [High,Confirmed] http://launchpad.net/bugs/59249 === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has left #launchpad ["wth] === mvo [n=egon@p54A6701C.dip.t-dialin.net] has joined #launchpad === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad === carlos [n=carlos@203.Red-81-35-100.dynamicIP.rima-tde.net] has joined #launchpad [11:22] matsubara: hi, around? [11:22] carlos: yes, but I'll need to leave for about 20 min in 10 min. [11:22] matsubara: well, I only need to ask you whether is possible to close your connection from mawson to asuka's database [11:23] carlos: I'm running a query on staging's DB for salgado. [11:23] I'm doing a code update and it's stalled due your connection [11:23] I see [11:23] do you know if it will need much more time? [11:24] carlos: no idea. I'll cancel and salgado and I can sort that on Monday. [11:24] no, don't worry [11:24] I can leave this until tomorrow [11:24] carlos: done already [11:24] oh, ok... [11:24] go ahead, staging is all yours :) [11:25] it's already done === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [11:25] the process was stalled [11:25] and it finished as soon as you cancelled it [11:26] matsubara: so you can execute it again if you want [11:26] I'm done with staging's updates [11:27] carlos: ok, thanks. I'll leave this for monday. I don't think it's high priority. at least salgado said nothing about it. [11:27] ok [11:27] need to go. bbl === jinty [n=jinty@132.Red-83-55-196.dynamicIP.rima-tde.net] has joined #launchpad === cprov is now known as cprov-afk === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has left #launchpad ["Bye"]