[10:48] <dpm> wgrant, cjwatson, quick question: what's the equivalent in git to push a personal branch to LP? I.e. how can I do something like 'bzr push lp:~dpm/dekko/my-branch' but for a git repo in LP?
[10:53] <wgrant> dpm: git push lp:~dpm/dekko
[10:53] <wgrant> https://help.launchpad.net/Code/Git
[10:54] <dpm> great, thanks wgrant
[11:02] <dpm> wgrant, hm, not sure I've quite figured it out after reading the docs. Trying 'git remote add origin lp:~dpm/dekko' as instructed in the documentation results in 'fatal: remote origin already exists'
[11:03] <wgrant> dpm: "origin" is a name of purely local significance. Apparently you already have a remote named "origin", so you should probably choose a different name or delete the existing one.
[11:06] <dpm> wgrant, ok, did a 'git remote add origin lp:~dpm/dekko', but now I'm not sure I understand the 'git push origin my-changes' bit. Do I need to create the 'my-changes' branch first? If I just do a 'git push origin my-changes', I get a "error: src refspec my-changes does not match any."
[11:06] <dpm> sorry, I meant, I did a 'git remote rm origin'
[11:06] <dpm> not an 'add'
[11:07] <wgrant> You'd want the branch to exist locally first, usually.
[11:07] <wgrant> It's possible to push to a different name on the other end, with "git push origin LOCAL:REMOTE", but it's unusual.
[11:08] <cjwatson> I generally call a personal remote that exists purely for the sake of me contributing branches to something else "cjwatson", though I'm sure you want a different name :-)
[11:09] <wgrant> I use origin for mine and upstream for trunk, usually.
[11:09] <cjwatson> So this is my workflow (as wgrant notes, the exact names are of purely local significance):
[11:09] <cjwatson> git clone lp:foo
[11:09] <cjwatson> cd foo
[11:09] <cjwatson> git checkout -b my-changes
[11:09] <cjwatson> # hack hack hack
[11:09] <cjwatson> git remote add cjwatson lp:~cjwatson/foo
[11:09] <cjwatson> git push -u cjwatson my-changes
[11:10] <cjwatson> If you haven't already created a branch for your changes, does that mean you have just committed your stuff on master?  (This is repairable, virtually anything is, but we need to know exactly what you've done.)
[11:11] <dpm> yes,  I committed to master, but it was a one-liner, so I might just clone again with the correct workflow
[11:11] <cjwatson> You can if you like but it's unnecessary.
[11:12] <cjwatson> git branch my-changes   # this creates a new branch that points to the current state of the branch you're on - just another pointer
[11:12] <dpm> ok
[11:13] <cjwatson> git reset --hard origin/master   # reset the branch you're currently on, should be master, back to whatever it is in the "origin" remote - this assumes you actually have an "origin" remote that points to upstream, and you can use a different name if you like
[11:14] <cjwatson> git checkout my-changes   # switch to the "my-changes" branch (which wants a better name, but whatever, this is an example).  not strictly necessary right now but useful to avoid confusing yourself.
[11:14] <cjwatson> git branch   # for reassurance.  tells you what branch you're currently on
[11:15] <cjwatson> BTW you should make sure you've committed everything before git reset --hard!
[11:15] <dpm> ok
[11:16] <cjwatson> In future, always create a branch before you start hacking, as they're ridiculously cheap in git, and it will avoid you getting confused like this.  I also suggest looking into the stuff in /usr/lib/git-core/git-sh-prompt to put some git status in your shell prompt
[11:17] <wgrant> Also be really careful with git reset
[11:17] <wgrant> It does several different things, some of which are permanently destructive, and all of which are easily confusable.
[11:17] <cjwatson> Yep
[11:18] <dpm> ok
[11:18] <cjwatson> I think only --hard is permanently destructive, though some of the recovery steps for the others are a bit expert-level ...
[11:18] <cjwatson> (Well, unless you consider index state precious, which I normally don't)
[11:19] <wgrant> Some people have a thing for that, unfortunately.
[11:19] <dpm> ok, so I think I've managed and I'm now submitting the MP. The web form complains about 'Target reference path:' missing. What is it exactly?
[11:21] <cjwatson> Probably "master".  The branch name in the target repository that you want to merge into
[11:21] <cjwatson> (The web UI there is known-awful)
[11:22] <dpm> There is an 'origin/master' in the output of git branch -a, so I'll give master a go
[11:23] <dpm> and it worked, thanks!
[11:27] <cjwatson> Excellent
[14:45] <karstensrage> hi
[14:46] <karstensrage> what do you have to sign to use dput ppa:
[14:46] <karstensrage> the problem is that the keys are not on the packaging machine
[14:52] <cjwatson> karstensrage: You must sign the .dsc and .changes files with a key registered in Launchpad.  If you don't have such a key on the machine where you prepare the packages, then perhaps "debsign -r" (or maybe debrsign, depending on direction) will help.
[14:54] <karstensrage> ok and reading the man page for debrsign you specify .changes and it picks up .dsc from that
[14:55] <cjwatson> Right, you don't normally have to do that bit manually
[14:57] <teward> cjwatson: i see two new options on the PPA details page - Build debug symbols, and Publish debug symbols.  Might I ask when/why those were added, and what cases someone would have for them?
[14:57] <teward> if you don't know then i'll wait :)
[14:59] <cjwatson> teward: They've been admin-only options for ages, and in September I moved them to be self-service because there was no reason for them to be admin-only any more
[14:59] <teward> I see.
[14:59] <teward> that explains then now being visible, alongside the self-service arch options
[15:00] <teward> well, one step closer to builds like the main repos, then, I guess xD
[15:00] <cjwatson> teward: It means you can turn on or off whether you want ddebs to be built and published; you might want them on because you have difficult stuff to debug, or off because maybe they're huge and eating your quota; so both options are reasonable
[15:00] <teward> ahhh, that makes more sense
[15:01] <teward> apparently i don't visit the "Change Details" page of PPAs frequently enough anymore heh
[15:01] <karstensrage> :( the machine with keys is a mac
[15:01] <teward> cjwatson: thanks
[15:03] <cjwatson> karstensrage: debsign is a shell script; it's not entirely impossible it would work on OS X
[15:03] <cjwatson> (or it might not, I'm not sure if e.g. mktemp is available there)
[15:12] <karstensrage> cjwatson, dont think so, debsign seems to use a lot of functions that are in pbuilder
[15:13] <karstensrage> or w/e all that stuff is in
[15:13] <karstensrage> hmmm
[15:13] <cjwatson> Um, no, it doesn't depend on pbuilder in any way.
[15:13] <cjwatson> Other parts of devscripts, maybe, but not debsign.
[15:13] <teward> stupid question but is it not possible for you to export your gpg key, then take it over to the packaging system?
[15:13] <teward> (or do the packaging from inside a VM on the Mac?)
[15:13] <karstensrage> https://github.com/rgeissert/devscripts/blob/418128c981768829145034df14469df03e6e7fd0/scripts/debsign.sh
[15:14] <teward> (crosscompatability of scripts would then be taken out of the equation)
[15:14] <karstensrage> teward, i *could* do that, i was hoping not to have to ship keys around
[15:14] <cjwatson> karstensrage: Right, where are you seeing pbuilder stuff in there?
[15:14] <teward> karstensrage: nothing in there is for pbuilder, by the way
[15:14] <teward> whoops ninja'd by cjwatson :)
[15:15] <karstensrage> cjwatson, line 639, dpkg-parsechangelog
[15:15] <cjwatson> That has nothing to do with pbuilder!
[15:15] <teward> karstensrage: that's not a pbuilder item
[15:15] <karstensrage> ok
[15:15] <karstensrage> well its not on the mac for sure
[15:15] <cjwatson> But it's true you probably won't find it on a Mac (though I think there are ways to get dpkg)
[15:15] <cjwatson> However, you only need that if you run debsign without arguments
[15:15] <cjwatson> It doesn't use that if you explicitly pass it a .changes file
[15:16] <cjwatson> Which you have to do in the -r mode - so that bit is entirely irrelevant for -r
[15:18] <teward> i hate to suggest an evil alternate method, but is having a separate key for your packaging system not an option for you?
[15:18] <teward> i only ask that because for a time I linked a (temporary, and now expired) PGP key to my LP profile, in order to make that system have upload / sign access to a PPA
[15:19] <teward> i know it's not ideal, but... :P
[15:23] <karstensrage> maybe it *does* make sense to have a packaging key separate from other keys, but i think it would probably ultra confusing in that if someone used the key for email or something besides packaging
[15:24]  * teward shrugs
[15:24] <teward> to each their own :)
[15:24] <teward> though you may want to try what you were doing first before going that route
[15:30] <karstensrage> the debsign program also seems to rewrite the .changes file is that right?
[15:31] <karstensrage> since the hashes all change after signing
[15:31] <cjwatson> It has to if it signs the .dsc file
[15:32] <karstensrage> yeah
[16:07] <toan_> cjwatson, i just want to check with you to know if the git recipe completed yet, if not when will it be completed and ready for testing?  thanks
[16:14] <cjwatson> toan_: https://blog.launchpad.net/cool-new-stuff/beta-test-git-recipes
[16:36] <toan_> cjwatson, @thanks
[16:58] <rbasak> It would be nice if https://git.launchpad.net/~ubuntu-server-dev/ led somewhere. Not sure where.
[16:58] <rbasak> Redirect to https://code.launchpad.net/~ubuntu-server-dev/+git perhaps?
[16:59] <rbasak> (I trimmed the URL from cgit to find a different repo)
[17:01] <cjwatson> Yeah, possibly - could we have a bug please (against the turnip project)?  Need to think a bit about how it knows when to redirect
[23:32] <teward> is it common for armhf builds in ppas to take over three hours, even when the same software also built in 1 hour on armhf ppa builders?
[23:32] <teward> (on a different Ubuntu version, mind you, but same PPA)
[23:39] <wgrant> teward: Examples?
[23:46] <teward> wgrant: the active ZNC build that took an hour longer than the others
[23:47] <teward> though it finished building
[23:47] <teward> meh, maybe it's just an odd hours difference in completion *shrugs*
[23:57] <wgrant> teward: There are millions of builds, so a link would be handy.
[23:57] <teward> wgrant: indeed, though it's a non-issue since it completed
[23:57] <teward> for a while i thought it was hung
[23:57] <teward> looks like it just took a long time to build one of the code files in the package is all :)
[23:57] <teward> once it did that, it was completed with compile and then built the package
[23:58] <teward> so issue disappeared, i guess