[08:23] <baltix-mantas> Hi launchpad developers
[08:23] <baltix-mantas> Is there any workaround for bug #602579 ?
[08:25] <wgrant> baltix-mantas: Sure, you can have your own version of pkgbinarymangler which whitelists your own PPAs
[08:25] <wgrant> grep for oem-archive in the pkgbinarymangler source
[08:27] <baltix-mantas> I found check for oem-archive in /usr/bin/pkgstripfiles :
[08:27] <baltix-mantas> if grep -q '/oem-archive' ${PKGBINARYMANGLER_APT_CONF_DIR:-/etc/apt}/sources.list; then             echo "INFO: Running pkgstripfiles for OEM PPA build"
[08:28] <wgrant> Right
[08:28] <wgrant> pkgbinarymangler is just a normal package, so you can have a custom one in your PPA
[08:28] <baltix-mantas> wgrant: I've created PPA, named oem-archive, see http://ppa.launchpad.net/~baltix/+archive/oem-archive
[08:28] <baltix-mantas> wgrant: but this doesn't help :(
[08:31] <wgrant> baltix-mantas: I think if you try again it will work
[08:31] <wgrant> baltix-mantas: Since the PPA indices don't exist on ppa.launchpad.net until a binary is published, Launchpad won't include the PPA in sources.list until there are binaries.
[08:31] <baltix-mantas> wgrant: cool
[08:31] <wgrant> So the first build won't have had 'oem-archive' anywhere in sources.list
[08:32] <baltix-mantas> wgrant: thanks for help, I will try again :)
[08:32] <wgrant> Great, I don't see why it shouldn't work
[08:32] <wgrant> (although I suggest you patch pkgbinarymangler, rather than using the oem-archive name hack!)
[08:33] <baltix-mantas> wgrant: I like to use official hacks ;)
[08:33] <baltix-mantas> if they works
[08:33] <wgrant> Heh
[08:34] <baltix-mantas> wgrant: thank you very much for hint, I will try now, bye
[09:11] <mantas-baltix> Please enable more amd64 builders - currently only 10 builders active and Queue is 500 jobs (22 hours), see https://launchpad.net/builders
[09:12] <mantas-baltix> While some amd64 builders are disabled, eg. https://launchpad.net/builders/akhlut and some others are idle.
[09:25] <mantas-baltix> wgrant: could you enable more amd64 builders - currently only 10 builders active and Queue is 500 jobs (22 hours), while i386 queue is only 57 minutes, see https://launchpad.net/builders
[09:25] <wgrant> I'll see what I can do.
[09:30] <mantas-baltix> wgrant: thanks, maybe you can enable https://launchpad.net/builders/akhlut or something :)
[09:32] <wgrant> It's a bit brokne
[12:05] <yaiza> hi! is is possible to rename a branch? Something like; lp:~ybailen/canonical-openerp/employee-registry-payroll -> lp:~ybailen/canonical-openerp/canonical-payroll
[12:05] <yaiza> I tried to do that clicking the "Change branch details"
[12:06] <yaiza> but then I got this error: "Private branches are not allowed for target Canonical OpenERP."
[12:06] <yaiza> and If I choose Personal as Target Branch I get this one "Only private teams may have personal private branches."
[12:11] <czajkowski> wgrant: ^^
[12:17] <czajkowski> yaiza: unsure about renaming branches, I dont think you can
[12:17] <czajkowski> most copy over to a new branch with the right name
[12:17] <mgz> rename does work, it's just privacy being fun.
[12:17] <czajkowski> mgz: fun :)
[12:18] <mgz> a fallback to `bzr branch lp:a lp:b` (ideally done within the datacenter) does work.
[12:41] <baltix-mantas> wgrant: Hi again, thanks for tip about retrying to build in oem-archive PPA, it seems this helps :)
[12:49] <baltix-mantas> Maybe someone can increase priority of my builds - I need to release new Baltix distribution version with fixed packages today, but must wait several hours, especially with amd64, see https://launchpad.net/~baltix/+archive/oem-archive/+build/3928929  https://launchpad.net/~baltix/+archive/oem-archive/+build/3928277
[12:55] <czajkowski> baltix-mantas: as wgrant said it's a bit broken today and you can see from our topic we do have some issues.
[12:56] <baltix-mantas> czajkowski: I'm asking about increasing priority of 2 my build - one time someone here helped me in this situation - launchpad admins can manually increase priority of some builds, right?
[12:57] <czajkowski> baltix-mantas: there is no need to keep changing the description of the bug please.
[13:09] <sinzui> yaiza, first change the branch to Proprietary, which is what the project says it requires the branch to be, then do the rename.
[13:09]  * yaiza tries
[13:10] <baltix-mantas> sinzui: maybe you can increase priority of these buids: https://launchpad.net/~baltix/+archive/oem-archive/+build/3928929  https://launchpad.net/~baltix/+archive/oem-archive/+build/3928277
[13:11] <baltix-mantas> It's "Build score", right?
[13:11] <TheLordOfTime> erm...
[13:11] <TheLordOfTime> whoops sorry, that msg was targetted elsewhere
[13:11] <sinzui> baltix-mantas, I don't have permission to do that. The policy for changing scores changed last month anyway.
[13:11]  * TheLordOfTime hates laptops
[13:12] <czajkowski> baltix-mantas: I did tell you already we're having some stuff going on at present
[13:13] <baltix-mantas> czajkowski: I did'nt understand you previously :)
[13:13] <czajkowski> baltix-mantas: ah well you could have said and I'd have made it clearer for you :)
[13:15] <yaiza> it's taking some time to be changed to Propietary, still processing
[13:26] <baltix-mantas> czajkowski: it seems your engish is too good for me ;) I'm not native english speaker, I started to learn english only in university ;)
[13:27] <czajkowski> baltix-mantas: no worries, here to help.
[13:30] <baltix-mantas> czajkowski: maybe you know aproximatly when problems in builders will be fixed or at least this my build will start: https://launchpad.net/~baltix/+archive/oem-archive/+build/3928929
[13:31] <baltix-mantas> There is a message "will start in 1 hour", but this message doesn't change for about a hour :(
[13:31] <czajkowski> baltix-mantas: the builder issue is an ongoing issue at present
[13:35] <yaiza> sinzui, which is the difference between Private and Proprietary?
[13:36] <sinzui> yaiza, private means contain personal information, like a your phone number. Proprietary means the data is owned by an organisation and it cannot be disclosed to non-organisational people
[13:37] <sinzui> yaiza, canonical's project are transitioning everything to Proprietary to make it clear who owns the data
[13:38] <baltix-mantas> I'm afraid, that after 2 hours I still see the same info: "Start in 1 hour" :(
[13:38] <yaiza> sinzui, ok, then I guess we will need to move this one to proprietary: https://code.launchpad.net/~canonical-isd-hackers/canonical-openerp/employee-registry
[13:40] <sinzui> yaiza, maybe more https://launchpad.net/canonical-openerp/+sharing says your project should only contain Proprietary branches
[13:40] <sinzui> You only need to do those that people are working with I think
[13:55] <yaiza> sinzui, then if I create a new branch now in that project it will be created as proprietary by default but I have to move existing ones, is this right?
[13:57] <sinzui> yaiza, not, move, just change the Information Type shown in the branch's privacy portlet
[13:57] <yaiza> sinzui, yes, sorry, that's what I meant
[13:58] <sinzui> yaiza, I might have a script that walks all the active branches in a project and changes their Information type to Proprietary.
[13:59] <yaiza> sinzui, don't worry, we can do that manually, we don't have many, but is it normal that it takes so much time to change their Information type?
[14:00] <sinzui> yaiza, branches are stacked on each other. Changing the base branch requires checking everything that is stacked on it. It is slow for large projects.
[17:55] <maxb> So.... lpia. I uploaded a hardy package, and it's nominally queued to build on lpia, but there are no lpia builders. I don't particularly care about lpia, but I would prefer it didn't register as "needs building" forever. Any suggestions? :-)
[17:56] <lifeless> wgrant: ^ ;)
[17:56] <cjwatson> maxb: I'll give you a builder for a bit.
[17:57] <maxb> cjwatson: no need, the build will probably fail anyway
[17:57] <maxb> I am just looking for hints on what people currently do if they bother to still update hardy
[17:57] <cjwatson> 106 jobs.  Heh.
[17:57] <cjwatson> We give lpia a builder or two every so often.
[17:58] <cjwatson> Don't really want to give it too many since the other queues are rather long.
[17:58] <cjwatson> (At the moment)
[17:58] <maxb> I wonder if declaring my package "Architecture: i386 amd64" will do something useful
[18:00] <maxb> I've deleted my package with the pending lpia build in the interest of not tying up resources with something that is likely to FTBFS
[18:04] <cjwatson> maxb: It should do.
[22:33] <mikal> Hi. I have done a project.searchTasks() to get a list of bug_tasks. I can see how to get to the bug from a task, but I can't see how to access the activity collection for each bug. Does anyone have an example of that laying around?
[22:36] <cjwatson> mikal: If you have a bug in the 'bug' variable, bug.activity is a collection of activity entries
[22:37] <cjwatson> e.g. in lp-shell: bug = lp.bugs[1000000]; bug.activity[0].message -> 'added bug'
[22:38] <cjwatson> the general thing to know is that for anything where the apidoc says foo_collection_link, you can access .foo in Python and you'll get a collection (which behaves more or less like an iterable)
[22:41] <mikal> Ok, so len works for .activty, but .activity[0] doesn't exist (list index out of range).
[22:41] <mikal> Ditto .activity[1]
[22:44] <lifeless> what about 'for thing in bug.activity: print thing' ?
[22:44] <mikal> That iterates zero things
[22:44] <lifeless> win'
[22:44] <lifeless> (not really)
[22:45] <mikal> The code is:
[22:45] <mikal> bugs = proj.searchTasks(modified_since=since)
[22:45] <mikal> for b in bugs:
[22:45] <mikal>     print b.title
[22:45] <mikal>     print len(b.bug.activity)
[22:45] <mikal>     print b.bug.activity[1].message
[22:45] <mikal> len here is 16
[22:45] <mikal> But I get the "list index out of range" for the last line
[22:47] <cjwatson> WFM with proj == lp.projects["ubuntu-archive-tools"]
[22:47] <mikal> This is with project "nova" and the bug title is "Bug #1062277 in OpenStack Compute (nova): "092_add_instance_system_metadata migration fails when upgrading""
[22:48] <cjwatson> Although rings a very very faint bell somewhere
[22:48] <cjwatson> I can get lp.bugs[1062277].activity[1] just fine
[22:50] <mikal> print launchpad.bugs[1062277].activity[1]
[22:50] <mikal> Gives me the same error
[22:50] <mikal> Would this be an anonymous login thing or something?
[22:51] <cjwatson> Ah - yes
[22:52] <mikal> Oh look, now it works
[22:53] <cjwatson> IBugActivity seems to have no particular security defined for it anywhere I can see, which I think means it defaults to ViewByLoggedInUser
[22:54] <cjwatson> So yeah, you'd have to be logged in to see it
[22:55] <cjwatson> mikal: bug 991079
[22:56] <mikal> Huh, cool
[22:56] <mikal> Thanks for your help
[22:56] <mikal> Now to work out how to use an activity object