[01:53] is there syntax in the email interface for bugs to apply one comment to multiple bugs, simulatneously? I.E. when I email edit@bugs.launchpad, I end up providing bug, affects, and status, so that it knows which status to set for which release in Ubuntu for that given source package and bug... but I don't know how to add one comment to all the bugs... is that even possibel? [01:55] teward: No, but there's a trick: you can also send a comment that includes commands to NUMBER@bugs.launchpad.net, and Cc it to lots of bugs. But why not use the API for this? [01:55] The Ccing to tonnes of bugs strategy was common in like 2007, but we have launchpadlib now. [01:59] wgrant: is there a nice way to do that via the api, or do I need to ultimately code it? [01:59] teward: "ultimately code it" being like 4 lines of code. [01:59] If you want to close all Karmic bugs, it's extremely complicated. [02:00] for task in lp.distributions['ubuntu'].getSeries(name_or_version='karmic'): [02:00] task.status = 'Invalid' [02:00] task.lp_save() [02:01] task.bug.newMessage(content="Karmic is EOL", subject="Karmic is EOL") [02:01] Er [02:01] wgrant: geez, that's not hard... oh wait, is that Python? [02:01] First line should also have a .searchTasks() at the end. [02:01] It is Python, yes. [02:01] You can run that directly in lp-shell (though do try API things against staging or qastaging first :)) [02:03] yeah, don't fubar it and change every open bug in lp to invalid. :) [02:04] i was planning on beating staging actually... [02:04] i don't give staging enough pain and punishment :P [02:05] wgrant: and here's where the coding gets trickier - i want to only close New, Incomplete, or Confirmed bugs against Karmic... [02:05] teward: searchTasks(status=['New', 'Incomplete', 'Confirmed']) should work. [02:06] * dobey highly recommends https://launchpad.net/+apidoc/1.0.html [02:06] dobey: it helps when these things are given initially, yes. :) [02:08] dobey: i should read through it... although nice tidbit: I"m not a python guy by nature. so if none of you mind me beating staging a couple thousand times i'll be testing against that [02:09] Well, staging's down atm for a DB refresh, but qastaging's up. [02:10] wgrant: i wasn't planning on running anything until tomorrow - i have three VMs, two servers, a switch, and my firewall's firmware to update this evening [02:10] wgrant: but if i do decide to work on that today, with login_with(), does it understand `qastaging` as well as `staging` and `production` [02:10] It does. [02:11] wgrant: and there's no risk of actually affecting real data by targeting qastaging or staging with the testing of this? (Just making sure before I ever run this :P) [02:12] No, they're separate servers and databases, firewalled from production. [02:25] wgrant: okay, that's good. i'm going to run this against qastaging on a very small subset of the karmic bugs then - there's only 6 incomplete bugs :P [02:25] hopefully it only hits these 6 [02:27] wgrant: via the api, changes are instantaneous? [02:28] for definitions of instantaneous that depend on your network speed, and whether any errors happened [02:28] and also possibly if you called lp_save() [02:28] well unless i botched the code... [02:30] dobey: https://gist.githubusercontent.com/teward/5d17e366f2dca158b171/raw/065fd7f2726d42456388200ee33b7ebab8702ce0/launchpad-close-karmic-bugs.py <-- note: first time working with the API, basically following wgrant's example verbatim [02:31] teward: move the lp_save to after the message creation [02:31] task.status, not task.bug.status [02:31] lp_save is fine where it is. [02:31] of course, that might not fix it [02:31] Methods are instantaneous; they don't require a save. [02:32] Only attribute changes require a save. [02:32] true [02:32] but when reading the code it looks weird with the save in the middle :) [02:33] well, to appease dobey, i'll move the lp_save to the end there. let me run this again... [02:33] everything else looks fine, though, for the most part? [02:34] aside from the thing wgrant mentioned, yeah [02:34] mmm... looks like it still didn't do anything [02:34] and net speed here is 105Mbps download, 15Mbps upload, just checked and confirmed [02:34] so IDK [02:34] * teward shrugs [02:34] Have you confirmed it found the bugs? [02:35] wgrant: no i haven't - any way to output what it finds? again, new to the API [02:35] right, get the list prior to the loop and ensure it's not empty [02:35] print on each iteration of the loop? [02:37] god i need to learn this api... >.> [02:37] wgrant: print task.bug.id, or what? sorry if i'm sounding handholdy, i'm just wholly unfamiliar with the API as it currently stands [02:37] Or print task [02:38] that works [02:38] oh, that's why, it didn't find anything... [02:39] You may have to explicitly search for "Incomplete (with response)" and "Incomplete (without response)" [02:39] i've never had to do that for incompletes [02:39] Ah, of course, omit_targeted. [02:40] mmm, possibly... still prints no results if i expand the searchTasks(status=[ ... to include that [02:40] I didn't think so, but that was the obvious thing. [02:40] Give omit_targeted=False [02:41] THERE we go [02:41] now it's giving the 6 bug tasks... it should now work and mark them "Won't Fix" if I did this right... [02:43] well, i don't even remember why i came back into my office this late now, so later :) [02:43] dobey: see ya, thanks for all the assistance :) [02:44] wgrant: whooo, it works! thanks again. [02:44] Yay. [02:44] how SIMPLE this is :) [02:45] wgrant: only question i have left... is it possible to target a specific package with the API? [02:45] a variant of this script might be executed come EOL times for any nginx bugs against the EOL release. [02:45] (since that's the package i primarily watch) [02:45] teward: getSourcePackage(name='nginx') on either the series or the distribution. [02:45] https://launchpad.net/+apidoc/devel.html documents the entire API. [02:46] wonderful. Thanks, wgrant [02:46] and again, sorry for needing the handholding [02:46] np, glad you got it sorted out. [02:47] wgrant: at least this can be run against qastaging or staging until i get it doing all that I want it to... that definitely helps a bit [02:51] wgrant: last question - because i'm rusty as all hell with python. If I want to include line breaks in the message content, is it just \r or \n, or \r\n [02:52] teward: Launchpad will cope with either. But one normally uses \n unless on Windows. [03:07] wgrant: ack, thanks [03:55] wgrant: interesting issue - it left 27 bugs in qastaging untouched - i had to wait 5 minutes and run it again and it got the last 27 bugs on qastaging... [03:55] * teward shrugs [07:26] www.openas.org - an open-source Anti-Spam appliance - We're still looking for contributers, volunteers and supporters. Check it out! [09:42] teward: When you retrieve collections of things from the API, they're batched, and the client only fetches the next batch when it needs to. This can introduce confusion if you're mutating the collection as you go. If you definitely intend to operate on the entire collection, it can be handy to wrap it in list() to force the whole thing to be materialised on the client in advance. [09:45] its also possible that other agents are mutating the list [09:45] its a concurrent system and IIRC we didn't get around to implementing the stable batch markers design. [09:46] Right, that too, but when operating on qas and missing 27 items I know which is more likely :-) [09:47] (Apologies for slight incoherency, a small motor vehicle^W^W^Wcat was demanding my attention) [09:47] cjwatson: :) [09:50] The irony is we don't even have a cat [09:51] But we do have one extremely determined to adopt us ... [09:54] there are worse things [15:38] hello [15:39] I'm having problem with versions in launchpad [15:40] I messed up with one package, the right version was 1.0.2, but it was with 1.8.0... so I changed the changelog for the right version, and now I can't publish [16:21] ahh, i think I managed to fix that === cprov__ is now known as cprov_ === Ursinha_ is now known as Ursinha === Peng_ is now known as Peng === tsimpson_ is now known as tsimpson === NikitaKonovalov2 is now known as NikitaKonovalov === nesthib_ is now known as nesthib === Spads_ is now known as Spads === igitoor_ is now known as igitoor === nesthib is now known as Guest36803 === vidplace7__ is now known as vidplace7_ === stgraber_ is now known as stgraber === funnel_ is now known as funnel [20:31] What terminal are the daily builds running on? [20:32] There is a problem with some Vim test: https://groups.google.com/d/msg/vim_dev/x-ZqAWBYfL0/PCt-HaJlCxEJ === daker__ is now known as daker [20:43] blueyed: TERM is unset when the build starts. If you have special requirements, you need to handle them in the build yourself. [20:45] wgrant: does this apply to builds in general or only the daily builds? [20:45] blueyed: All binary package builds use that environment. [20:46] There's no distinction between daily and non-daily binary package builds; only the way the source gets into Launchpad differs. [20:49] Hmm. Then I wonder why the vim-daily build fails, but the one for Ubuntu does not. I am using the Debian packaging, where debian/rules is similar, except that Ubuntu ignores some other test. [20:55] blueyed: The test wasn't changed recently upstream? [20:59] wgrant: good point. It was, but I cannot say really if it is related. Where's the last build log for Ubuntu? [21:00] https://launchpad.net/ubuntu/+source/vim [21:00] Pick the version you're interested in. [22:01] Hi guys, I'm wondering what anti-spam appliances / gateways you're deploying in a typical business environment? Which features do you use and would you like to have in a typical product like this? We're currently developing a open-source e-mail security appliance and would be happy for your suggestions. See www.openas.org and https://launchpad.net/open-as-cgw === cprov_ is now known as crov === crov is now known as cprov === Nigel_ is now known as G