[10:41] <johnl> hello. I'm getting chroot problem errors when trying to build packages on launchpad: https://code.launchpad.net/~ceph/+recipe/ceph-rc-builds
[10:42] <wgrant> johnl: Hi. That's a known issue that I landed a fix for a few hours ago.
[10:43] <johnl> ok great. I assume it's not deployed yet? (just got a fail a few minutes ago)
[10:44] <wgrant> johnl: It will hopefully be rolled out in the next day or two. For now you should be able to work around it by building the recipe into a PPA that had packages in it before the 9th of December.
[10:44] <wgrant> You can then copy it to the new PPA.
[10:46] <johnl> ok, super, thanks.
[10:47] <wgrant> The deployment is blocked on a few un-QA'd revisions before this fix, but it's nearly there.
[10:55] <lifeless> wgrant: has flacostes rolled back rollout been done now?
[10:55] <wgrant> lifeless: Yes.
[10:55] <wgrant> An hour or so ago.
[10:56] <wgrant> 12093
[10:56] <wgrant> Scripts are even working this time!
[10:56] <lifeless> o/
[13:15]  * lamont looks around for a backport of python-launchpadlib from lucid to hardy
[13:28] <MTecknology> From: "Dan@lbidecfcdf.{SPF_D1}" <Dan@lbidecfcdf.{SPF_D1}>
[13:28] <MTecknology> weirdest spam I've ever seen....
[13:29] <MTecknology> it's like someone is grabbing every user from ~ubuntu-members
[13:59] <MTecknology> allenap: how dare you change the topic!
[13:59] <MTecknology> btw- howdy helper :)
[14:23]  * CardinalFang hugs Launchpad.
[14:50] <allenap> MTecknology: Hi there :)
[14:50] <MTecknology> howdy
[14:52] <MTecknology> allenap: you good with design and planetplanet?>
[14:52] <allenap> MTecknology: Neither! What's up?
[14:53] <MTecknology> allenap: This is all I can come up with with my poor design skills (http://planet.nginx.org/) and I'm trying to make it actually look pretty
[14:58] <allenap> MTecknology: Ouch, that's ugly :) Personally, I would try switching to a sans-serif typeface and making the text bigger, then see how it looks. But, as I say, visual design is not really my domain.
[14:59] <MTecknology> allenap: :'(   I wrote that all from scratch
[14:59] <allenap> MTecknology: Sorry, I didn't mean to offend :)
[15:01] <MTecknology> allenap: you didn't, i know I'm not good with designing things. I can half way get there if I can picture it in my head, but that's what i can't do
[16:22] <zyga> hi, I seem to have damaged my branch
[16:22] <zyga> I had a branch, with debian packaging, stacked on top of the project trunk (technically, there was no actually common parts between the two)
[16:22] <zyga> I then changed the owner of both branches
[16:23] <zyga> and now it seems that the packaging branch is broken, I cannot bzr get it, I cannot bzr push to it
[16:23] <zyga> the branch is: lp:~linaro-infrastructure/django-render/packaging
[16:23] <zyga> it used to be ~zkrynicki
[16:23] <zyga> pushing to it causes: bzr: ERROR: Server sent an unexpected error: ('error', "Cannot lock LockDir(lp-57682896:///~linaro-infrastructure/django-render/packaging/.bzr/branchlock): File exists: u'/srv/bazaar.launchpad.net/mirrors/00/06/4e/64/.bzr/branch/lock': [Errno 17] File exists: '/srv/bazaar.launchpad.net/mirrors/00/06/4e/64/.bzr/branch/lock'")
[16:23] <zyga> getting says: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~zkrynicki/django-render/upstream/".
[16:24] <zyga> note - the getting error message still refers to the _old_ trunk (called upstream here) that was owned by my launchpad user
[16:24] <zyga> what can I do to recover?
[16:54] <berco> Hi, can a LOSA make PUBLIC our PPA "TI OMAP trunk PPA" https://launchpad.net/~tiomap-dev/+archive/trunk? It has been created as private by mistake, we (TI) already have a trunk PPA marked private called "TI OMAP private trunk PPA". Thanks.
[16:56] <allenap> zyga: I'll find someone who can help you.
[16:56] <allenap> abentley: Would you be able to help zyga out with a branch issue?
[16:57] <abentley> allenap, I believe the user should be able to change a private branch to public.
[16:58] <allenap> zyga: See abentley's reply. Does that make sense?
[16:59] <zyga> abentley, that was not a private branch
[16:59] <zyga> allenap, abentley: I resolved the issue by deleting the packaging branch and uploading it again to ~linaro-infrastructure team
[17:00] <zyga> but I suspect it's a lp bug
[17:00] <zyga> I got bit by this once before
[17:02] <Chex> berco: sure, give me a  couple
[17:03] <abentley> zyga, sorry.  I'm only used to being asked about branches.
[17:03] <berco> Chex: thanks a lot
[17:13] <Chex> berco: ok, all set, the PPA is public now.
[17:15] <berco> Chex: thanks
[17:31] <berco> Chex: I still see "TI OMAP trunk PPA" in private. Does it need some time to update?
[17:37] <Chex> berco: hrrm , looking
[17:38] <Chex> berco: oh, sorry, am getting this error, which is a bit odd ' This archive already has published sources. It is not possible to switch the privacy. '
[17:39] <Chex> berco: makes sense when going public to private, but not the way your going..
[17:51] <berco> Chex: Does it mean we cannot switch from private to public? just wanna make sure I understood
[17:56] <Chex> berco: I am trying to figure that out, let me get back to you
[17:57] <berco> Chex: okay, thanks. I'll need to leave the office but keep me posted here.
[18:14] <evaluate> hello
[18:17] <evaluate> I have a PPA and I would want to make the package available for both maverick and natty, but if I upload it with the same version number it doesn't work. Do I need to make sepparate PPAs for different distros or is there another trick?
[18:26] <maxb> evaluate: You should not make separate PPAs, rather, you should upload with different version numbers. You should take care that the version numbers sort correctly maverick < natty, such that someone upgrading from maverick to natty also sees the upgrade of your package
[18:27] <evaluate> maxb, ok, so for example for maverick I name it -1ubuntu1 and for natty -1ubuntu2?
[18:27] <maxb> evaluate: please don't :-)
[18:27] <maxb> As a good rule of thumb, never construct your PPA version numbers to look like they are official archive packages
[18:28] <evaluate> umm
[18:28] <maxb> It's good to not be misleading
[18:28] <evaluate> ok :p
[18:28] <evaluate> so then -1 and -2?
[18:29] <maxb> Then they look like official Debian version numbers :-)
[18:29] <maxb> Generally, I use something like -0ppa1maverick1
[18:29] <evaluate> ugh, is there a common convention then? :-)
[18:30] <evaluate> ohh, right, using the distro names, caus they are also alphabeticall. Didn't think about that one :-)
[18:30] <evaluate> maxb, thank you!
[18:30] <maxb> in which the zero says it's not based on a specific Debian packaging, the first 1 suggests the version of the base packaging, and the final 1 is what I would increment if fixing a problem in a single series build
[18:31] <evaluate> maxb, is there a way to delete a package that I already uploaded?
[18:31] <evaluate> caus it already contains -1 :-)
[18:32] <maxb> You can delete packages in the web ui, but making version numbers go downwards is usually not a good thing
[18:32] <maxb> is it a package which is *actually* in debian?
[18:32] <maxb> If not, I'd just keep the 1 until the next upstream version happens, and drop it to a 0 at that point
[18:32] <evaluate> I just uploaded it 5 minutes ago, it didn't even build yet. Could you please tell me where exactly I could delete it? I can't seem to find that feature...
[18:33] <evaluate> maxb, it's waiting in the NEW queue currently. They are pretty busy with the release apparently... :p
[18:34] <maxb> Oh, well, if your ppa packaging is actually based on a real debian upload, then yes, I'd base the version number on that version
[18:35] <maxb> Chex, berco: There's no detail in it whatsoever, but bug 376072 exists :-/
[18:35] <evaluate> ok then, -1 it is.
[18:35] <evaluate> thanks again maxb
[18:39] <Derixx> I have rm some packages in a ppa a few days ago. Now I want to copy packages with the same name to that ppa, but it says that there is already such packages :/
[18:39] <Derixx> it isn t
[18:39] <Derixx> it's removed!
[18:39] <maxb> same name *and* same version?
[18:42] <Derixx> right
[18:42] <maxb> A package name&version may be deleted, and is removed from disk and from the repository indexes, but a name&version can never be reused, even when deleted
[18:43] <Derixx> bug
[18:43] <maxb> This is to ensure the horrifically confusing situation of a single version referring to two different builds of a package, never arises
[18:43] <Derixx> arghhh
[18:43] <maxb> No, feature.
[18:43] <maxb> It's quite deliberate, I assure you
[18:44] <Derixx> it sounds like a 'hack' instead of a feature
[18:45] <Derixx> anyway, this isn't experienced as nice behavior by me... but alas, it is as it as atm...
[18:45] <maxb> Well... a version number is supposed to uniquely identify a version - pretty much by definition
[18:45] <maxb> It's not really a hack to strongly enforce that
[19:01] <evaluate> maxb, do you have the ability to delete a package forcefully?
[19:01] <evaluate> The package I deleted still appears in the build queue...
[19:06] <maxb> evaluate: That's fine, the build will be cancelled automatically when it reaches the head of the queue
[19:06] <evaluate> maxb, ok then.
[20:59] <bdmurray> bdrung: I'm not finding the lp-set-dupe bug in ubuntu-dev-tools easily
[21:00] <bdrung> bdmurray: it was closed
[21:01] <bdrung> bdmurray: it was bug #576477
[21:02] <bdmurray> bdrung: okay, some of the code in there is is unnecessary now as launchpad handles marking a bug w/ duplicates as a duplicate of another now
[21:12] <mgariepy> hello, i'm having a weird bug with a ppa
[21:12] <mgariepy> the package is published on lp but when i do apt-get update, apt-cache search i can't find the package
[21:13] <mgariepy> deb http://ppa.launchpad.net/revolution-linux/ppa/ubuntu hardy main
[21:13] <mgariepy> and the package is bzr-inotify
[21:13] <mgariepy> https://launchpad.net/~revolution-linux/+archive/ppa
[21:17] <thumper> mgariepy: that ppa doesn't appear to have bzr-inotify in it
[21:19] <mgariepy> thumper, the package is present on https://launchpad.net/~revolution-linux/+archive/ppa?field.series_filter=hardy