[01:23] <scientes> how do i turn off launchpad annoying me with my own bugs?
[01:23] <scientes> nvm
[02:40] <slick666> hello LP team
[02:40] <slick666> I was hoping to get a pointer on how to move a personal branch into a team branch
[02:40] <slick666> I think I'm just googleing the wrong terms and not finding this
[02:41] <thumper> hi slick666
[02:41] <thumper> let me just check
[02:41] <thumper> see if it is still the same
[02:42] <slick666> cool
[02:42] <thumper> slick666: go to the branch
[02:42] <thumper> slick666: on the right hand side, click the change details
[02:42] <thumper> slick666: you can then specify the owner with a drop down select box
[02:42] <slick666> ah I see it and follow
[02:42] <slick666> oh cool
[02:42] <thumper> slick666: I think the reason we didn't have an ajax change button was due to the potential for naming conflicts
[02:42] <thumper> however that isn't really a good reason
[02:43] <thumper> and there is no technical reason why it couldn't be fixe
[02:43] <thumper> d
[02:43] <slick666> actually I was poking at documentation and looking for a command line solution
[02:43] <thumper> oh...
[02:43] <slick666> this is way easier :P
[02:43] <thumper> I think you can do it with launchpadlib too
[02:43] <thumper> I think I got that working...
[02:43] <slick666> I was thinking bzr branch, bzr push something something
[02:44] <thumper> you should just be able to change the owner reference
[02:44] <thumper> and lp_save()
[02:44] <thumper> pushing to a new place works too
[02:44] <thumper> but it doesn't keep the existing subscribers
[02:44] <thumper> or linked bugs or merge proposals
[02:44] <thumper> as the old branch is still around
[02:45] <slick666> yea, thats what I was running into
[02:45] <slick666> thanks thumper, problem solved
[02:45] <thumper> np
[09:00] <mgz> anyone aware of issues with codehosting currently?
[09:00] <mgz> lp:~gz/bzr/2.5_backport_rmbranch_fixes exists over bzr+ssh but not over http
[09:02] <wgrant> mgz: You're the one that's meant to be aware of this now :P
[09:03] <wgrant> mgz: But I believe the HTTP rewriter always uses a slave database, and they're lagging by a bit at the moment.
[09:03] <wgrant> So if it's a new branch it might not be there yet.
[09:03] <jam> wgrant: I'm pretty sure they are served
[09:03] <jam> by the same location now, isn't it?
[09:03] <mgz> wgrant: thanks, now I am becoming more aware.
[09:03] <jam> ah, different pg db
[09:03] <jam> so it doesn't know how to translate URL to path on disk
[09:03] <wgrant> jam: Same location on disk, yeah
[09:03] <mgz> and this means I can blame stub?
[09:03] <wgrant> Pretty much.
[09:04] <wgrant> See the discussion in #-ops
[09:04] <mgz> ace.
[09:04] <wgrant> Well
[09:04] <wgrant> Blame Rosetta
[09:04] <wgrant> and stub
[09:04] <stub> I'm pedalling as fast as I can
[09:09] <czajkowski> poor stub
[09:12] <Nafallo> wgrant: oh hey! can ppas build stuff for debian yet? as in, can I put squeeze in my changelog and the buildfarm will DTRT?
[09:12] <StevenK> Nope
[09:12] <Nafallo> bah
[09:13] <czajkowski> Nafallo: ello
[09:13] <Nafallo> what's the timeline on that feature?
[09:13] <Nafallo> hola czajkowski
[09:13] <wgrant> Nafallo: Not clear if it will ever happen
[09:13] <Nafallo> wgrant: are you saying you've stopped being bored in weekends? ;-)
[09:13] <czajkowski> Nafallo: no it's ok I plague poor wgrant
[09:14] <wgrant> Nafallo: I implemented the necessary code in 2009
[09:14] <wgrant> Nafallo: It's trivial.
[09:14] <czajkowski> he now runs away at weekends to avoid me and my questions
[09:14] <Nafallo> haha
[09:14] <wgrant> Nafallo: Builder and disk resources are more the problem now
[09:14] <Nafallo> czajkowski: he's a clever guy :-)
[09:14] <wgrant> And potentially social considerations
[09:14] <czajkowski> wgrant: your idea of trivial and everyone elsses differs
[09:14] <Nafallo> wgrant: oh. hrm. yeeah... that makes sense to me...
[09:15] <wgrant> Nafallo: Maybe one day when we recruit 1SS into the build farm :)
[09:15] <Nafallo> wgrant: *grins*
[09:15] <wgrant> But it's certainly not feasible now
[10:08] <mpt> There should be a law against assigning bugs or work items to teams ...
[10:09] <geser> mpt: "It is forbidden by law to file bug or work items." something like that?
[10:09] <mpt> geser, no, just to assign them to teams
[10:09] <mpt> filing them is fine
[10:11] <geser> mpt: then file a bug which requests that the assign column gets hidden and assign it to the LP devs :)
[10:12] <mpt> Hiding it wouldn't work, because that would prevent assigning bugs to individuals.
[10:13] <geser> ah, indivuals are ok but just teams not
[10:13] <mpt> right
[10:19] <czajkowski> mpt: are you a happy chappy today!
[10:20] <mpt> I'm a box of birds, czajkowski
[10:20] <czajkowski> mpt: as always :)
[10:20] <czajkowski> mpt: unlike my battery icon which looks like a bee :/
[10:21] <mpt> A bee?
[10:21] <mpt> Screenshot?
[10:21] <davmor2> mpt: that's animal cruelty that is :P
[10:21] <xnox> Is launchpad ok? it has been 'processing' lp:~dmitrij.ledkov/ubuntu/quantal/btrfs-tools/merge for a while. =)
[10:22] <czajkowski> xnox: day downtime should be back up now
[10:22] <xnox> czajkowski: if you say so =)))
[10:22] <xnox> ok.
[10:22] <czajkowski> mpt: http://twitpic.com/9msmw2   http://twitpic.com/9mtp01     http://twitpic.com/9mtqml
[10:22] <czajkowski> xnox: in theory if not poke wgrant or stub
[10:24] <mpt> czajkowski, that is very strange. It looks as if one of the icons is missing, so for just that icon, it's falling back to a different theme.
[10:24] <czajkowski> mpt: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1001229
[10:24] <czajkowski> mpt: aye jut it's randomly changing every 2-3 mins only way to make it behave is to plug in your power supply
[10:50] <tsdgeos> hi guys, i can't change the branch status (the one under Branch Information) in https://code.launchpad.net/~aacid/nautilus/fix_quicklist_underscore even if it's my branch, any idea why? Could i convince you to do it for me?
[10:54] <czajkowski> tsdgeos: you should be able to do this
[10:54] <tsdgeos> i hope i could
[10:54] <tsdgeos> s/hope/wish
[10:54] <tsdgeos> don't see the yellow pencil
[10:55] <jelmer> tsdgeos: there is no yellow icon next to the statu ?
[10:55] <jelmer> *status
[10:55] <tsdgeos> nope
[10:55] <tsdgeos> oh wait
[10:55] <jelmer> tsdgeos: and you're logged in under the right account?
[10:55] <tsdgeos> i'm not logged in
[10:55] <tsdgeos> :D
[10:55]  * tsdgeos hides
[10:55]  * czajkowski peers at tsdgeos :)
[10:55] <tsdgeos> sorry guys
[10:55] <tsdgeos> and gal
[10:55] <czajkowski> tsdgeos: tis grand
[11:13] <xnox> maybe it's just me, but "Updating branch..." feels slow today
[11:13] <xnox> unless there is backlog
[11:35] <czajkowski> xnox: they are working on things atm
[11:36] <czajkowski> so perhaps thats why
[11:36] <xnox> ok
[12:09] <gema> hello, trying to work with the new blueprint work items section. is there a way to assign two people to one task? When I try to put the task twice with different names  against it, launchpad makes all of them the same name
[12:12] <gema> uhmmmm... it seems now it allowed me to, is it me or does it reorder the tasks?
[14:37] <dobey> sinzui: it would be pretty awesome if LP could work correctly in Netscape Navigator 3.04 Gold ;)
[14:41] <sinzui> dobey 3.04 parsed numbers wrong. I suspect that it is imposable for it to ever position content correctly on the screen
[14:42] <dobey> sinzui: it should work fine if you use tables :)
[14:42] <sinzui> Yes. I was pretty angry with how quick tables were subverted to layout tools in 1994
[14:43] <sinzui> I think it took 2 days from the moment Netscape added support for them
[14:43] <sinzui> but I do remember that moment in the Netscape 0.0 beta that I saw an animated GIF. That was really impressive
[14:45] <dobey> CSS is just a complex description of how to draw tables, anyway
[14:47] <sinzui> I don't think so. Positioning and z-index are a very different way of solving layout. Maybe you are referring to display:inline-block which is a really nice way to create a grid without a table
[14:48] <dobey> i mean, for most sites, the end result is the same, and z-order is not necessary.
[15:03] <mgz> the branch <lp:~clint-fewbar/charms/oneiric/statusnet/apparmor> has its stacking borked or similar
[15:07] <dobey> mgz: i guess you should bug SpamapS directly about that?
[15:08] <mgz> checking that no one else is already on the case, it's a known issue with the oneiric charms apparently
[15:14] <mgz> seems like it's currently not being handled, context is:

