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