[00:01] <Laney> hm
[00:02] <Laney> Should I get reject emails if someone signs+uploads a package to their PPA but leaves me in Changed-By?
[00:02] <wgrant> I don't think so.
[00:03] <wgrant> Unless you have upload privileges to that PPA, I think.
[00:03] <Laney> http://dpaste.com/116006/
[00:03] <Laney> I think that's what happened here?
[00:04]  * wgrant checks the code.
[00:06] <wgrant> Hm.
[00:06] <wgrant> It should only email changed-by or maintainer if the upload was not to a PPA.
[00:06] <wgrant> Any idea to where it was uploaded?
[00:07] <Laney> all I have is this email
[00:07] <Laney> You are receiving this email because you are the uploader, maintainer or
[00:07] <Laney> signer of the above package.
[00:08] <lfaraone> .ckear
[00:08] <wgrant> I wonder if it was in fact uploaded to the primary archive.
[00:09] <Laney> those mails come from "Ubuntu Installer"
[00:09] <jpds> Might of been aiming for http://tinyurl.com/yjphghl .
[00:10] <Laney> I reckon so
[00:10] <wgrant> Laney: They should, yes. But if the uploader uploaded to ppa.launchpad.net/ubuntu, it will be from Launchpad PPA
[00:11] <wgrant> I would file a bug, since there are no Soyuz people around at the moment.
[00:11] <wgrant> Give the full email there, ideally including the headers and rationale.
[00:12] <wgrant> There's a bug somewhere, but it's unclear exactly where without logs.
[02:10] <blackh> Can someone help? Why can I not upload binary packages to a PPA???
[02:10] <wgrant> blackh: Why would you want to, when Launchpad will build them itself?
[02:11] <wgrant> 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] <wgrant> If you upload binaries that you build yourself, I cannot trust them.
[02:12] <blackh> 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] <wgrant> blackh: Do you not have a source package that you can easily build the binaries from?
[02:15] <blackh> 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] <wgrant> You should really fix the source packages, or they're not useful for anytbody else.
[02:15] <wgrant> The point of a source package is to directly build the binaries easily.
[02:15] <blackh> 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] <blackh> These are just grabbed from Debian.
[02:16] <wgrant> "One of the packages" being a new version of ghc?
[02:16] <wgrant> So you need a newer version of ghc?
[02:16] <blackh> Yes....  78 packages in all
[02:16] <wgrant> 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] <blackh> Ah - that could be my solution, then.
[02:18] <wgrant> 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] <wgrant> But they should speed up soon.
[02:20] <blackh> wgrant: Your help is very much appreciated - thanks.
[02:20] <wgrant> np
[02:29] <RenatoSilva> what happens if I delete a translation branch which is target for the automatic exports?
[02:31] <RenatoSilva> 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] <RenatoSilva> well, never mind. I think I don't need export branches
[02:43] <doctormo> If there any experts here this evening, I have a question related to ssh keys for a launchpad intergration project.
[02:43] <wgrant> !ask | doctormo
[02:43] <doctormo> 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] <ajmitch> certainly possible to have more than one
[02:45] <doctormo> 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] <ajmitch> the difference between them is the algorithm used to generate it
[02:45] <doctormo> ajmitch: No practical reasons? no different uses for each one?
[02:45] <wgrant> In Launchpad (as with a normal authorized_keys file), you just add new keys separated by line breaks.
[02:45] <wgrant> You should probably use RSA keys now.
[02:45] <ajmitch> you can read up on the differences if you want, I can't remember which one is recommended (RSA i think)
[02:45] <wgrant> DSA is losing favour.
[02:46] <ajmitch> you can also tell your ssh client to use specific keys to connect to various hosts
[02:46] <doctormo> 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] <wgrant> I don't think so.
[02:48] <ajmitch> id_rsa is just the default name
[02:48] <ajmitch> you can have them named something else
[02:48] <ajmitch> id_rsa_key_for_silly_launchpad_stuff
[02:49] <ajmitch> & then use the IdentityFile option in the ~/.ssh/config to use that for launchpad hosts
[02:52] <doctormo> 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] <doctormo> thanks guys
[02:53] <ajmitch> I hope it works out
[02:53] <ajmitch> whatever you're trying to do there :)
[02:58] <RenatoSilva> does the loggerhead support for tags include tag urls?
[03:00] <mwhudson> RenatoSilva: no
[03:09] <RenatoSilva> ok, bug 473691
[03:18] <RenatoSilva> is there any work for supporting download urls in Loggerhead?
[03:19] <RenatoSilva> 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] <spiv> Not off the top of my head, but it might not be hard to add, depending on what exactly you want.
[03:20] <RenatoSilva> download a tree
[03:20] <spiv> (I'm not an expert in hacking on loggerhead, though, so I might be wildly underestimating the difficulty)
[03:20] <RenatoSilva> currently, we need to bzr branch it
[03:21] <mwhudson> someone worked on that a bit i think
[03:21] <spiv> 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] <RenatoSilva> I think bug 246764 is what I want. Unfortunately the work is abandoned :(
[03:22] <RenatoSilva> spiv: forget about the tags, it's a separate bug
[03:22] <spiv> Ok
[03:23] <RenatoSilva> spiv: I want something like this: http://www.sheep.art.pl/devel/mandarin/archive/tip.zip
[03:23] <spiv> So basically you want a way for loggerhead to generate a "bzr export" for you.
[03:23]  * spiv nods
[03:23] <spiv> That would be the bug/feature mwhudson just mentioned
[03:24] <RenatoSilva> 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] <spiv> Yes, understood.
[03:25] <spiv> 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] <RenatoSilva> you mean the bug /I/ mentioned?
[03:25] <spiv> Oh, sorry, yes.
[03:26] <RenatoSilva> ok, I'll just subscribe and `affects me too`then
[03:57] <lifeless> spiv: it was implemented in loggerhead
[03:57] <lifeless> spiv: its disabled on lp
[03:58] <lifeless> for reasons of fear
[03:58] <RenatoSilva> so the bug info is outdated
[03:59] <RenatoSilva> fear of badwidth overhead?
[03:59] <lifeless> 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] <RenatoSilva> is it available in bzr? bzr export does not support specific directories right?
[04:02] <lifeless> yes it does
[04:03] <RenatoSilva> can't find in the help, let me see
[04:06] <RenatoSilva> 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] <RenatoSilva> it would not be that hard as bzr already has the feature
[05:51] <MTecknology> 503 Service Unavailable
[05:51] <MTecknology> No server is available to handle this request.
[05:51] <MTecknology> hurray!
[05:52] <MTecknology> Is https://login.launchpad.net/+openid down?
[05:52] <wgrant> WFM
[05:54] <MTecknology> wgrant: musta just hated me for a couple minutes
[09:32] <rowinggolfer> ok, so the estimated build time for a package in my ppa is now 31 hours.
[09:32] <rowinggolfer> :(
[09:40] <wgrant> It would be nice if one of the lpia builders could be reassigned to i386 :(
[10:03] <noodles775> losa: can we do wgrant's suggestion above - given the backlog of i386 builds?
[10:03] <mthaddon> noodles775: we'd need to confirm with the soyuz devs and/or ubuntu osa (lamont)
[10:09] <wgrant> noodles775: It's difficult -- it would need a change in the image :(
[10:10] <noodles775> Yeah, we need to hassle IS to get back all the normal ppa builders. bigjools is trying to do so.
[10:10] <wgrant> Even just one or two extra on i386 would make things muuuch better.
[10:17] <fwest> can i run my own launchpad server internally?
[10:18] <maxb> fwest: Annoyingly, no, not without an awful lot of effort.
[10:18] <fwest> oh shame
[10:18] <maxb> The Launchpad licence for the *code* is opensource. The images&icons, however, are not
[10:19] <maxb> So basically, the first thing you would have to do is replace all of the visual branding with your own unencumbered version
[10:20] <rowinggolfer> would be an opportunity to improve the css though ;)
[10:20] <\sh> moins
[10:20] <Meths> Is launchpad a tm too?
[10:21] <\sh> guys, why is Lucid Lynx not shown on the overview page of a package in ubuntu?
[10:21] <maxb> exact link please
[10:22] <\sh> maxb, https://launchpad.net/ubuntu/+source/zend-framework (see #u-m)
[10:53] <Laney> \sh: scroll down
[10:55] <\sh> Laney, yeah saw it...will this be fixed somehow?
[10:57] <wgrant> Bug 464014
[10:57] <wgrant> (targetted to LP 3.1.11, 2009-12-05)
[10:57] <Laney> are the i386 virtual builders backed up?
[10:57] <Laney> (delayed I mean)
[10:58] <wgrant> https://launchpad.net/builders
[10:58] <wgrant> They've been stolen as release mirrors.
[10:58] <Laney> bah
[12:09] <siretart> wgrant: just curious, will your source v3 format branch go live with tomorrow's launchpad upgrade?
[12:12] <wgrant> 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] <siretart> 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] <siretart> and I expect more and more DDs to switch
[12:14] <wgrant> 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] <siretart> ok
[12:14] <wgrant> The LP code is done, but there are buildd changes required which I intend to discuss tomorrow morning.
[12:15] <siretart> I was considering switching myself, but I'm not even sure how merge debian changes if I did
[12:15] <siretart> ok, thanks a lot for your work on this!
[12:15] <wgrant> np
[12:17] <siretart> 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] <siretart> compared to setting up e.g. a dak/wanna-build/buildd instance
[12:19] <Meths> I've seen no feedback what-so-ever on bug 435857
[12:19] <Meths> Are CSS bugs low priority or are devs unable to reproduce or want more info?
[12:19] <wgrant> 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] <wgrant> siretart: Although using an external non-Soyuzish archive like Debian is rather hackish, it works.
[12:25] <wgrant> http://williamgrant.id.au/f/1/2009/running-soyuz.html, if you are sufficiently brave/stupid.
[12:30] <james_w> wgrant: what will happen if we try and autosync packages in the new format?
[12:30] <wgrant> james_w: BOOM!
[12:31] <james_w> oh
[12:31] <james_w> yay
[12:31] <wgrant> james_w: In other words, the autosyncer will crash, and you'll need to blacklist the package to get it working again.
[12:31] <james_w> that will be fun on Monday
[12:31] <wgrant> I wonder if I can get the trivial fix to make it just reject them into the reroll.
[12:31] <wgrant> bigjools: ^^ one-liner in dak_utils.py fixes autosyncer crash. Would be nice to have.
[12:34] <bigjools> wgrant: sure, send in an MP and I'll make sure it gets in
[12:35] <wgrant> bigjools: Will do. Not sure exactly how the reroll works.
[12:35] <bigjools> no different from normal really, except we don't take anything down
[12:35] <bigjools> (unless necessary)
[12:37] <wgrant> bigjools: So it's a full rollout across everything?
[12:38] <bigjools> wgrant: AFAIK it's just to stuff that needs it
[12:38] <wgrant> bigjools: Ah.
[12:38] <bigjools> but the losas can tell you more
[12:39] <wgrant> I doubt there are any tests for this (it is semicoloned Python imported from dak, used only by sync-source.py). :(
[12:40] <bigjools> if there are tests for it I'll be surprised
[12:41] <wgrant> Also, tabs. Ew.
[12:43] <siretart> wgrant: looks interesting. thanks for the link!
[12:45] <wgrant> 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] <james_w> wgrant: thanks
[12:48] <siretart> wgrant: ok, I guess it might indeed be worth to have a closer look
[12:48] <wgrant> 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] <bigjools> an archive admin should be able to help you
[12:50] <wgrant> james_w: ^^?
[12:50] <james_w> it runs ~/sync-queue/process-incoming.sh
[12:51] <james_w> and dies if that fails
[12:51] <james_w> there's also find ~lp_archive/syncs/ -name '*.gz' -o -name '*.dsc' -o -name '*.changes' > ~lp_archive/syncs/flush-syncs-list
[12:51] <james_w> I don't think that needs adjusting for any new extensions?
[12:51] <wgrant> Argh. That'll need fixing too.
[12:51] <wgrant> It needs *.bz2.
[12:53] <james_w> and process-incoming.sh runs process-upload.py -d ubuntu -C sync
[12:53] <james_w> stop me if you have these scripts
[12:53] <wgrant> I don't.
[12:53] <wgrant> Well, I have process-upload.py
[12:53] <james_w> cool
[12:53] <james_w> if a shell script isn't -e
[12:53] <james_w> is it's exit code always 0, or the exit code of the last thing that it runs?
[12:55] <wgrant> I don't think process-upload.py will return a failure code just because it rejects an upload.
[12:55] <james_w> the latter
[12:55] <james_w> so yeah, all this depends on how process-upload.py handles the rejections
[12:58] <james_w> and we have possibly similar issues with backports
[12:58] <james_w> I guess we can't backport newer source formats?
[12:59] <wgrant> 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] <wgrant> 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] <james_w> ubuntu-archive-tools
[13:01] <Laney> 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] <james_w> but I don't know if the meat is there or on cocoplum
[13:01] <james_w> Laney: it is, those with usual buildd powers can do it for PPAs as well
[13:01] <Laney> oh sexy
[13:04] <wgrant> james_w: flush-backports is similar to flush-syncs?
[13:06] <james_w> wgrant: pretty much identical
[13:07] <wgrant> james_w: OK. process-upload.py returns 0 even if an upload was rejected, so it should be fine.
[13:07] <james_w> just uses a different directory to pull the source packages from
[13:07] <james_w> that's fine
[13:07] <james_w> I was more worried that it would stop at the first rejection
[13:07] <wgrant> Oh, no, it's not that crazy.
[13:07] <james_w> ace
[13:07] <james_w> thanks for checking
[13:08] <wgrant> So, your tools should be fine once Soyuz gets v3 support, as long as bz2 is added as an extension to match.
[13:08] <james_w> I can make the same modification to flush-backports as the archive will reject any new formats?
[13:08] <wgrant> Right.
[13:08] <james_w> yeah, I just added it to flush-syncs
[13:08] <james_w> I'll add it to flush-backports
[13:08] <james_w> thanks
[13:08] <wgrant> Now I just have to work out how the heck the buildds are going to work.
[13:12] <bigjools> Laney: give me the build URL and I'll rescore it
[13:12] <bigjools> james_w: did you request some sessions for us at UDS to talk about Build From Branch?
[13:12] <Laney> thanks bigjools, it's https://launchpad.net/~laney/+archive/ppa/+build/1319012
[13:12] <james_w> bigjools: haven't yet
[13:13] <bigjools> Laney: done
[13:13] <Laney> thanks
[13:13] <Laney> hopefull I won't have to hassle again ;)
[13:13] <bigjools> good :)
[13:13] <Laney> stupid non reproducible problems
[13:13] <bigjools> james_w: ok, or I can do it, but I don't know where to go :)
[13:16] <james_w> bigjools: nope, I'll speak to robbie
[13:16] <bigjools> cool thanks
[15:04] <cr3> 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"
[15:59] <james_w> jml: does +branch work over bzr+ssh?
[16:04] <jml> james_w, no. there's an open bug for making it do so, though
[16:04] <jml> james_w, simple matter of programming
[16:04] <james_w> ok, thanks
[16:57] <ScottL_> 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] <ScottL_> colin watson is building it but cant' look at it right now and asked me to mention it here
[17:02] <Meths> ScottL_: I think the builders are currently reassigned as release mirrors
[17:05] <ScottL_> 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] <Meths> ScottL_: Agreed, looks broke in the logs.
[17:12] <Meths> Looks like they're back building too.
[17:17] <glen> 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] <glen> from dropdown i can only choose between "deleted" and "needs review"
[17:20] <henninge_> glen: approval of translations happens automatically if the files can be associated with a template and a language
[17:21] <ScottL_> Meths: Is there someone I should mention this to directly? to try to get it fixed?
[17:21] <glen> henninge_: how do i associate the translation with template(pot?)+language?
[17:22] <henninge_> glen: template: same directory as the template
[17:22] <henninge_> glen: language: file name is a valid language code
[17:22] <henninge_> glen: your files look good on both counts
[17:23] <henninge_> glen: so just be patient, it may take a few hours as the approval script is often very busy
[17:23] <henninge_> same goes for the import script ... ;)
[17:23] <glen> ah. that could explain things
[17:25] <Meths> ScottL_: Sorry, don't know.  You could try sending an email to the buildd admins.
[17:29] <ScottL_> Meths: ah, I did that already :(    well, I tried, it will get fixed at some point
[17:33] <kb9vqf> Any chance more i386 PPA builders could be brought online?
[17:33]  * kb9vqf notes the queue is at 44 HOURS!
[17:33] <kb9vqf> ;)
[17:37] <ScottL_> kb9vqf: one of the builders (iridium) appears to be stuck, which is backing up the queue
[17:38] <kb9vqf> OK, just wanted to let someone know
[17:40] <ScottL_> kb9vqf: that's why I'm here too ;)
[17:40] <kb9vqf> :)
[17:41] <kb9vqf> A user wanted knetstats-kde3...hopefully he'll have it before the weekend
[17:50] <jcastro> hi everyone, marjo needs the right permissions to be able to approve blueprints for the uds-l sprint
[17:51] <jcastro> currently the qa folks are submitting blueprints but marjo can't approve them
[17:57] <avar> 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] <avar> We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience.
[17:58] <avar> Trying again in a couple of minutes might work.
[17:58] <avar> (Error ID: OOPS-1404B2436)
[17:59] <XiXaQ> have I understood correctly, that Ubuntu on launchpad no longer wants usability bug reports?
[17:59] <avar> 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] <XiXaQ> 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] <avar> XiXaQ: file something at https://bugs.launchpad.net/ubuntu/+filebug/?no-redirect ?
[18:02] <XiXaQ> avar, ok, I got the impression that the point was to discourage people from filing non-crash bugs?
[18:04] <avar> XiXaQ: Dunno, just try
[18:06] <XiXaQ> ok, thanks.
[18:08] <jcastro> can someone help me sort out marjo's blueprint permission thing? It's blocking the QA team from adding sessions for UDS
[18:21] <jcastro> jml, could you point me in the right direction perhaps?
[18:33] <rockstar> jcastro, what's up?
[18:33] <jcastro> rockstar, ~marjo-mercado needs to be able to approve/decline blueprints for the uds-l sprint
[18:33] <jcastro> I don't know if he's supposed to be in a certain group or ... ?
[18:34] <rockstar> sinzui, ^^
[18:35] <sinzui> 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] <jcastro> sinzui, aha! maybe "UDS Organizers"
[18:36]  * jcastro goes off to try
[18:38] <sinzui> jcastro: I think you are right
[20:13] <james_w> the Debian import seems to be quite out of date
[20:13] <james_w> is it generally unreliable?
[20:13] <james_w> it doesn't seem to be as reliable as I would like
[20:19] <bigjools> james_w: can you ping a losa about it
[20:21] <james_w> mbarnett: hi, would you be able to check that the Debian import is running for us?
[20:22] <mbarnett> 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] <james_w> I'm trying to find some indication of what the "Debian import" actually is in anticipation of that ;-)
[20:24] <bigjools> mbarnett, james_w: it's "gina"
[20:24] <bigjools> runs on iron.c.c
[20:24] <james_w> aha!
[20:25] <james_w> 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] <james_w> that package certainly won't be up to date
[20:25] <james_w> is it possible that gina stops as soon as it hits one?
[20:32] <james_w> ok, it's not as bad as I thought
[20:33] <james_w> it looks to be up to date as of about 20 hours ago, except for new source format packages
[20:33] <james_w> bigjools: is it run from cron?
[20:33] <bigjools> yes, twice a day IIRC
[20:34] <bigjools> wgrant found the problem with v3 packages, I think he has a fix ready
[20:34] <james_w> cool
[20:34] <james_w> any chance we could crank that to four times a day?
[20:34] <bigjools> not sure if it blocks the whole run or just that package
[20:34] <james_w> since Debian has 4xdinstall a day now
[20:34] <bigjools> oh yes in that  case we should do that
[20:35] <james_w> let me get you the times
[20:35] <james_w> http://lists.debian.org/debian-devel/2008/12/msg00955.html
[20:37] <bigjools> cheers
[20:38] <james_w> bigjools: would you like a bug for this or similar?
[20:39] <wgrant> james_w: I verified last night that gina will just skip v3 packages, and I know how to fix it.
[20:39] <wgrant> However I can't fix it until most of the rest of LP supports v3.
[20:40] <james_w> wgrant: thanks for looking at it
[20:40] <bigjools> james_w: I just need to file an RT about it, will sort it tomorrow
[20:40] <james_w> thanks
[20:41] <james_w> mbarnett: thanks, but it seems to be running fine, so we don't need the check now.
[20:41] <mbarnett> james_w: yay!
[20:42] <bigjools> gina is bug-free (according to kiko) :)
[21:24] <fta> 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 :(
[22:21] <james_w> OOPS-1404D3213
[22:24] <james_w> am I reading it wrong, or is that reporting lots of repeated SQL statements? ^
[22:28] <jml> james_w, you are reading it correctly
[22:29] <james_w> any idea why that might be happening?
[22:35] <jml> james_w, badly written code
[22:35] <jml> james_w, it's not infinite repetition
[22:35] <jml> james_w, if you look carefully, you'll see the '%s' -- that's probably substituted with a different value each time
[22:36] <jml> james_w, ORMs make it really, really easy to write code like 'for x in xs: x.doExpensiveQuery()'
[22:36] <james_w> I'm calling this over the API
[22:36] <james_w> is it my code that's wrong?
[22:37] <james_w> I guess not as it wouldn't be one GET then
[22:37] <jml> james_w, right, that's my impression
[22:38] <james_w> I'm not sure what would have changed here
[22:38] <jml> james_w, what are you GETting?
[22:38] <wgrant> What's the request?
[22:38] <jml> 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] <jml> on /beta/ubuntu/+archive/primary
[22:39]  * jml looks up the implementation for getPublishedSources
[22:39] <james_w> ah, request variables, neat
[22:40] <jml> james_w, some problems we nailed years ago :)
[22:47] <jml> james_w, this is not a post-pint function
[22:47] <jml> at least, not for reading.
[22:47] <james_w> heh
[22:48] <james_w> well, it's not explicitly adding that %s
[22:49] <mwhudson> 42 select person.* from person where id = %s should really not take 8 seconds
[22:49] <james_w> yeah
[22:49] <james_w> and why are they repeated through the query log as well
[22:49] <james_w> ?
[22:49] <jml> james_w, the %s is something the OOPS log does
[22:49] <jml> james_w, I think
[22:50] <jml> or something
[22:50] <james_w> it's almost like I'm pipelining multiple queries in to one GET
[22:50] <jml> james_w, are you looping calls to  getPublishedSources?
[22:50] <james_w> yes
[22:51] <james_w> partitioning on distro_series so that it doesn't timeout ironically
[22:51] <jml> intriguing
[22:51] <james_w> http://paste.ubuntu.com/309984/
[22:53] <mwhudson> sounds like the implementation of getPublishedSources isn't very good
[22:54] <wgrant> It looks fine.
[22:54] <jml> james_w, icommon.lp_call?
[22:54] <james_w> heh
[22:55] <mwhudson> or maybe something lazr.restful is made of crack
[22:55] <jml> james_w, what is that?
[22:55] <james_w> http://paste.ubuntu.com/309987/
[22:57] <jml> james_w, :(
[23:00] <mwhudson> oh the repeated query isn't the one from getPublishedSources
[23:01] <mwhudson> i think it's from getFilesForSources
[23:01] <mwhudson> nope
[23:02] <wgrant> It's not from some permission-checking stuff?
[23:02] <mwhudson> getChangesFilesForSources
[23:02] <mwhudson> maybe indirectly
[23:03] <mwhudson> ok; theory: it's because changes_file_url is a @property on SourcePackagePublishingHistory
[23:04] <mwhudson> so when lazr.restful is serializing the spph it accesses this property, which runs that query
[23:04] <wgrant> Isn't it more likely to be on the signer property?
[23:04] <wgrant> Or is the person query not the big one?
[23:05] <mwhudson> that's a bit just plain odd
[23:05] <mwhudson> there are repeated person queries, but not that many
[23:05] <mwhudson> and they really should be fast (1-2ms each)
[23:05] <james_w> that sounds plausible
[23:06] <mwhudson> heh most of them are
[23:06] <mwhudson> but one took 7.9 seconds
[23:06] <mwhudson> probably some kind of locking thing in the db
[23:06] <wgrant> Ah.
[23:06] <mwhudson> james_w: is this reproducable?
[23:07] <jml> do you know what ws.size=75 implies?
[23:07] <james_w> possibly
[23:08] <james_w> just running locally
[23:08] <mwhudson> jml: it's the batch size i think
[23:08] <jml> because there are 74 reps of that query
[23:08] <mwhudson> jml: i bet there would be 75 if it hadn't timed out
[23:08] <jml> mwhudson, :)
[23:08] <james_w> makes sense
[23:09] <mwhudson> moral of the story?  don
[23:09] <mwhudson> don
[23:09] <mwhudson> don't make exported attributes expensive to compute
[23:10] <lifeless> win 38
[23:11] <jml> mwhudson, worth writing that one down, I reckon
[23:11] <james_w> so, bug on soyuz to make that cheaper or a method?
[23:11] <mwhudson> jml: definitely
[23:11] <james_w> and then a workaround to avoid hitting the issue?
[23:12] <mwhudson> jml: oh, i thought you said that in #launchpad-dev :)
[23:12] <mwhudson> james_w: yes a bug on soyuz
[23:12] <jml> mwhudson, heh
[23:13] <mwhudson> james_w: not sure what a workaround would be, you might be able to get the client to move across the collection in smaller chunks
[23:14] <mwhudson> i.e. it seems to be fetching 75 at a time, doing 20 at a time would be correspondingly less likely to time out
[23:16] <mwhudson> james_w: maybe you can say
[23:16]  * jml is off to bed
[23:16] <mwhudson> collection = getPublishedSources(...)
[23:17] <mwhudson> for i in range(0, len(collection), 10):
[23:17] <mwhudson>   for source in collection[i:i+10]:
[23:17] <mwhudson>    ....
[23:17] <james_w> if it implements len() :-)
[23:17] <james_w> bug 474876
[23:18] <james_w> if you want to turn it in to LP speak at all
[23:23] <james_w> yeah, no len() love
[23:24] <mwhudson> james_w: well just do for i in xrange(0, sys.maxint, 10) and tell when you've fallen off the end somehow i guess
[23:25] <james_w> and doesn't restfulclient request a page at a time anyway?
[23:25] <james_w> it's requesting 75, but I'm using __iter__ so I only want 1
[23:26] <mwhudson> james_w: it looks like __iter__ requests pages as an "optimization"
[23:26] <james_w> ah, but slicing will cause it to request less
[23:26] <mwhudson> james_w: but i don't think the slice fetching does
[23:27] <mwhudson> well, the 75 appears to be under the server's control actually
[23:27] <mwhudson> james_w: yeah, i think this will work
[23:28] <james_w> slicing sets ws.size if it thinks it won't need a full page
[23:28] <mwhudson> yeah
[23:29] <Laney> Alright fellas, this --- https://launchpad.net/debian/+source/gnome-do-docklets/+publishinghistory --- seems not to be correct. Can someone manually kick it, and where should I file the bug (if there is one)?
[23:29] <Laney> (it's pending, and the package is in testing)
[23:31] <james_w> Laney: not sure why that's not being shown in testing
[23:32] <james_w> other packages since then have imported
[23:32] <james_w> from sid at least
[23:32] <Laney> yeah
[23:32] <Laney> requestsync uses this data now
[23:33] <james_w> so does the bzr importer, so I also want to see it up to date
[23:35] <Laney> let's bug it
[23:35] <Laney> do you know which product to file against?
[23:37] <james_w> just go with launchpad
[23:51] <wgrant> There's more recent stuff imported from testing as well.