[00:00] <wxl> sorry git+ssh
[00:00] <wxl> the USERNAME is perhaps optional, depending on your config, but being explicit is good
[00:01] <wxl> following the same path as the original remote is ideal, too
[00:01] <gsilvapt> Okay, thanks guys!
[00:01] <wxl> so yes, wgrant and clivejo are both essentially correct :)
[00:02] <clivejo> so " git remote add gsilvapt git+ssh://gsilvapt@git.launchpad.net/~gsilvapt/kubuntu-packaging/+git/ksnakeduel "
[00:02] <clivejo> and then " git push gsilvapt kubuntu_unstable "
[00:02] <gsilvapt> Hum, okay that seems reasonable. I'll give that a try
[00:06] <clivejo> gsilvapt: did you push yet?
[00:06] <gsilvapt> just did
[00:06] <wxl> https://code.launchpad.net/~gsilvapt/kubuntu-packaging/+git/ksnakeduel
[00:06] <wxl> it's there
[00:06] <gsilvapt> exactly
[00:06] <wxl> so now click on the right branch
[00:06] <wxl> (kubuntu_unstable)
[00:07] <wxl> then click on the "Propose for merging" link
[00:07] <gsilvapt> I'm following
[00:09] <gsilvapt> clivejo, the merge message should be something like, the package was failing to build in KF5 because some packages were missing and this change adds that to the source code?
[00:09] <clivejo> I can see the commit
[00:09] <wxl> whatever you do make sure you pick the right repo/target!!!!!
[00:09] <clivejo> but no MR yet
[00:10] <wxl> and the merge request doesn't have to be anything really extensive
[00:10] <gsilvapt> Yea, I was going into those, wxl :D
[00:10] <wxl> it's very common to accidentially select the wrong repo
[00:10] <wxl> note that if you choose a repo from the repo, it doesn't automatically select the radio button
[00:10] <gsilvapt> target repository should be this ? https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/ksnakeduel
[00:10] <wxl> yes
[00:11] <gsilvapt> reference path? What's that?
[00:11] <wxl> that would be the branch
[00:11] <gsilvapt> kubuntu_unstable then, right?
[00:12] <wxl> should be yes
[00:12] <gsilvapt> Okay, thanks!
[00:12] <gsilvapt> I don't need to add any reviewer for now, or do I ?
[00:13] <wxl> no
[00:13] <gsilvapt> I know someone must sponsor this but I'm not sure if I should add someone or request sponsorship in another form
[00:13] <wxl> unless you've specifically talked to someone
[00:13] <wxl> otherwise the whole of the kubuntu-packaging team will get notification
[00:13] <gsilvapt> Right, okay.  wxl, thank you very much! I know you're busy with work so sorry for taking your time!
[00:13] <clivejo> you can direct it to me if you want?
[00:14] <gsilvapt> clivejo, too late now but I guess I can resubmit the proposal
[00:14] <clivejo> no, its fine, Ill get it anyway
[00:14] <gsilvapt> ah, or request another review
[00:14] <clivejo> got it
[00:15] <gsilvapt> I think I've done it correctly
[00:16] <gsilvapt> we can move this conversation to devel, if you prefer, clivejo. Seems more adequate to me
[00:16] <clivejo> sure :)
[00:16]  * wxl high 5s gsilvapt 
[00:17] <gsilvapt> thank you wxl!
[18:04] <gQuigs> is there any way to close all bugs on a package or project?  example: https://bugs.launchpad.net/ubuntu/+source/unity-2d
[18:05] <gQuigs> it's no longer in any supported ubuntu releases
[18:05] <gQuigs> or should I figure out how to script it to the LP api?
[18:05] <wxl> i don't know about the possibility of the former but it should be pretty trivial with the api
[18:09] <gQuigs> should that just be an automatic thing?  if Ubuntu release goes EOL (precise), and no action has been taken on the bug after 14.04 release, then mark it incomplete and ask to confirm if it's on a newer release?
[18:09] <wxl> yeah that's completely reasonable
[18:11] <nacc> gQuigs: wxl: server team is going through that process manually too :)
[18:12] <gQuigs> nacc: why manually?
[18:13] <nacc> gQuigs: well, we have to review each bug as well, in our case. For some, we are removing from our backlog, for some, we are updating the state.
[18:13] <nacc> gQuigs: most of them, in our case, are 'stale' in that they were triaged once, maybe 2 years ago and not touched since
[18:14] <gQuigs> nacc: what packages haven't you gotten to yet?
[18:14] <gQuigs> gQuigs is looking to get some technically good users (but possibly with little LP triage experience) a starting point of bugs to clean up/triage
[18:15] <gQuigs> so we might be able to help do a pre-clean on some packages
[18:15] <nacc> gQuigs: oh nice -- we're just finishing up a sprint, maybe I can ping you a list on monday?
[18:15] <gQuigs> nacc: sure, I'll shoot you an email  - thanks!
[18:16] <nacc> gQuigs: np, thank you
[19:16] <pmatulis> how do i branch/check-out/get a specific revision of a branch?
[19:20] <cjwatson> gQuigs: it's not IMO reasonable for it to be automatic, because it does happen that a source package is replaced or renamed and bugs should be moved around instead.  I'm much more comfortable with human judgement in the loop.
[19:24] <gQuigs> cjwatson: yea, that makes sense, especially with package renames..
[19:26] <gQuigs> cjwatson: any chance you know of a API script that already does part of what I'm looking to do?  (list all bus from one project, make  a comment and close)
[19:26] <gQuigs> most of the example scripts I'm finding are from 2010-2012..
[19:48] <pmatulis> disregard. bzr branch -r<rev#> ...
[20:06]  * gQuigs is currently trying to modify hugdaylist to do it..
[21:25] <cjwatson> gQuigs: Not offhand, but it's surely not that hard?