[00:01] hm [00:02] Should I get reject emails if someone signs+uploads a package to their PPA but leaves me in Changed-By? [00:02] I don't think so. [00:03] Unless you have upload privileges to that PPA, I think. [00:03] http://dpaste.com/116006/ [00:03] I think that's what happened here? [00:04] * wgrant checks the code. [00:06] Hm. [00:06] It should only email changed-by or maintainer if the upload was not to a PPA. [00:06] Any idea to where it was uploaded? [00:07] all I have is this email [00:07] You are receiving this email because you are the uploader, maintainer or [00:07] signer of the above package. [00:08] .ckear [00:08] I wonder if it was in fact uploaded to the primary archive. [00:09] those mails come from "Ubuntu Installer" [00:09] Might of been aiming for http://tinyurl.com/yjphghl . [00:10] I reckon so [00:10] Laney: They should, yes. But if the uploader uploaded to ppa.launchpad.net/ubuntu, it will be from Launchpad PPA [00:11] I would file a bug, since there are no Soyuz people around at the moment. [00:11] Give the full email there, ideally including the headers and rationale. [00:12] There's a bug somewhere, but it's unclear exactly where without logs. [02:10] Can someone help? Why can I not upload binary packages to a PPA??? [02:10] blackh: Why would you want to, when Launchpad will build them itself? [02:11] There is a good reason to disallow it: if Launchpad builds all the binaries itself, I can be sure that the binaries are built from the sources that I see. [02:11] If you upload binaries that you build yourself, I cannot trust them. [02:12] wgrant: OK - I see. But not very helpful for me. I've already built my packages and there was some trickery due to a package with the same name in the standard builds. I would need to go through all the same suffering over again (only on an unfamiliar environment) to get launchpad to build them. [02:12] blackh: Do you not have a source package that you can easily build the binaries from? [02:15] I have the source packages... but if you build them "straight", builddep gets the wrong version of ghc. I could fix it by hacking them all to refer to more specific versions... so basically I need to figure out whether I should do this, or whether I should give up and host them myself. [02:15] You should really fix the source packages, or they're not useful for anytbody else. [02:15] The point of a source package is to directly build the binaries easily. [02:15] One of the packages builds ghc-6.10.4-1, and the standard packages for karmic have ghc-6.10.4-ubuntu2 (iirc) [02:15] These are just grabbed from Debian. [02:16] "One of the packages" being a new version of ghc? [02:16] So you need a newer version of ghc? [02:16] Yes.... 78 packages in all [02:16] If you upload the new version of ghc first and wait for it to build, all the subsequent builds will use that version of ghc. [02:17] Ah - that could be my solution, then. [02:18] Builds are pretty slow at the moment, because most of the build machines are currently serving Ubuntu downloads because of the release of 9.10. [02:18] But they should speed up soon. [02:20] wgrant: Your help is very much appreciated - thanks. [02:20] np [02:29] what happens if I delete a translation branch which is target for the automatic exports? [02:31] I want to delete it because I don't let the translations get into trunk automatically, I have an extra branch to analyse the work first, then commit it to the main line [02:32] well, never mind. I think I don't need export branches [02:43] If there any experts here this evening, I have a question related to ssh keys for a launchpad intergration project. [02:43] !ask | doctormo [02:43] doctormo: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) [02:43] Is it possible to have more than one ssh key? how are they aranged? what is the difference between a key in id_rsa and id_dsa? [02:44] certainly possible to have more than one [02:45] The reason is that if I want to automated the creation of ssh keys for launchpad use, I don't want to squash existing keys and I want it to play nice. [02:45] the difference between them is the algorithm used to generate it [02:45] ajmitch: No practical reasons? no different uses for each one? [02:45] In Launchpad (as with a normal authorized_keys file), you just add new keys separated by line breaks. [02:45] You should probably use RSA keys now. [02:45] you can read up on the differences if you want, I can't remember which one is recommended (RSA i think) [02:45] DSA is losing favour. [02:46] you can also tell your ssh client to use specific keys to connect to various hosts [02:46] wgrant: Right, on the persons machine can I do that in id_rsa too? just add a new line to indicate a new private key? [02:47] I don't think so. [02:48] id_rsa is just the default name [02:48] you can have them named something else [02:48] id_rsa_key_for_silly_launchpad_stuff [02:49] & then use the IdentityFile option in the ~/.ssh/config to use that for launchpad hosts [02:52] ajmitch: Sounds like the perfect plan to make sure there are no conflicts, offer the use the choice to use an existing key, or make a special one that won't conflict later. [02:52] thanks guys [02:53] I hope it works out [02:53] whatever you're trying to do there :) [02:58] does the loggerhead support for tags include tag urls? [03:00] RenatoSilva: no === jon is now known as Guest73252 [03:09] ok, bug 473691 [03:09] Launchpad bug 473691 in loggerhead "Tag urls" [Undecided,New] https://launchpad.net/bugs/473691 [03:18] is there any work for supporting download urls in Loggerhead? [03:19] The web ui for hg has this, so you can download a .zip for the branch easily, including tags, for example http://server/project/tip/download [03:20] Not off the top of my head, but it might not be hard to add, depending on what exactly you want. [03:20] download a tree [03:20] (I'm not an expert in hacking on loggerhead, though, so I might be wildly underestimating the difficulty) [03:20] currently, we need to bzr branch it [03:21] someone worked on that a bit i think [03:21] What do you mean by "a tree"? The obvious meaning I can think of doesn't make sense with your "including tags" request. [03:21] I think bug 246764 is what I want. Unfortunately the work is abandoned :( [03:21] Launchpad bug 246764 in loggerhead "Recreate "Download a Directory" feature" [Wishlist,Triaged] https://launchpad.net/bugs/246764 [03:22] spiv: forget about the tags, it's a separate bug [03:22] Ok [03:23] spiv: I want something like this: http://www.sheep.art.pl/devel/mandarin/archive/tip.zip [03:23] So basically you want a way for loggerhead to generate a "bzr export" for you. [03:23] * spiv nods [03:23] That would be the bug/feature mwhudson just mentioned [03:24] spiv: it's not a static tip.zip, it's a tag tip (or default tag meaning the last rev), and an instruction to get the branch as zip [03:24] Yes, understood. [03:25] Until someone implements it natively in loggerhead, the simplest workaround I can think of would be a cronjob that runs "bzr export" and puts the zip file somewhere HTTP accessible. Not sure how you'd then make that file easily discoverable from loggerhead, I don't know much about customising it. [03:25] you mean the bug /I/ mentioned? [03:25] Oh, sorry, yes. [03:26] ok, I'll just subscribe and `affects me too`then [03:57] spiv: it was implemented in loggerhead [03:57] spiv: its disabled on lp [03:58] for reasons of fear [03:58] so the bug info is outdated [03:59] fear of badwidth overhead? [03:59] oh, the per-directory export bug? Not sure if that feature got completed; I did the work in bzrlib to permit loggerhead to do it [04:02] is it available in bzr? bzr export does not support specific directories right? [04:02] yes it does [04:03] can't find in the help, let me see [04:06] ok, so the sub-dir thing is what you has implemented right? So it just needs to have a link in the loggerhead ui, right [04:07] it would not be that hard as bzr already has the feature === doctormo_ is now known as doctormo === vorian is now known as v === v is now known as vorian [05:51] 503 Service Unavailable [05:51] No server is available to handle this request. [05:51] hurray! [05:52] Is https://login.launchpad.net/+openid down? [05:52] WFM [05:54] wgrant: musta just hated me for a couple minutes [09:32] ok, so the estimated build time for a package in my ppa is now 31 hours. [09:32] :( [09:40] It would be nice if one of the lpia builders could be reassigned to i386 :( [10:03] losa: can we do wgrant's suggestion above - given the backlog of i386 builds? [10:03] noodles775: we'd need to confirm with the soyuz devs and/or ubuntu osa (lamont) [10:09] noodles775: It's difficult -- it would need a change in the image :( [10:10] Yeah, we need to hassle IS to get back all the normal ppa builders. bigjools is trying to do so. [10:10] Even just one or two extra on i386 would make things muuuch better. [10:17] can i run my own launchpad server internally? [10:18] fwest: Annoyingly, no, not without an awful lot of effort. [10:18] oh shame [10:18] The Launchpad licence for the *code* is opensource. The images&icons, however, are not [10:19] So basically, the first thing you would have to do is replace all of the visual branding with your own unencumbered version [10:20] would be an opportunity to improve the css though ;) [10:20] <\sh> moins [10:20] Is launchpad a tm too? === henninge is now known as henninge-bbl [10:21] <\sh> guys, why is Lucid Lynx not shown on the overview page of a package in ubuntu? [10:21] exact link please [10:22] <\sh> maxb, https://launchpad.net/ubuntu/+source/zend-framework (see #u-m) === micahg1 is now known as micahg [10:53] \sh: scroll down [10:55] <\sh> Laney, yeah saw it...will this be fixed somehow? [10:57] Bug 464014 [10:57] Launchpad bug 464014 in launchpad-registry "DistributionSourcePackageView.active_series sorts versions as strings" [High,Triaged] https://launchpad.net/bugs/464014 [10:57] (targetted to LP 3.1.11, 2009-12-05) [10:57] are the i386 virtual builders backed up? [10:57] (delayed I mean) [10:58] https://launchpad.net/builders [10:58] They've been stolen as release mirrors. [10:58] bah === henninge-bbl is now known as henninge === salgado-afk is now known as salgado [12:09] wgrant: just curious, will your source v3 format branch go live with tomorrow's launchpad upgrade? [12:12] siretart: No. Depending on how rapidly Debian adopts the new formats, it may be cherrypicked before 3.1.11, but it may not. [12:13] wgrant: the new formats are being accepted since a few days for unstable. I see a lot of package with this format being uploaded the last few days [12:13] and I expect more and more DDs to switch [12:14] siretart: There were only ~15 yesterday, but that number is rapidly ascending. I am watching closely, and I'm sure the distro team will poke if it becomes too critical. [12:14] ok [12:14] The LP code is done, but there are buildd changes required which I intend to discuss tomorrow morning. [12:15] I was considering switching myself, but I'm not even sure how merge debian changes if I did [12:15] ok, thanks a lot for your work on this! [12:15] np [12:17] wgrant: other question: how difficult would it be to setup an launchpad instance that accepts and autobuilds packages packages for debian? - in essence, a private debian PPA? [12:18] compared to setting up e.g. a dak/wanna-build/buildd instance [12:19] I've seen no feedback what-so-ever on bug 435857 [12:19] Launchpad bug 435857 in launchpad "CSS bug with Firefox on Windows XP" [Undecided,New] https://launchpad.net/bugs/435857 [12:19] Are CSS bugs low priority or are devs unable to reproduce or want more info? [12:19] siretart: While I've tried a few times, I've never succeeded in setting up dak/wanna-build/buildd. LP took me just few hours to work out and document. So it's pretty easy. [12:21] siretart: Although using an external non-Soyuzish archive like Debian is rather hackish, it works. [12:25] http://williamgrant.id.au/f/1/2009/running-soyuz.html, if you are sufficiently brave/stupid. [12:30] wgrant: what will happen if we try and autosync packages in the new format? [12:30] james_w: BOOM! [12:31] oh [12:31] yay [12:31] james_w: In other words, the autosyncer will crash, and you'll need to blacklist the package to get it working again. [12:31] that will be fun on Monday [12:31] I wonder if I can get the trivial fix to make it just reject them into the reroll. [12:31] bigjools: ^^ one-liner in dak_utils.py fixes autosyncer crash. Would be nice to have. [12:34] wgrant: sure, send in an MP and I'll make sure it gets in [12:35] bigjools: Will do. Not sure exactly how the reroll works. [12:35] no different from normal really, except we don't take anything down [12:35] (unless necessary) [12:37] bigjools: So it's a full rollout across everything? [12:38] wgrant: AFAIK it's just to stuff that needs it [12:38] bigjools: Ah. [12:38] but the losas can tell you more [12:39] I doubt there are any tests for this (it is semicoloned Python imported from dak, used only by sync-source.py). :( [12:40] if there are tests for it I'll be surprised [12:41] Also, tabs. Ew. [12:43] wgrant: looks interesting. thanks for the link! [12:45] siretart: It's much easier now than when I started, since the dev keyserver is more helpful and rocketfuel-setup does a lot more of the Soyuz configuration. But lp-buildd still needs a few manual changes. [12:48] wgrant: thanks [12:48] wgrant: ok, I guess it might indeed be worth to have a closer look [12:48] Is the code in lp_archive@cocoplum:~/syncs/flush-syncs available somewhere? Would be nice to just see how it will handle rejections. [12:49] an archive admin should be able to help you [12:50] james_w: ^^? [12:50] it runs ~/sync-queue/process-incoming.sh [12:51] and dies if that fails [12:51] there's also find ~lp_archive/syncs/ -name '*.gz' -o -name '*.dsc' -o -name '*.changes' > ~lp_archive/syncs/flush-syncs-list [12:51] I don't think that needs adjusting for any new extensions? [12:51] Argh. That'll need fixing too. [12:51] It needs *.bz2. [12:53] and process-incoming.sh runs process-upload.py -d ubuntu -C sync [12:53] stop me if you have these scripts [12:53] I don't. [12:53] Well, I have process-upload.py [12:53] cool [12:53] if a shell script isn't -e [12:53] is it's exit code always 0, or the exit code of the last thing that it runs? [12:55] I don't think process-upload.py will return a failure code just because it rejects an upload. [12:55] the latter [12:55] so yeah, all this depends on how process-upload.py handles the rejections [12:58] and we have possibly similar issues with backports [12:58] I guess we can't backport newer source formats? [12:59] Technically you could take them back to Karmic, but you'd have to convince somebody to enable the new format there. I don't think dpkg in <= Jaunty will like the new formats much. [13:00] I'm not sure how backport-source.py works, as it's not in the tree, but I think I saw it in some ubuntu-archive branch somewhere. [13:01] ubuntu-archive-tools [13:01] Is it possible to have a PPA build rescored? I'd appreciate gtk2hs/i386 on ~laney/ppa being bumped up some if so... trying to fix a build failure that seems to not happen locally. [13:01] but I don't know if the meat is there or on cocoplum [13:01] Laney: it is, those with usual buildd powers can do it for PPAs as well [13:01] oh sexy [13:04] james_w: flush-backports is similar to flush-syncs? [13:06] wgrant: pretty much identical [13:07] james_w: OK. process-upload.py returns 0 even if an upload was rejected, so it should be fine. [13:07] just uses a different directory to pull the source packages from [13:07] that's fine [13:07] I was more worried that it would stop at the first rejection [13:07] Oh, no, it's not that crazy. [13:07] ace [13:07] thanks for checking [13:08] So, your tools should be fine once Soyuz gets v3 support, as long as bz2 is added as an extension to match. [13:08] I can make the same modification to flush-backports as the archive will reject any new formats? [13:08] Right. [13:08] yeah, I just added it to flush-syncs [13:08] I'll add it to flush-backports [13:08] thanks [13:08] Now I just have to work out how the heck the buildds are going to work. === danilo_ is now known as danilos [13:12] Laney: give me the build URL and I'll rescore it [13:12] james_w: did you request some sessions for us at UDS to talk about Build From Branch? [13:12] thanks bigjools, it's https://launchpad.net/~laney/+archive/ppa/+build/1319012 [13:12] bigjools: haven't yet [13:13] Laney: done [13:13] thanks [13:13] hopefull I won't have to hassle again ;) [13:13] good :) [13:13] stupid non reproducible problems [13:13] james_w: ok, or I can do it, but I don't know where to go :) [13:16] bigjools: nope, I'll speak to robbie [13:16] cool thanks === abentley1 is now known as abentley === salgado is now known as salgado-lunch [15:04] hey folks, I'm trying to propose a branch for merging against karmic-proposed and I entered "ubuntu/karmic-proposed/checkbox" in the target branch, but I get the error "invalid value" === oubiwann_ is now known as oubiwann === matsubara is now known as matsubara-lunch [15:59] jml: does +branch work over bzr+ssh? [16:04] james_w, no. there's an open bug for making it do so, though [16:04] james_w, simple matter of programming [16:04] ok, thanks === danilo_ is now known as danilos === welten is now known as welterde === salgado-lunch is now known as salgado === EdwinGrubbs is now known as Edwin-lunch [16:57] the iridium ppa builder seems stuck (it has been building openclipart for over 2 days) can someone look into this? https://launchpad.net/builders/iridium [16:58] colin watson is building it but cant' look at it right now and asked me to mention it here [17:02] ScottL_: I think the builders are currently reassigned as release mirrors === matsubara-lunch is now known as matsubara [17:05] Meths: but it's been building for over 2 days on the same build - it looks like an error in the build log [17:11] ScottL_: Agreed, looks broke in the logs. [17:12] Looks like they're back building too. [17:17] i'm setting up translation for a project, i see some templates in import queue (https://translations.launchpad.net/eventum/+imports), what (who) should approve these? project manager? launchpad manager? [17:17] from dropdown i can only choose between "deleted" and "needs review" [17:20] glen: approval of translations happens automatically if the files can be associated with a template and a language [17:21] Meths: Is there someone I should mention this to directly? to try to get it fixed? [17:21] henninge_: how do i associate the translation with template(pot?)+language? [17:22] glen: template: same directory as the template [17:22] glen: language: file name is a valid language code [17:22] glen: your files look good on both counts [17:23] glen: so just be patient, it may take a few hours as the approval script is often very busy === deryck is now known as deryck[lunch] [17:23] same goes for the import script ... ;) [17:23] ah. that could explain things [17:25] ScottL_: Sorry, don't know. You could try sending an email to the buildd admins. [17:29] Meths: ah, I did that already :( well, I tried, it will get fixed at some point [17:33] Any chance more i386 PPA builders could be brought online? [17:33] * kb9vqf notes the queue is at 44 HOURS! [17:33] ;) [17:37] kb9vqf: one of the builders (iridium) appears to be stuck, which is backing up the queue [17:38] OK, just wanted to let someone know [17:40] kb9vqf: that's why I'm here too ;) [17:40] :) [17:41] A user wanted knetstats-kde3...hopefully he'll have it before the weekend === flacoste is now known as flacoste_lunch [17:50] hi everyone, marjo needs the right permissions to be able to approve blueprints for the uds-l sprint [17:51] currently the qa folks are submitting blueprints but marjo can't approve them [17:57] Hi I'm consistently getting an internal error when I submit something on this page: https://bugs.launchpad.net/ubuntu/+filebug/?no-redirect [17:58] We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience. [17:58] Trying again in a couple of minutes might work. [17:58] (Error ID: OOPS-1404B2436) [17:58] https://lp-oops.canonical.com/oops.py/?oopsid=1404B2436 [17:59] have I understood correctly, that Ubuntu on launchpad no longer wants usability bug reports? [17:59] it also says I'm a member of the ubuntu beta testers team and that the edge server sucks, but the "disable redirection" button doesn't seem to work [18:00] * Meths is having probs reaching bazaar. too. [18:01] for instance. It hit me that the first time a user launches Transmission without a torrent file argument (that is, launches it from the menu), it should popup a welcome dialog explaning that Firefox already is configured to use Transmission for downloading torrents. That's not a Transmission bug, I think. It's a distro bug. and it's not a "problem" to be reported, it's just a usability issue. How am I supposed to report that now? [18:01] XiXaQ: file something at https://bugs.launchpad.net/ubuntu/+filebug/?no-redirect ? [18:02] avar, ok, I got the impression that the point was to discourage people from filing non-crash bugs? [18:04] XiXaQ: Dunno, just try [18:06] ok, thanks. [18:08] can someone help me sort out marjo's blueprint permission thing? It's blocking the QA team from adding sessions for UDS === bernie is now known as _bernie [18:21] jml, could you point me in the right direction perhaps? [18:33] jcastro, what's up? [18:33] rockstar, ~marjo-mercado needs to be able to approve/decline blueprints for the uds-l sprint [18:33] I don't know if he's supposed to be in a certain group or ... ? [18:34] sinzui, ^^ [18:35] jcastro: I suspect that marjo-mercado must be a driver for something [18:35] * sinzui needs to read code to know what something is [18:36] sinzui, aha! maybe "UDS Organizers" [18:36] * jcastro goes off to try [18:38] jcastro: I think you are right === danilos is now known as danilo-afk === deryck[lunch] is now known as deryck === dpm is now known as dpm-afk === flacoste_lunch is now known as flacoste === sale_ is now known as sale [20:13] the Debian import seems to be quite out of date [20:13] is it generally unreliable? [20:13] it doesn't seem to be as reliable as I would like [20:19] james_w: can you ping a losa about it [20:21] mbarnett: hi, would you be able to check that the Debian import is running for us? === salgado is now known as salgado-afk [20:22] james_w: sure, give me a few minutes.. have to wrap up some deploy tasks then i can take a look.. (i might have to hit you up for more info at that point as well) .. [20:23] I'm trying to find some indication of what the "Debian import" actually is in anticipation of that ;-) [20:24] mbarnett, james_w: it's "gina" [20:24] runs on iron.c.c [20:24] aha! [20:25] I tried to think of a package that would have been imported in the last few days, and went for a v3.0 one as that's only been in the last week [20:25] that package certainly won't be up to date [20:25] is it possible that gina stops as soon as it hits one? [20:32] ok, it's not as bad as I thought [20:33] it looks to be up to date as of about 20 hours ago, except for new source format packages [20:33] bigjools: is it run from cron? [20:33] yes, twice a day IIRC [20:34] wgrant found the problem with v3 packages, I think he has a fix ready [20:34] cool [20:34] any chance we could crank that to four times a day? [20:34] not sure if it blocks the whole run or just that package [20:34] since Debian has 4xdinstall a day now [20:34] oh yes in that case we should do that [20:35] let me get you the times [20:35] http://lists.debian.org/debian-devel/2008/12/msg00955.html [20:37] cheers [20:38] bigjools: would you like a bug for this or similar? [20:39] james_w: I verified last night that gina will just skip v3 packages, and I know how to fix it. [20:39] However I can't fix it until most of the rest of LP supports v3. [20:40] wgrant: thanks for looking at it [20:40] james_w: I just need to file an RT about it, will sort it tomorrow [20:40] thanks [20:41] mbarnett: thanks, but it seems to be running fine, so we don't need the check now. [20:41] james_w: yay! [20:42] gina is bug-free (according to kiko) :) === matsubara is now known as matsubara-afk === micahg1 is now known as micahg === lionel_ is now known as lionel [21:24] in a ppa/+packages page, when i try to unfold a release to see the details, most of the time, it jumps to a +listing-archive-extra page with no css :( === EdwinGrubbs2 is now known as EdwinGrubbs === thunderstruck is now known as gnomefreak [22:21] OOPS-1404D3213 [22:21] https://lp-oops.canonical.com/oops.py/?oopsid=1404D3213 [22:24] am I reading it wrong, or is that reporting lots of repeated SQL statements? ^ [22:28] james_w, you are reading it correctly [22:29] any idea why that might be happening? [22:35] james_w, badly written code [22:35] james_w, it's not infinite repetition [22:35] james_w, if you look carefully, you'll see the '%s' -- that's probably substituted with a different value each time [22:36] james_w, ORMs make it really, really easy to write code like 'for x in xs: x.doExpensiveQuery()' [22:36] I'm calling this over the API [22:36] is it my code that's wrong? [22:37] I guess not as it wouldn't be one GET then [22:37] james_w, right, that's my impression === Philip6 is now known as Philip5 [22:38] I'm not sure what would have changed here [22:38] james_w, what are you GETting? [22:38] What's the request? [22:38] james_w, distro_series=https%3A%2F%2Fapi.launchpad.net%2Fbeta%2Fubuntu%2Flucid&status=Published&ws.op=getPublishedSources&ws.start=1950&ws.size=75 [22:39] on /beta/ubuntu/+archive/primary [22:39] * jml looks up the implementation for getPublishedSources [22:39] ah, request variables, neat [22:40] james_w, some problems we nailed years ago :) [22:47] james_w, this is not a post-pint function [22:47] at least, not for reading. [22:47] heh [22:48] well, it's not explicitly adding that %s [22:49] 42 select person.* from person where id = %s should really not take 8 seconds [22:49] yeah [22:49] and why are they repeated through the query log as well [22:49] ? [22:49] james_w, the %s is something the OOPS log does [22:49] james_w, I think [22:50] or something [22:50] it's almost like I'm pipelining multiple queries in to one GET [22:50] james_w, are you looping calls to getPublishedSources? [22:50] yes [22:51] partitioning on distro_series so that it doesn't timeout ironically [22:51] intriguing [22:51] http://paste.ubuntu.com/309984/ [22:53] sounds like the implementation of getPublishedSources isn't very good [22:54] It looks fine. [22:54] james_w, icommon.lp_call? [22:54] heh [22:55] or maybe something lazr.restful is made of crack [22:55] james_w, what is that? [22:55] http://paste.ubuntu.com/309987/ [22:57] james_w, :( [23:00] oh the repeated query isn't the one from getPublishedSources [23:01] i think it's from getFilesForSources [23:01] nope [23:02] It's not from some permission-checking stuff? [23:02] getChangesFilesForSources [23:02] maybe indirectly [23:03] ok; theory: it's because changes_file_url is a @property on SourcePackagePublishingHistory [23:04] so when lazr.restful is serializing the spph it accesses this property, which runs that query [23:04] Isn't it more likely to be on the signer property? [23:04] Or is the person query not the big one? [23:05] that's a bit just plain odd [23:05] there are repeated person queries, but not that many [23:05] and they really should be fast (1-2ms each) [23:05] that sounds plausible [23:06] heh most of them are [23:06] but one took 7.9 seconds [23:06] probably some kind of locking thing in the db [23:06] Ah. [23:06] james_w: is this reproducable? [23:07] do you know what ws.size=75 implies? [23:07] possibly [23:08] just running locally [23:08] jml: it's the batch size i think [23:08] because there are 74 reps of that query [23:08] jml: i bet there would be 75 if it hadn't timed out [23:08] mwhudson, :) [23:08] makes sense [23:09] moral of the story? don [23:09] don [23:09] don't make exported attributes expensive to compute [23:10] win 38 [23:11] mwhudson, worth writing that one down, I reckon [23:11] so, bug on soyuz to make that cheaper or a method? [23:11] jml: definitely [23:11]