[05:07] <thomi> Hi, I'm trying to create a build recipe for a python package. I have followed the packaging guide (https://wiki.ubuntu.com/PackagingGuide/Python), and can create packages manually, but when I try and run 'bzr dailydeb...' I get this error:  http://pastebin.com/8gKAgGKH
[05:07] <thomi> Can someone point me in the right direction please? I'm sure I'm doing something obviously wrong.
[05:13] <spiv> thomi: perhaps try asking #ubuntu-packaging ?
[05:15] <thomi> spiv: okay - The help pages for recipes say to ask here for help :) Cheers.
[05:15] <thomi> huh, could be I stumbled onto this bug: https://bugs.launchpad.net/launchpad/+bug/614768
[05:18] <antono> i think i should ask it here... for some reason launchpad places only readme in my amd64 package while i386 contains all needed files
[05:19] <antono> everything is ok when i build package locally on my amd64 host.
[05:19] <antono> if you interested you can look at my PPA: https://launchpad.net/~antono/+archive/rubinius/+packages
[05:33] <spiv> thomi: here is a reasonable place to ask, but it appears not many folks are awake in here atm
[05:33] <thomi> Cheers
[05:33] <spiv> thomi: (and your question is beyond what I know)
[05:34] <thomi> well, Once I found that bug report I was able to get it going. Now I have other issues to sort out ;)
[05:34] <wgrant> antono: Try 'dpkg-buildpackage -B' locally.
[05:34] <wgrant> antono: That should reproduce the conditions found on Launchpad's amd64 builders.
[05:36] <antono> wgrant: tying.
[05:36] <antono> it worked for me with debuild without options
[05:37] <wgrant> antono: debuild by default builds arch-indep packages too.
[05:37] <wgrant> But when building for multiple architectures you can only build them on one -- we build them on i386.
[05:37] <wgrant> -B requests that only architecture-dependent packages be built, as the non-i386 builders do.
[05:38] <antono> wgrant: thanks for expaination
[05:39] <antono> wgrant: okay. i got normal sized package with all included
[05:40] <antono> and it works locally
[05:45] <wgrant> antono: So you can't reproduce it locally?
[05:52] <wgrant> antono: That should have reproduced it locally, because I can see the bug.
[05:52] <wgrant> antono: You have binary depending directly on install.
[05:52] <wgrant> binary-arch and binary-indep should depend on install.
[05:53] <wgrant> Otherwise the separate builds will not have anything installed.
[05:53] <wgrant> Which is probably not what you want.
[05:53] <spiv> wgrant: interesting, why would that lead to different results for i386 vs amd64 though?  (I'm just randomly curious)
[05:54] <StevenK> Which is why it works on i386 and not amd64. i386 will call 'binary' and amd64 calls 'binary-arch'
[05:54] <wgrant> spiv: i386 builds arch-indep, so calls 'binary'
[05:54] <StevenK> Er, what wgrant said.
[05:54] <spiv> wgrant: ah
[05:54] <antono> wgrant: thanks!
[06:10] <antono> hey, have you considered idea of distributed build farm
[06:11] <antono> for example i have a lot of free resources on my local box and would like to contribute it to ubuntu and launchpad users
[06:11] <antono> so they can build their packages faster
[06:11] <lifeless> antono: yes, and rejected it
[06:11] <antono> lifeless: why?
[06:12] <lifeless> antono: its a matter of trust : we can't verify the output of the build without repeating the build.
[06:12] <antono> aha, right
[06:12] <lifeless> antono: and the output of the builds run on millions of users machines
[06:12] <antono> sure, i got it :)
[06:12] <antono> stupid me :)
[06:12] <lifeless> not at all
[06:13] <lifeless> it would be wonderful to find a solution
[06:13] <lifeless> many folk would contribute compute resources
[06:13] <antono> i know there is SETI@home project that uses p2p cloud for science
[06:14] <lifeless> right
[06:14] <lifeless> what they do is run the same calculation many times
[06:14] <lifeless> *and*
[06:14] <lifeless> they have a cheap[ish] verify function
[06:15] <antono> hmm. i should ask ubuntuone guys about p2p cloud ;)
[06:17] <antono> btw, anyone know about launchpad installation except launchpad.net ?
[06:17] <antono> *installations
[06:19] <lifeless> not really
[07:16] <thomi> Is there a delay between the first package being built via build recipe and it appearing on ppa.launchpad.net? My builds have finished, but my PPA doesn't exist yet.
[07:17] <StevenK> Did the recipe itself finish building or the source package from the recipe?
[07:18] <thomi> both, I think: https://code.launchpad.net/~sloecode/+recipe/bzr-sloecode-daily
[07:18] <wgrant> thomi: The PPA publisher might not be running at the moment. It stops for around an hour most days, about this time.
[07:18] <wgrant> I must fix that cron job.
[07:18] <thomi> wgrant: haha, thanks.
[07:20] <StevenK> thomi: Yes, it's waiting for the publisher. Looking at https://code.launchpad.net/~sloecode/+archive/ppa/+packages if you expand the package you can see 'i386 - Pending publication'
[07:21] <thomi> StevenK: ahh, thanks. I missed that.
[09:08] <mrevell> Good morning
[09:19] <antono> how can I build packages for different ubuntu versions in one PPA ?
[09:48] <bigjools> antono: you can either upload packages with different names (include the ubuntu series in the name) or you can upload to one series and use the Copy Packages page
[09:48] <bigjools> the former rebuilds for each series, the latter does not
[09:49]  * bigjools really needs to make this a FAQ
[10:00] <StevenK> Upload packages with different *versions*, and include the ubuntu series in the version
[10:02] <antono> bigjools, StevenK, thank you!
[10:02] <antono> anyway i figured out that maverick missing required dependency :(
[10:42]  * popey pokes stub with https://wiki.ubuntu.com/Membership/RegionalBoards/AsiaOceania
[10:43] <stub> popey: Ta
[14:39] <zyga> james_w, quick question,I have a package foo-2 that I uploaded to my ppa, the package failed to build because of missing dependency, the dependency turned out to be cyclic so I wanted to upload foo-1, then bar, then foo-2 again. This failed because foo-1 is older and foo-2 was already present. I removed foo-2, uploaded foo-1 and bar (this worked fine). Now the problem: when I upload foo-2 it says I cannot do it because the package is already accepted in "ubunt
[14:39] <zyga> u/lucid" and I need to modify the package. The actual message is: http://pastebin.ubuntu.com/580588/
[14:40] <james_w> zyga, are foo-1 and foo-2 two different versions of the same source package name? because uploading foo-1 shouldn't have worked
[14:40] <zyga> james_w, yes, and it did
[14:41] <james_w> odd
[14:41] <zyga> james_w, the ppa in question is ppa:zkrynicki/lava
[14:41] <james_w> but you have to upload zyga2
[14:41] <zyga> james_w,  foo-1 was python-testtools-0.9.4
[14:41] <james_w> to get past this error
[14:41] <zyga> the -2 was python-testtools-0.9.8
[14:41] <zyga> ok, let me try that
[14:42] <zyga> it's quite odd that I cannot push the package again really
[18:02] <psusi> it is not currently possible to log into launchpad on a headless server via a text mode browser is it?  or did that get fixed?
[18:22] <benji> psusi: it's mostly not possible, but this workaround might help you: https://bugs.launchpad.net/launchpad/+bug/586908/comments/5
[18:36] <lifeless> psusi: w3m should work fine
[18:41] <psusi> if I want to look up bugs in the launchpad api for a particular package in ubuntu, is there an easier way than calling launchpad.distributions['ubuntu'].current_series.getSourcePackage("package").searchTasks()?
[18:43] <lifeless> IIRC you can provide a target or sourcepackageindistro to searchTasks
[18:43] <lifeless> but I may be thinking of the python API which is slightly different
[18:44] <psusi> but searchTasks is a member of...wait... ohh... I can call searchTasks() on the main launchpad collection directly eh?
[18:44] <psusi> yea, I'm talking python api
[18:47] <psusi> I don't see an argument to specify the ubuntu/package part
[18:50] <lifeless> you can call searchTasks globally, ubuntu, distroseries, package, product, project group, project series, distro series
[18:51] <lifeless> psusi: but we haven't exposed this flexability as searchTasks parameters sorry
[18:51] <lifeless> so yes, launchpad.distributions['ubuntu'].current_series.getSourcePackage("package").searchTasks() is the Right Way
[19:09] <psusi> blast
[19:22] <lifeless> feel free to file a bug asking for less object traveral and more flexability
[20:33] <psusi> so I've got a collection of bugs returned from searchTasks().. how do you just get the count of bugs in it?
[20:50] <lifeless> psusi: len()
[21:12] <psusi> lifeless: got an exception: File "/usr/lib/pymodules/python2.6/lazr/restfulclient/resource.py", line 717, in __len__
[21:12] <psusi>     raise TypeError('collection size is not available')
[21:12] <psusi> TypeError: collection size is not available
[21:12] <lifeless> huh
[21:13] <james_w> if you are using an old version of launchpadlib then there was a bug that caused that erroneously
[21:16] <lifeless> james_w: happy thing-fixed-day : bug 707111
[21:16] <james_w> thanks
[21:16] <psusi> ohh... so basically the version on lucid is messed up?
[21:17] <james_w> psusi, possibly
[21:17] <james_w> psusi, try .total_len rather than len()
[21:17] <psusi> k... guess I'll try again at home on maverick... because I'm also getting an exception trying to call bug.newMessage()
[21:18] <psusi> exception calling .len, .total_nen, and just len(bugs)
[21:20] <StevenK> bugs.count() ?
[21:21] <lifeless> StevenK: thats storm isn't it?
[21:21] <StevenK> Probably
[21:21] <StevenK> While we're tossing out ideas, I thought I'd add mine
[21:25] <AfC> bugs.magically_fix()
[21:25] <AfC> StevenK, lifeless: [morning :)]
[21:25] <StevenK> Haha. Morning AfC
[21:26] <AfC> The worst part of IRC is coming in to conversations out of context. But then again, you get to come into conversations out of context, and that can be fun.
[21:26]  * AfC lets you get back to work
[21:27] <StevenK> Pff, I don't start for another 90 minutes, I'm bored while waiting for a delivery
[21:27] <lifeless> hi AfC
[21:28] <StevenK> I'm so tempted to export a magically_fix function from IBug that raises NotImplemented
[21:31] <StevenK> lifeless: Are we allowed to have easter eggs in the API? :-)
[21:31] <lifeless> StevenK: shrug :)
[21:32] <leonardr> StevenK: make sure you expose() that NotImplemented
[21:33] <lifeless> StevenK: wouldn't want it in the apidoc, that would really not be an easter egg ;>
[21:33] <StevenK> lifeless: I'm not sure how to export something to devel only but have the apidoc ignore it.
[21:34] <leonardr> anything you hide from the apidoc you will also hide from the client
[21:35] <StevenK> The sounds like a bug. "We do not support easter eggs"
[21:35] <leonardr> you can neglect to give it a docstring
[21:35] <StevenK> :-)
[21:36] <StevenK> leonardr: Last time I recall doing that, I seem to recall lazr.restful giving very odd exceptions due to the docstring not being formatted as it expected.
[21:36] <leonardr> it had no docstring at all, or an empty docstring?
[21:37] <StevenK> I think I was having trouble with an empty docstring, but I can't quite recall.
[22:24] <arand> Hello, I'm doing rebuilds of a ~450M game in https://edge.launchpad.net/~arand/+archive/redeclipse and I tend to run out of space every now and then, would it be possible to increase the quota?
[22:25] <arand> s/rebuilds/svn updates/
[22:44] <micahg> arand: file a question against launchpad
[22:45] <arand> micahg: Ok, cheers