[02:34] <psusi> so I have a collection of bugs returned from searchTasks() and I'm trying to do for bug in bugs: bug.newMessage(content=message) and I'm getting an exception saying AttributeError: 'Entry' object has no attribute 'newMessage'
[02:35] <wgrant> psusi: searchTasks returns bugtasks, not bugs.
[02:36] <wgrant> for task in foo.searchTasks(...): bugtask.bug.newMessage(...)
[02:40] <lifeless> psusi: I'm curious what you're writing
[02:42] <psusi> lifeless, a script to close out all bugs on a removed package at once ;)
[02:43] <psusi> wgrant, don't you mean task.bug.newMessage()?
[02:43]  * micahg would be worried about such a script being abused
[02:44] <wgrant> psusi: Yes.
[02:44] <StevenK> micahg: Use it against firefox? Sounds fun.
[02:45] <micahg> StevenK: heh, I have 2 sources to clean after natty release, but I need to make sure that the ones that need to be open stay open
[02:47] <psusi> ahh, I see.. yes.. of course, the status is a property of the task, but messages get added to the bug the task is a part of
[02:48] <psusi> by the way, is there a way to speed things up?  it seems to take forever setting the status in a for loop, I guess because each assignment results in a http call to the server
[02:48] <psusi> be nice to batch up the requests
[02:50] <psusi> staging is mirrored from live once a day right?
[02:50] <wgrant> Once a week, more or less.
[02:51] <psusi> ahh
[02:58] <psusi> this is weird... bug.bug.newMessage() works, but bug.status = 'Invalid' silently fails.. the bugs get the comment but the status is still new
[02:58] <StevenK> psusi: Do you call task.lp_save()?
[02:59] <psusi> doh... I thought there was some sort of save I did last time.. this time i"m saving the script instead of just doing it in an interactive python session ;)
[03:08] <psusi> well, it is taking quite a while, but it is indeed closing out the 168 open bugs in usplash... now to get to the other open status's than New
[03:08] <psusi> 239 total open bugs... hooray for automation
[03:21] <psusi> hrm.. https://help.launchpad.net/Packaging/BuildScores specifies how build priority is calculated for the -proposed pocket, but when I tried to upload a package to my ppa for lucid-proposed, I got: Rejected: PPA uploads must be for the RELEASE pocket.
[03:21] <StevenK> -proposed is only for the distribution itself
[03:22] <psusi> why?
[03:23] <psusi> can't I test build it in my ppa fist?
[03:23] <StevenK> Yes, but it's a little complicated, since your PPA also needs to pull from proposed.
[03:24] <wgrant> PPAs don't have pockets, you can't upload to -proposed.
[03:24] <wgrant> So you have to change the series in the changelog for a PPA upload.
[03:24] <psusi> hrm... oh well, I just changed it back to lucid to upload to the ppa
[03:26] <micahg> actually, you can just set ~/.dput.cf to upload to lucid and ignore the release/pocket in the changelog
[03:26] <psusi> ok, this is frigging goofy... this is the third time I've run this script to close out the bugs and each time it seems to leave some....it is down to only 18 now but...
[03:26] <micahg> psusi: https://help.launchpad.net/Packaging/PPA/Uploading#Using%20packages%20from%20other%20distributions
[03:26] <wgrant> psusi: Try listfying the collection before you iterate over it.
[03:27] <psusi> wgrant, why?
[03:27] <wgrant> psusi: Otherwise it might try to grab it in batches... and the batches will have mutated because you're removing all the bugs from the first batch.
[03:27] <psusi> aha!
[03:27] <wgrant> So launchpadlib grabs 1-50, removes them from the list.
[03:27] <wgrant> Then grabs 51-100
[03:27] <wgrant> But those are now 1-50
[03:28] <psusi> goofy!
[03:28] <wgrant> Yes.
[03:28] <wgrant> Very.
[03:28] <psusi> so bugs = list(package.searchTasks(status='New')?
[03:29] <wgrant> Please call it 'tasks' or similar instead :)
[03:29] <wgrant> But yes.
[03:29] <psusi> k
[03:30] <psusi> ahh good, then I should also be able to append more searchTasks on the other status'... .append() doesn't seem to work on the task collection
[03:33] <psusi> so when is staging next going to be mirrored? :)
[03:34] <wgrant> Should be over the weekend.
[03:35] <psusi> ok... I'll run this again after the next mirror just to make double tripple sure it's correct before turning it loose on live
[08:15] <Daviey> Hello! i386 PPA builders seem wedged?  11 hour queue
[08:16] <Daviey> wedged is the wrong word, because some seem to be working. :/
[08:16] <wgrant> Daviey: Most of them are off doing other things.
[08:16] <wgrant> Have been for a few days.
[08:17] <Daviey> oh, jolly good :)
[08:17] <wgrant> I'll poke people to give them back, once London wakes up.
[08:17] <Daviey> thanks wgrant
[08:32] <nigelb> hrm, I forget who we poked during dev week, but if anyone wants to talk about how lp would help app devs, https://wiki.ubuntu.com/UbuntuAppDeveloperWeek
[08:32] <nigelb> I guess, mailing lp-dev would be a good idea at this point
[10:12] <baltix-members> hello launchpad developer and users :)
[10:14] <baltix-members> maybe someone could tell me why small PPA build should wait 12 hours for start? See https://launchpad.net/~baltix-members/+archive/ppa/+buildjob/2324181
[10:15] <bigjools> baltix-members: there's a big queue: https://edge.launchpad.net/builders
[10:20] <baltix-members> bigjools: maybe there is some problems with builders? few months ago I noticed big queue and some launchpad developers told me, that big queue was because of stopped builders - he restarted build server and only then the problem was fixed :)
[10:21] <wgrant> baltix-members: The builders were off doing some non-builder stuff. They should start coming back in a few minutes, and the queue will clear within a couple of hours.
[10:21] <baltix-members> wgrant: thanks for info
[10:23] <baltix-members> wgrant: I'm releasing new version of Ubuntu based operating system and I need to release test images in 3 hours, are there any chances to finish my cdrdao backport in ~2 hours?
[10:30] <baltix-members> wgrant: Why most of i386 builders are Idle now? See: https://launchpad.net/builders
[10:30] <wgrant> baltix-members: palmer, roseapple, rothera and vernadsky are for building Ubuntu.
[10:31] <wgrant> The others further down the page are the ones that PPAs build on.
[10:31] <wgrant> Starting from iridium.
[10:34] <baltix-members> wgrant: I thought, that all builders can do PPA builds :)
[10:34] <wgrant> baltix-members: No, some are reserved for Ubuntu itself (for security reasons)
[10:37] <wgrant> baltix-members: cdrdao is building.
[10:37] <baltix-members> it seems I should say thanks for someone - my build was just started instead of waiting 12 hours :)
[10:38] <baltix-members> wgrant: thank you :)
[10:38] <wgrant> Everything else should build soonish.
[10:38] <wgrant> The builders are nearly back.
[11:14] <dpm> hi launchpadders, it would be great to have some LP content on AppDeveloperWeek. Would anyone be up for picking any of the proposals on https://wiki.ubuntu.com/UbuntuAppDeveloperWeek or to sign up for a session with another LP topic?
[11:29] <Laney> please include debian/NEWS entries with lplib uploads in future when you are going to break clients
[15:08] <psusi> is there a proper procedure for the death of a project?  launchpad.net/usplash is no longer maintained and lists a canonical employee as the maintainer who has left.  Shouldn't it at least be updated to indicate it has no maintainer?
[15:13] <dpm> hey all, could someone have a look why the language pack export on https://translations.launchpad.net/ubuntu/maverick/+language-packs is not yet available?
[15:14] <dpm> the maverick ones should be available on Wednesdays:
[15:14] <dpm> https://dev.launchpad.net/Translations/LanguagePackSchedule
[15:14] <dpm> thumper, wallyworld^
[15:14] <popey> psusi: usplash is still shipped in an LTS release (8.04, hardy) and even though keybuk has left the company, he could still maintain it if he wished :)
[15:30] <psusi> popey: I'm pretty sure he isn't... he said that Scott James Remnant (canonical) is dead.. we had a funeral for him and everything... his words... and the package has been dropped from Ubuntu and is being dropped from debian... I suppose it doesn't hurt to keep the project listed, but shouldn't it at least be clear that it is no longer maintained?
[16:02] <popey> psusi: dunno :)
[16:20] <c10ud> hello, i'm try making launchpad import code from github, bu the thing is failing because we have a git submodule in the tree. i don't need it in launchpad, how can i tell it?  http://launchpadlibrarian.net/66508919/emesene-team-emesene-master.log
[16:21] <c10ud> s/try making/trying to make
[16:26] <beuno> c10ud, I think LP doesn't support submodules
[16:27] <beuno> well, I know it doesn't, but I'm not sure if it shiuld be failing
[16:41] <c10ud> beuno, is there any way to tell launchpad to leave submodules alone?
[16:46] <c10ud> brb
 hey all, could someone have a look why the language pack export on https://translations.launchpad.net/ubuntu/maverick/+language-packs is not yet available?
