[01:10] <Fudge> hi does the lp team  manage the http on developer.ubuntu.com
[01:20] <huwshimi> Fudge: No, they do not.
[01:37] <Fudge> huwshimi  thank you mate
[01:37] <Fudge> are there packaging classes or help channels on freenode?
[01:37] <lifeless> Fudge: there is #ubuntu-packaging
[01:37] <Fudge> lifeless  thanks :D
=== 18WABEXNJ is now known as jhesketh
[02:06] <jhesketh> Hi there
[02:06] <jhesketh> I'm new to building deb packages and I'm having some trouble with the dailybeb builder
[02:06] <jhesketh> Is this the right place to ask for some help?
=== jamesh__ is now known as jamesh
[02:07] <lifeless> jhesketh: kindof :) we'll steer you in the right direction if needed
[02:17] <jhesketh> cool, thanks
[02:17] <jhesketh> so the log is here: https://launchpadlibrarian.net/109349210/buildlog.txt.gz
[02:18] <jhesketh> it seems to build okay on my machine but it only builds a .tar.gz using bzr dailydeb
[02:19] <jhesketh> the confusing part is the error looks like it is failing in the debian build:
[02:19] <jhesketh>   File "/var/lib/python-support/python2.5/debian_bundle/changelog.py", line 222, in parse_changelog
[02:19] <jhesketh>     for line in self._file.split('\n'):
[02:24] <lifeless> thats verra odd
[02:24] <lifeless> let me consult.
[02:24] <lifeless> wgrant: ^
[02:26] <wgrant> lifeless: There's a bug for that.
[02:26] <wgrant> Recipe version 0.3 works, 0.4 does not
[02:26] <wgrant> Try just reverting to 0.3
[02:26] <wgrant> jhesketh: ^^
[02:26] <jhesketh> thanks wgrant, will do in a minute :-)
[02:27] <wgrant> Bug #915505
[02:27] <ubot5> Launchpad bug 915505 in launchpad-buildd "bzr: ERROR: exceptions.AttributeError: 'cStringIO.StringI' object has no attribute 'split'" [Critical,Triaged] https://launchpad.net/bugs/915505
[02:40] <Fudge> do openpgp keys have a private pair that should be kept?
[02:52] <jhesketh> ok, that's now building... however my recipe is only building a source only upload. How do I get it to create a .deb ?
[02:54] <StevenK> It will build the source package next
[02:58] <wgrant> jhesketh: The recipe builds a source package, and then the source will be built into binaries.
[02:59] <jhesketh> thanks guys, I think it was because I have a mistake in my control file
[03:10] <jhesketh> Hmm, now it's failing to upload with: Unhandled exception processing upload: too many values to unpack
[03:10] <jhesketh> Any thoughts what that might be? https://code.launchpad.net/~eexam-core/+archive/eexam-repo/+recipebuild/265089
[03:14] <wgrant> jhesketh: Your Section is wrong
[03:14] <wgrant> http://bazaar.launchpad.net/~eexam-core/eexam/daemon-packaging/view/head:/debian/control
[03:14] <jhesketh> right, I just played around with that. What should I be using?
[03:14] <jhesketh> ppa or something?
[03:14] <wgrant> 'Utilities (universe)' doesn't make sense. You might mean 'utils'
[03:15] <wgrant> http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
[03:15] <wgrant> It's in a PPA, so you shouldn't specify a component like universe.
[03:16] <jhesketh> ok thanks :-)
[03:26] <jhesketh> wgrant: Thanks for your help. It seems to be building successfully now :-)
[03:32] <wgrant> jhesketh: Excellent.
=== matsubara-afk is now known as matsubara
=== czajkowski changed the topic of #launchpad to: Help contact: czajkowski | Launchpad is an open source project:  https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad | For packaging help: join #ubuntu-packaging
=== tkamppeter_ is now known as tkamppeter
=== zyga is now known as zyga-afk
=== matsubara is now known as matsubara-afk
[10:58] <khizer_\> looking for openerp developers in India can anyone help?
[11:01] <czajkowski> khizer_\: not sure this is the right place for that kinda of help
[11:02] <khizer_\> hmm any suggestions?
[11:04] <czajkowski> khizer_\: a quick google shows http://www.openerp.com/irc/
[11:05] <khizer_\> thanks a lot
=== zyga-afk is now known as zyga
[13:15] <herton> hi, we are getting an unusually high repository size usage at canonical-kernel-team ppa (https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages). Right now is 24GiB, but even before with more packages it used less, we are hitting this first time this week.
[13:15] <herton> Any known problem?
[13:16] <herton> in fact using 23.4 GiB right now
[13:17] <czajkowski> herton: not heard of any issues with ppas
[13:18] <czajkowski> allenap: any idea where I could find that kinda issue out for herton ?
[13:19] <allenap> czajkowski: bigjools or wgrant would be the first people I would ask.
[13:19] <allenap> czajkowski: Failing that, it should go to the maintenance squad I think.
[13:19] <czajkowski> allenap: cheers
[13:19] <czajkowski> jam: ping
[13:20] <jam> czajkowski: opng
[13:20] <czajkowski> jam: can you help looking into herton issue ?
[13:24] <herton> czajkowski, jam: thanks. I just found it strange that we need so much space now, usually before that ppa with 16GB was enough for the packages, and we had more packages before sometimes, just making sure there isn't something else going on
[13:24] <czajkowski> well I've just increased your PPA also
[13:24] <herton> we even did a major cleanup on tuesday of old packages, and even with that we hit the size limit again today
[13:24] <czajkowski> as per the request on answers.
[13:25] <herton> czajkowski, yep, luis henriques told me now
[13:33] <jam> herton: it appears to be involving a rather large number of packages all the way back to hardy, is there a reason you need hardy packages?
[13:34] <herton> jam, yes, hardy is still in support, we have to produce kernel updates for it
[13:35] <jam> herton: powerpc as well?
[13:35] <jam> (and spac)
[13:35] <jam> sparc
[13:36] <herton> jam, nothing changed for hardy that we know of, I think sparc and powerpc builds were always done
[13:38] <herton> if the account of all packages is fine, then no problem. Just find strange that we hit this problem now. May be because of the addition of precise and armadaxp packages we got an size increase. But previously we had maverick that is not more produced, and fsl-imx51 and mvl-dove packages for lucid, and never surpassed the 16GB mark, even with hardy being pushed
[13:39] <henrix> herton: jam: yeah, there's a difference in this cycle: the hardy lum/lbm/lrm src packages. and lrm in particular is quite big (src pkg itself has ~150MB, iirc)
[13:40] <henrix> i have never prep'ed these 3 packages for hardy i believe
[13:40] <henrix> not sure if these make the difference, though
[13:42] <jam> henrix: so just looking at the hardy 'linux-image' files, is about 500MB
[13:42] <jam>        linux-image-3.2.0-27-omap-dbgsym_3.2.0-27.42_armel.ddeb          (289.6 MiB)                 linux-image-3.2.0-27-omap-dbgsym_3.2.0-27.42_armhf.ddeb          (289.5 MiB)
[13:42] <jam> henrix: ^^ ?
[13:42] <jam> omap-dbgsym is about 10x larger than the next largest ones
[13:43] <jam>        linux-image-3.2.0-27-virtual-dbgsym_3.2.0-27.42_amd64.ddeb          (628.9 MiB)                 linux-image-3.2.0-27-virtual-dbgsym_3.2.0-27.42_i386.ddeb          (636.9 MiB)
[13:43] <jam> each 600+ mb
[13:43] <henrix> debug symbols, i guess that's normal
[13:43] <jam> so each of those files is the size of all of hardy
[13:43] <jam> henrix: the hardy debug images are only 20MB
[13:43] <jam> not 600
[13:44] <jam> I'm not sure what virtual vs omap is.
[13:44] <henrix> omap is for ARM (mainly pandaboard)
[13:45] <jam> ah, generic is also 600MB, etc.
[13:45] <jam> henrix: so you have about 10 of those 600MB files, that gets you a lot of the 24G quota
[13:45] <herton> henrix, hmm, there was some patch from Chris for debug packages, that may account for the big size on precise now
[13:45] <jam> I don't really know what to say about it. If you need them, then we need the space...
[13:46] <jam> herton: there doesn't seem to be any 'dbgsym' files in Oneiric
[13:46] <jam> ah nm, just needed to search farther, just a sec
[13:46] <henrix> herton: ah, that's true! i remember now. but... these sizes (~600MB) look correct to me. does this mean we were not building them before?
[13:46] <herton> jam, we always had debug packages, yes someof them are large
[13:47] <herton> but we had some change in this cycle on precise, that may have increased size of precise pkgs
[13:47] <jam> herton: in Lucid they are more like 400M, in NOP they are 600+MB, they aren't in H that I can see.
[13:49] <jam> herton, henrix: So I can help you figure out why you're consuming space, I'm not really in the place to say whether it is needed or not, or whether you can just increase your limit.
[13:50] <henrix> ok, i'll try to figure out if chris's patch is responsible for this.
[13:50] <jam> I see a bunch of stuff published within the last day
[13:51] <jam> and I can imagine that there is a period of time where you have CURRENT and OLD at the same time
[13:51] <jam> (if not OLD+1... as well)
[13:51] <herton> jam, thanks. The tendency with newer kernels is for debug packages to be large, since there are more code etc. Just this suddenly this space usage was strange, but we will try to investigate more. We always produced the debug packages as far as I know
[13:51] <jam> I'm told we expire fairly strongly
[13:51] <jam> herton: sure, nothing stands out to me as vastly different than before
[13:52] <jam> my best guess would actually be something about not expiring fast enough.
=== zyga is now known as zyga-afk
=== zyga-afk is now known as zyga
[15:08] <joey> jam: are you the right person to escalate bzr issues to?
[15:09] <joey> jam:  "bzr broke a few months ago and will no longer merge between the lp:gcc/4.7 and lp:gcc-linaro/4.7 branches."
[15:09] <joey> czajkowski: ^^
[15:10] <joey> jam: I'm working on getting the bug number for that
[15:10] <mgz> 'broke' is helpful.
[15:10] <joey> jam: I do have the traceback in an email
[15:11] <joey> jam: and I have the manual merge instructions here:  https://wiki.linaro.org/WorkingGroups/ToolChain/BzrTips#How_to_do_a_manual_bzr_merge_when_.22bzr_merge.22_fails
[15:11] <czajkowski> joey: with bzr stuff I tend to look to the blue squad they know it pretty well :)
[15:12] <joey> Yeah, although I find the whole squad idea to be awkward :-)
[15:13] <czajkowski> joey: nope I love it!
[15:13] <czajkowski> it's really cool to see and can keep a team motivated
[15:13] <joey> ah well I'm glad it's working then
[15:13] <joey> :-)
[15:24] <ailo> Hi, I'm trying to forward bug reports to a mail list at lists.ubuntu.com. I tried using the list as a contact adress, but that didn't seem to work.
[15:25] <czajkowski> ailo: why are you doing that ?
[15:25] <ailo> I'm using a team to subscribe to bug reports, and would like them to be forwarded to a mail list
[15:26] <czajkowski> ailo: anyone subscribed to the bug can get the bug mail, plus they can also edit their settings
[15:26] <czajkowski> do you own the team ?
[15:26] <ailo> The team is ~ubuntustudio-bugs, and the mail list is also ubuntustudio-bugs@lists.ubuntu.com. I am admin of both
[15:26] <czajkowski> so the team being added will be enough
[15:27] <czajkowski> then a person can control their own bug mail
[15:27] <ailo> I realize that, but I would still like to know if it is possible to redirect bug reports to a mail list at lists.ubuntu.com
[15:27] <ailo> How does Ubuntu do it?
[15:28] <czajkowski> I dont know of any such list tbh,
[15:28] <czajkowski> can you give me an example
[15:29] <ailo> You don't know of ubuntustudio-bugs, or ubuntu-bugs?
[15:31] <czajkowski> I know of the latter
[15:31] <czajkowski> there is a bug squad for it
[15:31] <ailo> ubuntustudio-bugs was created this week
[15:32] <ailo> http://lists.ubuntu.com/mailman/listinfo/ubuntustudio-bugs
[15:32] <czajkowski> ailo: I still don't understand why you won't just add people to that team, and then sub the team, and then let people chose how much bug mail they wish to get.
[15:33] <ailo> Well, that was not what I was asking for
[15:33] <ailo> I'm looking at this possibility, and just trying to see if it is posible, and how
[15:35] <ailo> Seems like it's working now
[15:36] <sinzui> ailo, Lp does not support redirects. You can set that address as a team's contact address and Lp will ask you to confirm you control the address. After that, you can subscribe the team to bugs to get all bug mail.
[15:37] <ailo> Yep, that's what I did. I was just confused about the test mails I got. I now see that there is a bounces@canonical.com in the header
[15:37] <ailo> I thought I was getting them directly from launchpad
[15:37] <sinzui> ailo, We advise you not to do that. ubuntu-bugs's approach is the leading cause of private  email addresses being leaks to the world
[15:37] <sinzui> people will hate you
[15:38] <ailo> sinzui: So, how does that happen?
[15:38] <czajkowski> sinzui: indeed, am less likely to be involved in a team that does that
[15:39] <sinzui> Your list archive  is a public archive. any spammer can scrape the pages to collect email address in the body of the page
[15:41] <ailo> Ok, so it's not something specific to launchpad. More like a general problem with public mail lists
[15:41] <sinzui> ailo, correct.
[15:42] <sinzui> Users should subscribe to get email, not teams. In your case, you are at least redirecting the team emails to an address to reduce unwanted email, but the emails are stored in a public location :(
[15:44] <ailo> What is the best way to filter emails from launchpad teams?
[15:47] <ailo> I'd say the problem is hard to get around either way, since probably anyone wanting to subscribe to bug reports will likely be subscribing to a public email list anyway
[15:47] <ailo> I guess this header is a good one for bug reports: X-launchpad-bug: product=ubuntustudio;
[15:49] <ailo> Would be great to have a header specific to the team also. Maybe there is?
[15:53] <ailo> There's a nice help section on launchpad bug reports here V
[15:53] <ailo> https://help.launchpad.net/Bugs/Subscriptions/#Bug_mail_headers
[15:53] <ailo> As an alternative to a mail list, it might do ok
=== matsubara-afk is now known as matsubara
=== heroux_ is now known as heroux
[18:09] <rmk> Running into an issue whereby I request a forgotten password, then receive an email stating the account doesn't exist.  However, I know the account exists, I just sent a message via launchpad and it arrived at the exact email address I am using to retrieve the password.
=== zyga is now known as zyga-afk
[18:45] <dobey> rmk: what launchpad username?
[18:53] <lifeless> rmk: dobey: LP doesn't handle passwords at all.
[18:54] <lifeless> Thats Ubuntu SSO, there is a link to their support forums on the login.launchpad.net /login.ubuntu.com pages. Or you can see #canonical-isd on this IRC server.
[18:54] <lifeless> rmk: ^
[18:54] <dobey> right
[18:54] <lifeless> rmk: the reason LP knows your email and SSo doesn't is that you've added it to LP to your account, but not to SSO.
=== Guest54097 is now known as dpb__
=== dpb__ is now known as dpb___
[19:40] <dobey> rmk: ^^ see what lifeless said
[19:40] <rmk> I see, ok thanks.
=== matsubara is now known as matsubara-afk
=== zyga_ is now known as zyga
[21:50] <ivaldi> hi - i have some issue with the LP api - http://pastebin.com/i5n5jDJr - why is len(activities) == 35 when activities itsel is actually empty (or more precisely: why is activites is empty even when it shouldn't)?