[00:24] <ovnicraft> hi guys how i get lp support this http://bit.ly/9CQdDc
[00:29] <ovnicraft> or i want to know if is posible manage something like 'multibranchs'
[00:29] <ovnicraft> 1 myrepo
[00:29] <ovnicraft> inside have many folder what are too branchs
[00:35] <spiv> ovnicraft: it might be good for launchpad to support bzr-scmproj directly, file a bug asking for it
[00:35] <spiv> ovnicraft: in the meantime you should be able to push the individual branches to lp separately
[00:36] <spiv> ovnicraft: there's some work in bzr towards having something like bzr-scmproj or bzr-colo builtin, when that's part of bzr I'm sure Launchpad will support it too
[00:40] <ovnicraft> spiv, i really hope
[03:11] <George_e> Is there a known issue with daily builds? One of mine hasn't been built for the last 8 days or so.
[03:12] <micahg> queue is empty ATM
[03:12] <George_e> Hmmm...
[03:13] <George_e> So is there something else that could be the problem?
[03:13] <micahg> idk, do you have a link to the build?
[03:13] <George_e> Sure... one sec.
[03:14] <George_e> micahg: https://code.edge.launchpad.net/~stackapplet-dev/+recipe/stackapplet-daily-builds
[03:14] <George_e> I requested a build yesterday, but it failed.
[03:15] <George_e> (The reason it failed had nothing to do with the actual build itself.)
[03:15]  * micahg doesn't know about recipies, spiv can you help?
[03:16]  * George_e hopes so...
[03:16] <wgrant> thumper: ^^ recipe builds stuck uploading -- what do we do about them?
[03:16] <George_e> The builds were working for about two weeks and then just stopped.
[03:16] <thumper> ah...
[03:16] <thumper> hmm...
[03:17] <thumper> there was a bug that jelmer was working on
[03:17] <wgrant> I think we may want to hit cancel and then retry.
[03:17] <thumper> where they got stuck
[03:17] <wgrant> I know what the bug is, but I'm not sure how to handle these existing cases.
[03:17] <thumper> it actually failed to upload, but didn't change state
[03:17] <thumper> I'm not entirely sure either
[03:17] <wgrant> There's a separate bug with recipe builds.
[03:17] <George_e> So I found a bug? :P
[03:18] <wgrant> Bug 666741, I think.
[03:18] <thumper> kk
[03:18] <George_e> Whew... I was worried I had done something wrong somewhere along the line.
[03:18] <thumper> the branch hasn't had a commit since the 29th
[03:18] <thumper> that was the last successful build
[03:19] <George_e> Right.
[03:19] <thumper> the subsequent ones fail to upload as the version already exists
[03:19] <thumper> there is a known bug about this sticking
[03:20] <thumper> If there were new commits to this branch I'm fairly sure that they would work
[03:20] <George_e> Wait, wait - are we talking about 'stackapplet'? The last commit of mine was 41.
[03:21] <thumper> https://code.edge.launchpad.net/~george-edison55/stackapplet/trunk has two commits from the translations service
[03:21] <George_e> Oh, right.
[03:24] <George_e> Is there some way of resetting the version?
[03:24] <George_e> *manually
[03:26] <thumper> edit the version string?
[03:26] <thumper> on the recipe that is
[03:28] <George_e> Okay...
[03:28] <George_e> thumper: Here is what is currently there: http://pastebin.com/9iEUZ6Yh
[03:29] <George_e> What do I change? (I'm not the one that created the recipe :)
[03:29] <thumper> my question first is why you want to change it?
[03:29] <thumper> if the branch hasn't changed, it'll build the same thing
[03:30] <George_e> The branch _has_changed.
[03:30] <George_e> *since the last build, anyway.
[03:30] <wgrant> The last revision is 43.
[03:31] <wgrant> The last successful build is of 43.
[03:31] <wgrant> https://code.edge.launchpad.net/~stackapplet-dev/+recipe/stackapplet-daily-builds/+build/5952
[03:32] <George_e> Something's messed up here...
[03:32] <George_e> I committed to the branch yesterday.
[03:32] <wgrant> Apparently not.
[03:32] <wgrant> Did you remember to push?
[03:32] <StevenK> Perhaps you commited locally, and didn't push
[03:32] <George_e> I'll check.
[03:33] <George_e> You're right!
[03:33] <George_e> ...I think...
[03:34] <George_e> I'm confused. Give me a minute to figure this out.
[03:39] <George_e> Okay, NOW all of the changes are pushed for sure.
[03:40] <George_e> I've requested new builds now.
[03:49] <thumper> ok
[03:52] <George_e> thumper: According to this page, the status is 'build uploading': https://code.edge.launchpad.net/~stackapplet-dev/+recipe/stackapplet-daily-builds/
[03:52] <George_e> What does that mean?
[03:53] <George_e> Will it show up in the PPA?
[03:53] <thumper> George_e: it means that the source package that was assembled from the recipe is being uploaded (as if a user did it)
[03:53] <thumper> George_e: only the results of building the uploaded package appear in the ppa
[03:54] <thumper> I'm in the process of fixing the recipe page to show the binary builds too
[03:54] <George_e> Oh, okay.
[03:54] <George_e> Are you one of the Launchpad developers then?
[03:56] <thumper> George_e: yep
[03:57] <jderose> quick question: what's the guidance for the "Fix Committed" vs "Fix Released" status for software not yet in Ubuntu (but available in a PPA)?
[03:57] <jderose> I just finished this bug: https://bugs.launchpad.net/dmedia/+bug/672273
[03:57] <George_e> thumper: Thanks for making Launchpad awesome! I use it for all of my many open source projects.
[03:57] <George_e> (and there's a lot :)
[03:57] <thumper> George_e: great to hear
[03:58] <thumper> jderose: it often depends on the project
[03:59] <jderose> thumper: is "Fix Committed" equally "fixed" as "Fix Released"? if that makes sense. :)
[04:00] <George_e> Uh-oh - I just got a rejection email... :(
[04:00] <jderose> thumper: like once dmedia is in Ubuntu, will I want to change these bugs to "Fix Released"?
[04:00] <thumper> jderose: the way we use it as a project is that once the fix is committed in trunk, it is "Fix committed", when end users get it it is "Fix released"
[04:01] <George_e> It seems like the last build was for revision 43 back in October... but I just committed revision 43 20 minutes ago :P
[04:01] <George_e> Guess I have to make a dummy commit or something.
[04:01] <thumper> ?
[04:01] <thumper> George_e: ah... did you push --overwrite?
[04:02] <George_e> No... what will that do?
[04:02]  * thumper is confused
[04:02]  * George_e is trying 'push --overwrite'
[04:02] <George_e> Nothing.
[04:02] <jderose> thumper: so at this stage, when I don't really have *users*, should I change it to "Fix Released" once it hits the daily PPA build?
[04:02] <thumper> George_e: wait
[04:03] <thumper> jderose: sounds fine
[04:03] <thumper> George_e: which branch are you saying you did a commit on 20 minutes ago?
[04:03] <George_e> trunk
[04:03] <thumper> which trunk?
[04:03] <George_e> ...which trunk...?
[04:03] <jderose> thumper: okay, thanks. so there is no *technical* difference between "Fix Committed" and "Fix Released", just cultural?
[04:04] <thumper> George_e: not this then? http://bazaar.launchpad.net/~george-edison55/stackapplet/trunk/revision/43
[04:04] <thumper> jderose: fix committed will still show in bug listings by default, fix released won't
[04:04] <George_e> jderose: Fix committed means that a revision has been committed that fixes the bug, Fix released means that that revision has made its way into a release.
[04:04] <George_e> ...of course it can mean whatever you want... but that's the way I use it.
[04:05] <jderose> George_e: gotcha, thanks.
[04:05] <George_e> thumper: Is 'lp:stackapplet' different from 'lp:~george-edison55/stackapplet/trunk'?
[04:05] <George_e> I thought they were supposed to be the same.
[04:06] <jderose> thumper, George_e: okay, one more question. are there conventions for these statuses when a bug is targeted to a particular milestone?
[04:06] <jderose> like changed to "Fix Released" one the milestone has been reached or something?
[04:07] <jderose> s/one/once/
[04:07] <thumper> George_e: no, that is the same branch
[04:07] <thumper> George_e: lp:~george-edison55/stackapplet/trunk is what we call the unique_name
[04:07] <thumper> well... to be precise "~george-edison55/stackapplet/trunk" is what we call the unique_name
[04:08] <George_e> I made a sort-of dummy commit (I removed two extra newlines).
[04:08] <George_e> Now we're at revision 44.
[04:08] <George_e> NOW I will request another build :P
[04:09] <George_e> I think I finally figured out what's going on...
[04:10] <George_e> When the translation service commits to the branch, I have to merge it with my copy...
[04:10] <George_e> ...and this probably messes with the revision numbers.
[04:10] <George_e> (This happened to me on another project.)
[04:10] <George_e> Could that be it?
[04:11] <thumper> yep
[04:11] <thumper> George_e: I think the best thing to do there is to not have translations commit to trunk
[04:12] <George_e> I see that now.
[04:12] <George_e> I've been meaning to ask someone...
[04:12] <George_e> how do branches work...?
[04:12] <thumper> jtv knows about translations stuff
[04:12] <George_e> What I mean to say is... is there any reason to create separate branches besides trunk?
[04:12] <thumper> what do you mean "how do branches work"
[04:12] <George_e> Or am I misunderstanding something?
[04:13] <thumper> I tend to work using feature branches
[04:13] <thumper> so I have trunk always good
[04:13] <George_e> Okay.
[04:13] <thumper> experimental work in progress goes in a different branch
[04:13] <thumper> when that is ready to release, merge it with trunk
[04:13] <George_e> How does that work when it comes to releases?
[04:13] <thumper> you release trunk
[04:13] <George_e> Do the releases all use trunk?
[04:13] <thumper> no
[04:13] <George_e> What do they use?
[04:13] <thumper> some longer running projects will use release branches
[04:14] <thumper> they may branch those from trunk at specific points in time, like beta
[04:14] <thumper> then they apply fixes to the release branches as needed
[04:14] <thumper> but leave trunk open for fresh work
[04:14] <jderose> George_e: branches are also great so you don't break trunk... don't merge a feature till tests pass, everything is working
[04:14] <George_e> Ah.
[04:15] <George_e> So when I release 1.4 of StackApplet soon, I just leave it set to trunk?
[04:15] <psusi> thumper, say, you had a chance to figure out what the deal is with the broken stacked branches?
[04:15] <George_e> What is the recommended thing?
[04:15] <thumper> psusi: hi
[04:15] <psusi> howdy
[04:15] <thumper> psusi: sorry, I've been flat stick with other things today
[04:16] <thumper> we have in progress bzr 2.2.1 landing
[04:16] <jderose> George_e: tag that revision with `bzr tag 1.4`
[04:16] <thumper> which I think fixes it
[04:16] <poolie> hi thumper
[04:16] <thumper> it has landed on trunk, but we need to arrange codehosting downtime to release it
[04:16] <George_e> jderose: What does that do?
[04:16] <thumper> hi poolie
[04:17] <jderose> George_e: if you think you will do ongoing maintaining on 1.4, branch from trunk and call the branch foo-1.4 or whatever... then you can also create a series in launchpad and have it point to foo-1.4 (the "trunk" for the 1.4 branch).
[04:17] <jderose> rockstar was just explaining this all to me yesterday, so i'm pretty sure i got it right :)
[04:18] <George_e> jderose: ...and if you're not planning any maintenance?
[04:19] <thumper> George_e: then you can just tag the trunk branch and keep going
[04:19] <thumper> tags are nice
[04:19] <jderose> jderose: then just tag it... that way you at least know the revision the release was associated with
[04:19] <thumper> jderose: snap
[04:19]  * thumper needs to take a break and stop kids killing each other
[04:20] <jderose> George_e: you can also branch and create the series later on. but creating the series from the get-go i think can be good because it communicates your intentions to other who may want to contribute
[04:21] <jderose> George_e: so someone see, oh, this series is open for maintenance, so my merge proposal might actually get looked at, even accepted.
[04:21] <George_e> jderose: Okay... so how do translations  fit into that?
[04:22] <jderose> George_e: someone else might have to answer that, but i'm sure there's a good answer so translators aren't just chasing trunk... i'd like to know the answer to that myself :)
[04:24] <George_e> Let me see if I've got it right... when StackApplet 1.4 comes out, I should create a new branch called stackapplet-1.5 and merge trunk with it every now and again?
[04:24] <jderose> (cool, stackapplet sounds awesome, btw)
[04:26] <jderose> George_e: basically, but i wouldn't create 1.5 branch till 1.5 is released
[04:26] <jderose> active development is merged onto trunk
[04:26] <George_e> Oh... so how do I take the contents of trunk and put it in stackapplet-1.5?
[04:27] <jderose> bugfixes and perhaps backports are merge onto 1.4
[04:27] <George_e> (I haven't done a lot of merging before...)
[04:27] <jderose> George_e: I love merging, so I can explain. :)
[04:27] <George_e> Oh good!
[04:27] <jderose> George_e: so 1.4 is your stable release, you're working up to 1.5?
[04:27] <George_e> No.
[04:28] <George_e> 1.3 is stable... I'm working to 1.4
[04:28] <George_e> :)
[04:29] <jderose> George_e: ah, okay... well, there is a lot of flexibility, but i would do something like this (and I'm trying to channel rockstar for correctness)...
[04:29] <jderose> so say you're in trunk or whatever the tip branch is for 1.4 development
[04:29] <George_e> Right.
[04:30] <jderose> you just make the final change: bzr commit -m "StackApplet 1.4 is now totally awesome"
[04:30] <jderose> then tag the release: bzr tag 1.4
[04:31] <George_e> What does the tag do?
[04:31] <jderose> George_e: it's just metadata associated with a particular revision
[04:31] <jderose> it's used most for release numbers
[04:32] <jderose> George_e: like if you checkout bzr and then run: bzr tags
[04:32] <George_e> I see.
[04:32] <jderose> you'll see stuff like this:
[04:32] <jderose> bzr-2.1.0b1          4734.3.1
[04:32] <jderose> bzr-2.1.0b2          4668.1.4
[04:32] <jderose> bzr-2.1.0b3          4797.1.3
[04:32] <jderose> bzr-2.1.0b4          4896.1.6
[04:32] <jderose> bzr-2.1.0rc1         4981.1.6
[04:32] <jderose> bzr-2.1.0rc2         4797.6.1
[04:32] <jderose> bzr-2.1.1            4797.41.1
[04:32] <jderose> bzr-2.1.2            4797.55.1
[04:33] <George_e> Okay.
[04:33] <jderose> George_e: does lp:stackapplet point to your development tip?
[04:34] <jderose> (guess it does, you just commited 7 minutes ago)  ;)
[04:34] <jderose> Okay, branching...
[04:35] <jderose> George_e: so you tagged your release...
[04:35] <jderose> now branch like this: bzr branch lp:stackapplet lp:~george-edison55/stackapplet/1.4
[04:36] <George_e> jderose: Okay... And that creates a separate branch for the 1.4 release?
[04:37] <jderose> George_e: yes, you will see all branches that haven't been merged here: https://code.launchpad.net/stackapplet
[04:38] <jderose> actually, maybe create a test one right now and i'll walk you trough a real live merge
[04:38] <George_e> Ah.. that makes sense.
[04:38] <George_e> Okay.
[04:38] <George_e> Can I delete it after?
[04:38] <jderose> you'll just merge into a throwaway branch... yep
[04:38] <George_e> Okay.
[04:39] <jderose> Run this: bzr branch lp:stackapplet lp:~george-edison55/stackapplet/dummy-1.4
[04:39] <George_e> Okay.
[04:40] <jderose> Okay, see how it show's up here now: https://code.launchpad.net/stackapplet
[04:40] <George_e> Oh yeah.
[04:42] <jderose> Okay, now I just branched from your 1.4 branch: bzr branch lp:~george-edison55/stackapplet/dummy-1.4 lp:~jderose/stackapplet/dummy-1.4-bugfix
[04:42] <jderose> Which you now also see here: https://code.launchpad.net/stackapplet
[04:43] <jderose> George_e: have you used bzr "shared repositories" before?
[04:43] <George_e> I don't know.
[04:44] <jderose> George_e: Okay, more learning, but this is cool stuff... opinions very here, but here's how I like to work....
[04:45] <jderose> George_e: Okay, maybe cd into /tmp for this as we're just playing
[04:45] <jderose> cd tmp
[04:45] <George_e> Okay sure.
[04:45] <George_e> Now what?
[04:45] <jderose> bzr init-repo stackapplet
[04:45]  * George_e thinks you meant 'cd /tmp'
[04:45] <jderose> ah, yeah
[04:46] <George_e> Okay.
[04:47] <jderose> cd stackapplet/
[04:47] <jderose> bzr checkout lp:~george-edison55/stackapplet/dummy-1.4
[04:47] <George_e> Okay.
[04:47] <jderose> Okay, and this one should be faster: bzr checkout lp:~jderose/stackapplet/dummy-1.4-bugfix
[04:48] <George_e> Okay.
[04:49] <jderose> if you do an ls now (assuming your in /tmp/stackapplet still), you should see dummy-1.4  dummy-1.4-bugfix directories
[04:49] <George_e> Right.
[04:49] <jderose> those are two branches, but the revisions (stuff stuff that takes up the space), are store just once in /tmp/stackapplet
[04:49] <George_e> Ah, neat!
[04:49] <jderose> i'll show you around more...
[04:50] <jderose> cd dummy-1.4-bugfix
[04:50] <jderose> bzr info
[04:50] <George_e> "checkout of branch: bzr+ssh://bazaar.launchpad.net/~jderose/stackapplet/dummy-1.4-bugfix/"
[04:50] <George_e> ^--- part of output
[04:50] <jderose> George_e: yeah, and notice it shows you where the shared repository is
[04:51] <jderose> shared repository: /tmp/stackapplet
[04:51] <George_e> Okay.
[04:51] <jderose> okay, now i'm going to make some changes, hang on a sec....
[04:53] <jderose> okay, so assuming you're still in /tmp/stackapplet/dummy-1.4-bugfix
[04:53] <jderose> bzr update
[04:53] <jderose> bzr log --forward
[04:54] <jderose> you should see the revno 46 commit that i made "Said hello to George"
[04:54] <jderose> George_e: that work?
[04:54] <George_e> Yup.
[04:55] <jderose> George_e: so by peoriodically running bzr update you can track my progress and have a convient local copy
[04:56] <George_e> I see... how does 'bzr update' differ from 'bzr pull'?
[04:57] <jderose> George_e: Good question. :) there are two approaches that basically do the same things...
[04:58] <jderose> so you can 1) do a checkout, in which case commits are automatically "pushed" do the parent branch when you do a commit, and you do update to pull remote changes into your local branch
[04:59] <jderose> George_e: or you can 2) branch, make commits, then push to put those commits on launchpad, pull to bring commits from launchpad
[05:00] <George_e> I have been doing the second option.
[05:00] <George_e> So when you first create the branch (when starting a project), what choices do you have?
[05:00] <jderose> the disadvantage of checkouts is you can't commit when offline without some monkey business; the advantage of checkouts is you don't need an extra step to let the word know about the change you just made
[05:00] <George_e> Ah.
[05:01] <jderose> George_e: well, it doesn't matter that much, you can switch between the to modes easily
[05:01] <George_e> How?
[05:02] <jderose> George_e: so if you're in /tmp/stackapplet/dummy-1.4-bugfix still
[05:02] <George_e> Yup.
[05:02] <jderose> just run: bzr unbind
[05:02] <jderose> now you can work with your familiar push/pull mode
[05:02] <George_e> I'm guessing 'bzr bind' does the opposite?
[05:03] <jderose> yeah, although i guess will will have to specify the push location once at first
[05:03] <George_e> I see.
[05:03] <jderose> George_e: although you can't push (or commit it) my branch because I own it.  put you can pull from it.
[05:03] <George_e> Can I try a commit?
[05:03] <George_e> Oh.
[05:04] <jderose> I'll have you do the merge in just a sec... :)
[05:04] <jderose> Okay bind it again: bzr bind
[05:04] <George_e> Yup.
[05:04] <jderose> bzr update
[05:04] <jderose> just have 2 more commits, up to rev 48
[05:04] <jderose> now:
[05:05] <jderose> cd ../dummy-1.4
[05:05] <jderose> bzr merge ../dummy-1.4-bugfix/
[05:05] <jderose> bzr status -v
[05:06] <George_e> Yup, it lists 3 pending merges.
[05:06] <jderose> A cool thing about bzr is that merge doesn't automatically merge, the merge itself is a point on the history that must be committed
[05:06] <jderose> bzr commit -m "Merged fix from Jason"
[05:07] <George_e> And it will get pushed automatically, right?
[05:07] <jderose> yep, that's how a checkout works (bound branch)
[05:07] <George_e> Right.
[05:07] <jderose> bzr log --forward --include-merges
[05:08] <jderose> George_e: scroll up till you see revno: 46 [merge]
[05:08] <George_e> Yeah, I see it.
[05:08] <George_e> I see extra version numbers have sneaked in too.
[05:09] <George_e> (45.1.1, etc.)
[05:09] <jderose> When you use the --include-merges options you see the sub-history... the 3 commits on my branch
[05:09] <jderose> yeah, this is the bzr hierarchical history and it's awesome
[05:10] <jderose> for example, try it without the flag: bzr log --forward
[05:10] <jderose> it collapses the child history, so you can have a quick overview of say trunk
[05:10] <George_e> Okay... now it just displays the merge revision.
[05:10] <jderose> but you can also drill down into the child-history and get all the nice meta-data there, see my thought process
[05:11] <George_e> Right.
[05:11] <George_e> When you have a lot of people contributing that would be very valuable.
[05:11] <jderose> George_e: yes, and a time saver... i can explain what i'm doing though commit messages, something i'm doing anyway
[05:12] <jderose> George_e: so that's how you would merge a fix into your maintenance branch. same process if you were merge into trunk.
[05:12] <George_e> Ah, I get it.
[05:13] <jderose> George_e: opinions and circumstances difference on whether you should use checkout+update or push+pull, but the branch/merge semantics are the same either way
[05:13] <George_e> Yeah, it's a matter of preference, I guess.
[05:14] <George_e> Thanks so much for the tutorial!
[05:14] <jderose> George_e: and situation. i work mostly from a workstation with pretty reliable Internet, so checkout+update fits well for me
[05:15] <jderose> George_e: no prob, lauchpad and bzr are great tools, happy to pass on what i know about them.  :)
[05:15] <George_e> Me too - I'm always at home when committing. (Well _almost_...)
[05:15] <George_e> jderose: Should we get rid of the branches?
[05:15] <jderose> ah, yeah. you can delete it through the web ui: https://code.launchpad.net/~george-edison55/stackapplet/dummy-1.4
[05:16] <jderose> i'll delete mine.
[05:18] <George_e> Thanks again!
[05:19] <jderose> George_e: no prob, i'll have to checkout StackApplet :)
[05:19] <George_e> Great! You can find a breif overview of version 1.3 here: http://stackapps.com/questions/83/stackapplet-stackoverflow-meets-the-gnome-desktop-v1-4-beta-1-available-for-te
[06:01] <jderose> Hmmm, are source package recipes currently horked? I'm getting an Oops when I request a build.
[06:06] <lifeless> !oops
[06:06] <lifeless> bah, need to tweak that
[06:07] <lifeless> jderose: we need to see the OOPS to comment.
[06:07] <jderose> lifeless: so just the link will work then?
[06:08] <jderose> lifeless: Error ID: OOPS-1773B467
[06:11] <lifeless> jderose: just waiting for that to sync
[06:12] <jderose> lifeless: cool, thanks :)
[06:22] <lifeless> jderose: ok, got it up
[06:23] <lifeless> jderose: you need to use 'edge' for now
[06:23] <lifeless> jderose: we no longer redirect to edge automatically.
[06:23] <lifeless> because we're in the process of removing 'edge'.
[06:23] <lifeless> https://code.edge.launchpad.net/%7Enovacut/+recipe/dmedia-daily/+request-builds
[06:23] <lifeless> should work
[06:23] <jderose> lifeless: ah, okay... rockstar told me edge went away, i thought it didn't do anything anymore
[06:24] <lifeless> the servers are still there
[06:24] <jderose> but i misunderstood a bit ;)
[06:24] <lifeless> we're transitioning edge only things onto the main cluster
[06:26] <jderose> lifeless: okay, cool. is there anyway to know when source package recipes are running on the main cluster?
[06:26] <lifeless> when the revno at the bottom right of pages shows 11866 or higher
[06:29] <jderose> lifeless: awesome, thanks!
[10:07] <geser> bigjools: can you check why https://launchpad.net/~pali/+archive/kopete/+build/1973460 is still uploading (for over 2 weeks now)? (see also https://bugs.launchpad.net/soyuz/+bug/662419/comments/2)
[10:08] <bigjools> jelmer: ^
[10:08] <jelmer> bigjools: Looking into it.
[10:10] <bigjools> jelmer: there's still some builds stuck on "uploading" it seems
[10:10] <bigjools> I don't know if there's any new ones since your fix though
[10:21] <popey> If there's any admins about it looks like https://launchpad.net/~mess110 has spammed bug 11334
[10:41] <mrevell> allenap, pingaling
[10:42] <mrevell> Thanks popey, I'll take a look
[10:42] <popey> np
[10:42] <allenap> mrevell: Cheers.
[11:30] <bdrung> where do i report spam in bug reports (last comment in bug #11334)?
[11:31] <jpds> bdrung: Already being looked into (see above).
[11:32] <bdrung> oh, thanks
[12:46] <AlexC_> morning
[12:47] <AlexC_> I have to ask, what is going on with the Launchpad interface? It looks so unfinished and, well ... crappy. There are just things everywhere, inconsistent margins. bold text that draws your eye to things that simply don't need attention given to them, random colors.
[12:48] <AlexC_> compare the current with how it looked like 1, 1 1/2 years ago, it's quite shocking
[12:59] <napster> Can I use this ppa https://launchpad.net/~nvidia-vdpau/+archive/cutting-edge-multimedia with Meerkat?
[14:54] <ubuntu4shane> ok, I was trying to setup a PPA and successfully setup one, however I logged in on my laptop, and it isn't there, I'm thinking I have two launchpad accounts, and didn't realize it, is there a way to merge them?
[14:54] <ubuntu4shane> is that possible?
[15:00] <bigjools> hey sinzui, are you CHR today? ^
[15:04] <ubuntu4shane> ok, I did confirm that I have two accounts, this comes as news to me, I never realized it!  is there a way to merge these two accounts?
[15:06] <bigjools> there is but I can't remember how you do it
[15:06] <sinzui> bigjools, I was just getting my coffee and start it
[15:06] <bigjools> but there's a man who does
[15:06] <bigjools> morning sinzui :)
[15:07] <sinzui> ubuntu4shane, you are a victim of Ubuntu's Single Signon and the deep Lp authentication code
[15:07] <ubuntu4shane> sinzui, yes, I don't know how that happened, I mean I do have 2 email addresses (who doesn't) the funny thing is I never realized it.
[15:08] <ubuntu4shane> which I now have to ask, which one am I using for UbuntuOne?  :)
[15:11] <sinzui> ubuntu4shane, I think you want to start by merging one into the other. Use the "Request a merge" link on https://launchpad.net/people to start the merge. You must be logged in as the profile you want to keep, and enter the id of the profile that must go away
[15:11] <sinzui> ubuntu4shane, you will be sent an email to confirm you control the other email address.
[15:12] <ubuntu4shane> sinzui, thanks!  glad it can be done
[15:13] <ubuntu4shane> sinzui, that was simple enough, I assume that all my bugs will then be linked to both accounts
[15:15] <sinzui> ubuntu4shane, yes, they will. You karma will look odd for a few days. It is fixed by a secondary process
[15:16] <sinzui> ubuntu4shane, if you get a timeout error, reload the browser. merge is slow but it will complete when whipped with successive ctrl+r presses
[15:16] <ubuntu4shane> sinzui, ok, thanks a bundle for the info!
[16:20] <mtaylor> in launchpadlib, is there a way to get a particular team if you know the exact name? it seems like what I have is launchpad.people.findTeam(text="blah")
[16:26] <james_w> mtaylor, lp.people["blah"] I think
[16:26] <cody-somerville> mtaylor, launchpad.people['blah']
[16:26] <mtaylor> awesome
[16:26] <jpds> What a cool team name.
[16:27] <mtaylor> heh
[17:10] <piken> Hi all, is there a way to display a file in a raw format in the web browser the way you can with github?
[17:59] <sinzui> piken, I do not know what you mean by raw. Do you mean the see the unannotated contents of a file
[18:01] <piken> yes
[18:01] <piken> here is an example github link
[18:01] <piken> https://github.com/piken/unified-install/raw/master/src/manifest.global
[18:01] <piken> That actually displays the raw text of the file as if accessing the file directly.
[18:13] <sinzui> piken, loggerhead does not support this. It will make you download the file.
[18:53] <Linuxsapien> how to change account Email address please?
[19:15] <lifeless> Linuxsapien: login, register a new email address in your account, disable the old email address (in that order)
[19:16] <Linuxsapien> thank for that lifeless but I managed to get it
[19:16] <Linuxsapien> once ya find help, its easy to read :D
[19:24] <piken> sinzui: ty, looks like I will b staying with github for now
[20:04] <paddy_> I created a key for launchpad with gpg --gen-key but i cannot find the file i give to launchpad, the key appears in seahorse though
[20:46] <sinzui> paddy_, did you publish your key to an Ubuntu keyserver over 30 minutes ago?
[20:47] <lifeless> sinzui: paddy_ had not found the +editgpgkeys page
[20:47] <lifeless> sinzui: I helped them in #ubuntu-devel
[20:47] <sinzui> paddy_, using seahorse you can publish the key to keyserver.ubuntu.com. It can take about 30 minutes before launchpad will see it
[20:47] <sinzui> thanks lifeless
[20:49] <sinzui> lifeless, why do we send an email to confirm gpg keys. I ask because quickly wants to assist the new user to setup gpg keys?
[20:52] <sinzui> I think Lp could let me upload an encrypted test document to verify my public key
[20:58] <lifeless> sinzui: IIRC the logic was
[20:58] <lifeless> gpg ids are email addresses
[20:58] <lifeless> we shouldn't let someone use a gpg id for an email address they don't control.
[20:59] <lifeless> doing an email round trip both shows they control the gpg key and the email address.
[20:59] <sinzui> That is still a good reason
[20:59] <lifeless> I think it would be plausible to skip the round trip where we already believe they have the email address
[20:59] <lifeless> we'd still want to see that they can sign /encrypt with the key
[21:00] <sinzui> lifeless, we do not control the email address anymore. SSO does. We take it for granted in the case of the average user
[21:00] <sinzui> only user with more than on address will be confirmed by Lp
[21:01] <lifeless> so
[21:01] <lifeless> in the generic open id consumer story
[21:01] <lifeless> we wouldn't want to let someone setup a provider
[21:01] <lifeless> claim to have mark at canonical dot com, and sign in
[21:01] <lifeless> nor grab that as a gpg key
[21:05] <sinzui> lifeless, okay. So I think we really want to keep this requirement. Quickly needs to set user expectations and clearly to keep the user engaged
[21:06] <lifeless> we could iterate towards some known conditions where we can loosen it, but it seems nontrivial to me
[21:21] <paddy_> I tried to tell bzr about my launchpad account but it says I have no ssh keys, it's right but I have an openPGP key instead, can I not use this?
[21:28] <spiv> paddy_: bzr uses ssh to connect to Launchpad, not gpg
[21:37] <paddy_> spiv, thanks