[07:30] <jmarsden> I've got a bzr recipe that doesn't build on LP, giving what looks like a quilt-related error.  I'd appreciate help fixing it.  https://code.launchpad.net/~lxde/+recipe/lxterminal-daily produces the error "tar: recipe-0.1.9/.pc/01_create_POTFILES.skip.patch/POTFILES.skip: Cannot open: Permission denied" in https://launchpadlibrarian.net/74175712/buildlog.txt.gz
[07:52] <maxb> jmarsden: Hmm. It's probably worth retrying the build - this smells like it could be something like a bad umask setting or something alike on the builder node that processed your build
[07:53] <jmarsden> maxb: Tried on natty and oneiric, same result: https://launchpadlibrarian.net/74174459/buildlog.txt.gz
[07:58] <jmarsden> Trying rebuilds for both now, just in case...
[08:07] <maxb> hmm
[08:07] <maxb> Failed on thallium too
[08:07] <maxb> I don't know what to make of this
[08:07] <maxb> It seems more like an infrastructure failure than anything wrong with your recipe
[08:09] <maxb> bug 760735
[08:10] <wgrant> I'm not sure that's it.
[08:10] <wgrant> It's related.
[08:11] <maxb> it looks very much the same bug as jmarsden's buildlogs
[08:12] <wgrant> ... fair point, I can't read.
[09:23] <bac> Riddell: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[09:24] <bac> Riddell: it has landed here https://qastaging.launchpad.net/
[11:01] <lag> When you delete a package, does it go instantly?
[11:02] <wgrant> lag: no, it can take up to half an hour to be removed.
[11:03] <wgrant> lag: And you can't ever reupload the same version to that archive again.
[11:03] <spiv> wgrant: you missed a chance to say "lag: there's some lag" :P
[11:03] <wgrant> True.
[11:03] <wgrant> I blame jetlag.
[11:05] <lag> I always get the blame for people being tired after a sprint :(
[11:05] <lag> It's annoying that you can't use the same version number
[11:06] <wgrant> Why do you want to?
[11:06] <wgrant> To use it again would be a lie.
[11:07] <lag> Because I'm starting again
[11:07] <spiv> wgrant: so is 'bzr uncommit' :P
[11:07] <wgrant> spiv: And we don't normally do that on public branches :)
[11:08] <wgrant> Also, bzr won't get confused by identical revnos, but apt will get confused by identical versions.
[11:40] <pmjdebruijn> hi all
[11:40] <pmjdebruijn> we're considering a commercial launchpad subscription
[11:42] <pmjdebruijn> however, I'm wondering how private PPAs work? are they just publicly unlisted? or do they have long obscure URLs to "protect" them, or are they htaccessed or something?
[11:44] <lifeless> pmjdebruijn: htaccessed more or less
[11:44] <lifeless> pmjdebruijn: you subscribe people one by one
[11:44] <lifeless> they get a unique access key for that ppa subscription
[12:14] <hrw> hi
[12:14] <hrw> is it normal that launchpad is unable to set 'fix released' for debian tracked bugs?
[12:14] <hrw> bug 739151 is fixed in ubuntu (fix released status) and in debian (fix commited status)
[12:14] <hrw> and it got closed in debian on 11 May 2011 so thats why I wondered
[12:15] <lifeless> hrw: yes
[12:15] <lifeless> hrw: or rather, the tracker seems to have an issue atm
[12:15] <lifeless> we have a high pri bug to look into it
[12:15] <hrw> ok, thanks
[12:15] <lifeless> gmb: you know about this stuff :P
[12:17] <gmb> ORLY?
[12:17] <gmb> Oh godsdammit.
[12:17] <gmb> THat.
[12:48] <hrw> bye
[14:59] <czajkowski> mrevell: having fun!
[15:00] <mrevell> Hey czajkowski. It's going well so far, thanks :)
[15:00] <czajkowski> git I'm there next week
[15:00] <StevenK> Good, then most of us will be gone. :-P
[15:01] <mrevell> We don't say "git" in this channel, we say "bzr".
[15:01] <mrevell> :)
[15:01] <mrevell> czajkowski, Ah, it's a shame you're gonna miss the meet-up tomorrow.
[15:02] <czajkowski> StevenK: charming! fecker!
[15:02] <czajkowski> mrevell: yes but you are a git :)
[15:02] <mrevell> heh
[15:02] <czajkowski> mrevell: next time you're in London if you dont say hi I will throttle you
[15:02] <mrevell> haha
[15:02] <czajkowski> I live in spitting distance of millbank now
[15:02] <mrevell> Okay, it's a deal. You don't throttle me, I'll say hi.
[15:02] <mrevell> Oh yeah? Cool. I'll let you know next time I'm down.
[15:02] <czajkowski> fair deal really
[15:02] <mrevell> I think I come out of the deal pretty well.
[15:02] <czajkowski> yeah live across the water london eye from my room here
[15:03] <mrevell> Nice
[15:03] <StevenK> czajkowski: :-)
[15:05] <czajkowski> mrevell: plus my team are having a special ubuntu hr for me returning next week :) so meh :p
[15:14] <SteveExodus> the absolute bare-arsed minimum package that debuild seems to be happy to make is a directory with NEWS and README in it .. and debian
[15:16] <bjwebb> hi, is this a good place to ask about ppa builds?
[15:16] <StevenK> What about them
[15:16] <StevenK> ?
[15:17] <bjwebb> why they fail
[15:18]  * SteveExodus grins
[15:18] <bjwebb> more specifically, if there's an easy way to build my package locally in the same way, so i can debug
[15:18] <SteveExodus> fakeroot debian/rules
[15:18] <tsimpson> !pbuilder
[15:18] <StevenK> tsimpson: Thanks! I was just trawling my brain for that link.
[15:19] <bjwebb> ahh
[15:19] <tsimpson> if it builds in pbuilder, it will likely build on LP, both run in a clean chroot etc
[15:21] <bjwebb> okay
[15:22] <SteveExodus> fakeroot debian/rules is a quicker test ... doesnt setup a complete new environment
[15:23] <StevenK> But it can mask problems.
[15:23] <SteveExodus> indeed .. but maybe OP wants to solve basic problems like me and get INSTANT turnaround
[15:24] <bjwebb> i think pbuilder is what i want. building the standard way seemed to work fine
[15:25] <SteveExodus> imo it is too slow to solve newbie problems
[15:25] <SteveExodus> first fakeroot since it is instant .. then pbuilder I think for proper .. then lp for proper proper
[15:26] <tsimpson> if you start a new pbuilder for every change you make, then it's slow, but you can script pbuilder to drop you into a shell on build failure
[15:26] <tsimpson> then it's just as fast as anything else you would do
[15:27] <SteveExodus> undestood .. but fakeroot costs little or nothing to setup ... can be used to trial many things instantly
[15:28] <tsimpson> yep
[15:28] <bjwebb> is there a good way to do local mirroring on the fly?
[15:33] <tsimpson> bjwebb: I haven't used it in a while, but I did setup mini-dinstall to create a local apt repo with the packages I built
[15:34] <bjwebb> tsimpson: i don't mean for the packages i built atm. just for caching multiple hits to download packages from the main repos
[15:36] <tsimpson> bjwebb: I see a few in the archive, like approx, apt-cacher, apt-cacher-ng and apt-proxy
[15:36] <bjwebb> thanks
[16:27] <doko> jelmer: skaet did ask about the possibility of a manual import for gcc/4.6
[16:28] <jelmer> doko: We should be able to do that
[16:28] <doko> jelmer: that would be nice, avoids us uploading the new compiler after feature freeze
[16:35] <doko> jelmer: could you confirm, if/when you start the import?
[16:38] <jelmer> doko: I'm currently pulling down what's already on launchpad, will keep you informed of the progress.
[16:39] <doko> jelmer: thanks!
[16:40] <dbart> I have an account subscribed to several trees in launchpad (configured to receive branch revision notification emails), and it hasn't received any emails since yesterday (the last email it received was dated 27 Jun 2011 15:19:13 +0000 (UTC)) and I know there have been a few branch revisions since then... is there any known current issue with launchpad notification emails?
[16:45] <poolie> dbart: not that i know of
[16:53] <dbart> poolie: ok :(
[16:54] <poolie> are you getting other mail from lp?
[16:54] <dbart> this account is not
[16:54] <poolie> no mail at all?
[16:55] <poolie> i would guess it's some kind of antispam thing at some point then
[16:56] <dbart> it's a special account for our automated test system, it watches for branch revision notification emails from launchpad and runs tests after each push
[16:57] <dbart> my personal launchpad account is receiving my launchpad mailing list emails just fine (same mail server)
[17:14] <jelmer> doko: the import is now in progress (600/26k revisions at the moment)
[17:22] <SteveExodus> any pointer to the best way to package a python module .py and .so?
[17:24] <jelmer> SteveExodus, please ask in #ubuntu-packaging
[17:26] <SteveExodus> jelmer: thanks
[17:29] <pcrews> Hi - does an admin still need to directly set team / project / branch / bug privileges to private for commercial users?
[18:24] <poolie> pcrews: i think yes
[18:31] <pcrews> poolie: ack, gracias : )
[22:05] <tumbleweed> meh, hitting lots of launchpad timeouts on APIs tonight
[22:07] <mhall119> I need help writing a bzr-builder recipe
[22:07] <mhall119> I currently have http://paste.ubuntu.com/634566/
[22:08] <mhall119> but I was told I can use one reciple and one package branch to build package for multiple distros/releases
[22:09] <nigelb> mhall119: everyone except lifeless is probably in dublin ;)
[22:09] <tumbleweed> mhall119: the releases to build for are an option on the build recipe page (assuming your source packages will be buildable on all releases)
[22:10] <mhall119> tumbleweed: doesn't the release name have to be in the changelog though?
[22:10] <mhall119> or no?
[22:10] <tumbleweed> mhall119: no, it'll take care of that
[22:10] <mhall119> oh cool
[22:10] <mhall119> so what should I have in my changelog then?
[22:12] <tumbleweed> whatever you want, I think it adds an entry when it does the recipe build
[22:12] <mhall119> ok
[22:13] <mhall119> I like that loco-directory is used in the bzr-builder examples....
[22:51] <gustonegro> is there a way I can just import another package from a launchpad ppa into my launchpad ppa?
[22:51] <gustonegro> I see that this person has a package in his ppa from another lp ppa: https://launchpad.net/~xapantu/+archive/euclide
[22:55] <gustonegro> oh, +copy-packages was my friend