[16:47] <dpm>  the maverick ones should be available on Wednesdays:
[16:47] <dpm>  https://dev.launchpad.net/Translations/LanguagePackSchedule
[16:48] <dpm> could anyone from a maintenance squad have a look? ^
[16:48] <dpm> thanks!
[17:28] <Q-FUNK> wasn't support for Jaunty dropped during autumn?  apparently LP still accepts Jaunty packages for the PPA. :)
[17:28] <maxb> Yes, this is confusing.
[17:29] <maxb> I'd quite like some guidance on how long this will continue, so I can make plans for whether Bazaar should plan their own jaunty-desupport date or not
[17:29] <bigjools> some other, er, parties wanted to continue using jaunty
[17:29] <maxb> hah
[17:30] <maxb> It would be nice if launchpad-users@ could be sent a likely timeline for jaunty/karmic PPA support ceasing
[17:30] <bigjools> when we mentioned security updates I think there was a case of fingers in ears
[17:30] <bigjools> it's mostly up to the IS guys
[17:32] <maxb> IS == ..... something Systems?
[17:32] <bigjools> da admins
[17:34] <maxb> Because they choose when it's appropriate to cease supporting it to avoid people using builder time better spent on current series?
[17:34]  * maxb can't see why the admins would care other than that
[17:34] <bigjools> they have to spend time updating chroots etc as wel
[17:35] <elmo> we care because it ties into what needs to be on archive.ubuntu.com
[17:35] <elmo> and for hystericals reasons that's still with us
[17:39]  * maxb sobs at people who think registering a code import of http://localhost is a good idea
[17:41] <bigjools> !
[17:42] <lifeless> maxb: win!
[21:00] <bryceh> is launchpad down?
[21:00] <lifeless> no
[21:00] <lifeless> whats up?
[21:01] <bryceh> The webpage at https://bugs.launchpad.net/ubuntu/+bug/599017 might be temporarily down or it may have moved permanently to a new web address.
[21:02] <lifeless> seems fine to me
[21:02] <bryceh> had been noticing blueprints.launchpad.net was taking a long time to respond, but now nothing is loading
[21:02] <bryceh> hmm
[21:02] <lifeless> what was the status code you got?
[21:02] <lifeless> (from your browser)
[21:02] <bryceh> in Chromium - Error 7 (net::ERR_TIMED_OUT): The operation timed out.
[21:03] <lifeless> bryceh: sounds like a routing issue
[21:03] <lifeless> mbarnett: those alerts - any networking related?
[21:04] <mbarnett> lifeless: nopers
[21:05] <lifeless> bryceh: traceroute etc time
[21:49] <bryceh> http://paste.ubuntu.com/581320/
[21:54] <wgrant> bryceh: Interesting. My routing is just about the same from hop 7, and it works fine for me.
[21:54] <wgrant> To both of the frontends (they're the next hop after chenet)
[21:56] <bryceh> http://planet.ubuntu.com/ works, wiki.ubuntu.com hangs, www.canonical.com loads, http://directory.canonical.com/ doesn't, canonicaladmin doesn't (what's new), login.ubuntu.com hangs
[21:57] <wgrant> #is might be a good idea.
[21:59] <bryceh> wgrant, does your traceroute go through eth0.chenet.canonical.com too?
[21:59] <wgrant> bryceh: Yes.
[21:59] <wgrant> It's the penultimate hop.
[22:00] <wgrant> The last four hops are identical for me.
[22:00] <wgrant> The 5 or 6 before then are slightly different hosts, but same locations.
[22:03] <blueyed> Does https://help.launchpad.net/Packaging/SourceBuilds/Recipes (still) work as documented?
[22:04] <lifeless> sure hope so
[22:04] <blueyed> I am looking at creating a recipe for Vim builds.
[22:04] <blueyed> good.
[22:05] <blueyed> You are not aware of a daily/current build ppa for vim, are you? ツ
[22:05]  * blueyed does not want to duplicate work.. ;)
[22:06] <Ampelbein> blueyed: you can look through https://launchpad.net/ubuntu/+ppas?name_filter=vim I guess
[22:10] <lifeless> Ampelbein: or /+dailybuilds :)
[22:16] <blueyed> lifeless: where is +dailybuilds?
[22:17] <wgrant> https://code.launchpad.net/+daily-builds
[22:35] <blueyed> thanks, wgrant. it's not searchable though. the "30 days" filter is very good though!
[22:36] <blueyed> before I'll skim the docs, is it possible to build from a mercurial branch, where the packaging comes from debian?
[22:37] <blueyed> after all, it would be best to just help with debian packaging I guess.
[22:40] <wgrant> blueyed: Launchpad can import some hg branches.