[15:16] <dobey> stacking looks correct on lp for clint's branch
[15:17] <dobey> it's stacked on lp:charms/oneiric/statusnet
[16:51] <m_3> james_w: ping
[16:52] <james_w> hi m_3
[16:52] <james_w> how's it going?
[16:52]  * m_3 stands around looking guilty :)
[16:52] <m_3> james_w: so... we've got these branches
[16:53] <m_3> james_w: they're frozen still too I think
[16:53] <james_w> yeah
[16:53] <m_3> james_w: any suggestions on who to ask for help here?
[16:53] <james_w> I think that will need a Launchpad change to unfreeze them
[16:53] <czajkowski> m_3: what's up ?
[16:53] <m_3> james_w: and then bzr reconfigure them in a script?
[16:54] <m_3> czajkowski: fundamental problem is that we have a series of branches that're stacked on the wrong bases if I understand correctly
[16:54] <m_3> example:
[16:54] <m_3> lp:~charmers/charms/oneiric/sbuild/trunk
[16:55] <m_3> I try to branch it and it's pointing to the precise branches
[16:55] <m_3> czajkowski: history is... lemme just pastebin the email summary
[16:57] <m_3> czajkowski: http://paste.ubuntu.com/1001230/ summarizes how we got these branches into their current state
[16:58] <czajkowski> ok
[16:58] <jimis> Hello all. Thought you'd like to know: It happens often to me that Launchpad times out when I try to browse big projects. Trying a second time after 30 seconds or so and request succeeds.
[16:58] <m_3> czajkowski: note that I mis-stated what `branch-distro` does in that email... it doesn't just _rename_ the branches
[16:58] <czajkowski> m_3: findibng out how best to help 2 ticks
[16:59] <james_w> ah right
[16:59] <james_w> I don't know if the freezing will mean that we can't fix the stacking
[16:59] <james_w> we can likely get an admin to fix the stacking without having to unfreeze them though
[16:59] <james_w> abentley, hi, I'm sure you will know: how can we fix a branch that is stacked on a non-existent branch due to a rename?
[16:59] <james_w> reconfigure --stacked-on seems to try and activate the fallback, so you have to have a working branch to use it?
[16:59] <m_3> czajkowski: many thanks!!! no particular rush... we need to a.) fix this and b.) make sure we don't do it again next release
[17:00] <czajkowski> m_3: nods just rying to find out as heading away but will get someone first
[17:00] <m_3> james_w: the branches are based on _different_ branches (that also have lp:charms aliases)... not nec non-existent branches
[17:00] <james_w> m_3, for next release an option to branch-distro to set the name to 'trunk' would seem to avoid this?
[17:01] <lifeless> that got wont-fix I think
[17:02] <lifeless> m_3: james_w: Stacking *is not semantic*, it shouldn't matter if oneiric is stacked on precise, as long as it was setup that way using bzr primitives (which will migrate data if needed)
[17:02] <james_w> m_3, for redis-master it is complaining about https://code.launchpad.net/~charmers/charms/precise/redis-master/precise/ which doesn't exist
[17:02] <lifeless> m_3: james_w: The branche should be stacked on +branch/ddddddd urls, not on long path urls.
[17:02] <m_3> james_w: I think that's the target branch for lp:charms/redis-master thought
[17:02] <lifeless> If they are long path urls, something is broken somewhere.
[17:02] <m_3> s/thought/though/
[17:03] <james_w> m_3, no, lp:charms/redis-master points to .../trunk
[17:03] <m_3> james_w: ah, right
[17:03] <james_w> m_3, branch-distro sets up that stacking, so I'm assuming the renaming you did to get /trunk is what broke the stacking
[17:04] <m_3> james_w: right... sounds correct
[17:04] <lifeless> james_w: branch-distro is broken if it set .../trunk
[17:04] <james_w> lifeless, branch-distro is what is broken then
[17:04] <lifeless> james_w: see my prior comment
[17:04] <james_w>     old_location_branch.set_stacked_on_url('/' + new_db_branch.unique_name)
[17:04] <lifeless> it should stack on numeric is
[17:04] <lifeless> *ids*
[17:04] <lifeless> to allow renames to be done.
[17:05] <m_3> lifeless: branch-distro set to /precise... but juju requires /trunk... so we renamed
[17:05] <m_3> lifeless: the rename script is in the email summary (halfway-ish) in http://paste.ubuntu.com/1001230/
[17:06] <lifeless> james_w: yeah, its using unique_name, which is fragile
[17:06] <lifeless> james_w: could you file a bug? Its 5am here...
[17:07] <lifeless> thumper did a project to migrate all existing branches to numeric stacked pointers, and change LP to stack numerically itself.
[17:07] <james_w> https://bugs.launchpad.net/launchpad/+bug/1003016
[17:07] <lifeless> We don't however magically change a symbolic name to a numeric
[17:07] <lifeless> we just provide a good default to bzr's config when it inspects the server
[17:08] <chrisccoulson> who broke armhf? https://launchpadlibrarian.net/105811044/buildlog_ubuntu-quantal-armhf.thunderbird_13.0~b2%2Bbuild1-0ubuntu3_CHROOTWAIT.txt.gz
[17:08] <chrisccoulson> :)
[17:09] <james_w> chrisccoulson, which slave is that?
[17:09] <chrisccoulson> james_w, nihal
[17:10] <james_w> chrisccoulson, cjwatson reported that already, and it's on the list to be hit with a cluebat
[17:10] <chrisccoulson> ah, cool. thanks!
[17:10] <czajkowski> heh
[17:10] <james_w> https://bugs.launchpad.net/launchpad/+bug/1003017
[17:11] <james_w> m_3, do you know if there is a bug about the oneiric branches being frozen?
[17:11] <m_3> james_w: dunno
[17:12] <m_3> james_w: Bug #991980
[17:12] <james_w> thanks
[17:13] <james_w> now that we've filed all the bugs hopefully we can get to fixing the broken branches now :-)
[17:13] <lifeless> james_w: a bug about the wrong stacking location I meant.
[17:14] <james_w> https://bugs.launchpad.net/launchpad/+bug/1003016
[17:14] <lifeless> james_w: we won't fixed the name choice, I don't know the bug number offhand to dupe it.
[17:14] <james_w> already commented with the bug number!
[17:14] <lifeless> james_w: if I'm sloppy right now, its because its 5am ;)
[17:15] <lifeless> james_w: but in this case, I loaded the page before your comment :)
[17:17] <james_w> sure
[17:17] <james_w> how can we fix the stacked on location of these broken branches?
[17:17] <lifeless> re-run the migration script thumper wrote
[17:18] <lifeless> its idempotent
[17:18] <lifeless> need to rename the branches back first.
[17:18] <lifeless> so that it can find and resolve the names
[17:19] <m_3> lifeless: can you point to thumper's migration script?
[17:20] <james_w> m_3, it's in the LP tree, one moment
[17:22] <dobey> is there a way to tell recipes on lp to include the "NubuntuM" part of the version?
[17:23] <james_w> m_3, http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/scripts/update-stacked-on.py
[17:23] <james_w> to be used with http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/scripts/get-stacked-on-branches.py
[17:23] <james_w> dobey, you mean from the changelog?
[17:25] <m_3> james_w: thanks... looking now
[17:25] <dobey> james_w: yes.
[17:26] <james_w> dobey, {debversion}
[17:26] <james_w> dobey, requires format 0.4
[17:27] <dobey> ah ok, cool
[17:27] <dobey> thanks
[17:27] <dobey> james_w: might you also know what LockNotHeld error from bzr means? #bzr seems to be deaf to my cry at the moment :)
[17:38]  * james_w can't hear dobey 
[17:38] <james_w> dobey, I don't really know
[17:38] <dobey> heh
[17:38] <dobey> ok
[17:39] <james_w> dobey, possibly that locking isn't being done correctly and the operation in question needs a lock that hasn't been taken, but I think that error is different
[17:39] <james_w> dobey, possibly that the lock on disk isn't the state that bzr thinks it should be
[17:39] <james_w> possibly something else
[17:39] <dobey> hmm
[17:39] <james_w> dobey, getting a backtrace by running with "bzr -Derror" might be useful
[17:40] <james_w> "bzr -Dlock" might be useful too
[17:40] <dobey> james_w: so it's not from bzr the program itself, but from tarmac using bzrlib
[17:40] <james_w> ah, hmm
[17:41] <james_w> dobey, do you have plugins that interact with bzrlib as well by any chance?
[17:41] <dobey> yes
[17:41] <james_w> and is tarmac running on precise?
[17:41] <dobey> yes
[17:42] <james_w> I have no new information for you
[17:42] <james_w> but they are possible sources of the error given that we aren't seeing it without those two things
[17:43] <james_w> class ObjectNotLocked(LockError):
[17:43] <james_w>     _fmt = "%(obj)r is not locked"
[17:43] <james_w>     # this can indicate that any particular object is not locked; see also
[17:43] <james_w>     # LockNotHeld which means that a particular *lock* object is not held by
[17:43] <james_w>     # the caller -- perhaps they should be unified.
[17:44] <dobey> hmm
[17:44] <dobey> that's quite odd
[17:44] <dobey> thanks
[20:09] <milk> howdy. i'm looking to login to my milkmiruku account, but the password reset doesn't work for what i think the address should be. what might my options be?
[20:21] <dobey> what should the address be?
[20:25] <milk_> it should be something @milkmiruku.com. i thought i'd have gone with launchpad@milkmiruku, but it might have been before, but my milkmiruku@gmail.com doesn't work either
[20:25] <dobey> milk: perhaps you should check spam folder
[20:28] <milk> och, i tried again with gmail and it worked. prolly pebkac. thanking you.