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:48 |
---|---|---|
wgrant | dpm: git push lp:~dpm/dekko | 10:53 |
wgrant | https://help.launchpad.net/Code/Git | 10:53 |
dpm | great, thanks wgrant | 10:54 |
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:02 |
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:03 |
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:06 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
cjwatson | BTW you should make sure you've committed everything before git reset --hard! | 11:15 |
dpm | ok | 11:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:21 |
dpm | There is an 'origin/master' in the output of git branch -a, so I'll give master a go | 11:22 |
dpm | and it worked, thanks! | 11:23 |
cjwatson | Excellent | 11:27 |
=== xnox_ is now known as xnox | ||
=== nottrobin_ is now known as nottrobin | ||
karstensrage | hi | 14:45 |
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:46 |
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:52 |
karstensrage | ok and reading the man page for debrsign you specify .changes and it picks up .dsc from that | 14:54 |
cjwatson | Right, you don't normally have to do that bit manually | 14:55 |
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:57 |
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 | 14:59 |
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:00 |
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:01 |
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:03 |
karstensrage | cjwatson, dont think so, debsign seems to use a lot of functions that are in pbuilder | 15:12 |
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:13 |
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:14 |
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:15 |
cjwatson | Which you have to do in the -r mode - so that bit is entirely irrelevant for -r | 15:16 |
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:18 |
teward | i know it's not ideal, but... :P | 15:19 |
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:23 |
* 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:24 |
karstensrage | the debsign program also seems to rewrite the .changes file is that right? | 15:30 |
karstensrage | since the hashes all change after signing | 15:31 |
cjwatson | It has to if it signs the .dsc file | 15:31 |
karstensrage | yeah | 15:32 |
=== bdmurray_ is now known as bdmurray | ||
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:07 |
cjwatson | toan_: https://blog.launchpad.net/cool-new-stuff/beta-test-git-recipes | 16:14 |
toan_ | cjwatson, @thanks | 16:36 |
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:58 |
rbasak | (I trimmed the URL from cgit to find a different repo) | 16:59 |
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 | 17:01 |
=== aendrew_ is now known as aendrew | ||
=== andyrock_ is now known as andyrock | ||
=== dobey_ is now known as dobey | ||
=== cyphermox_ is now known as cyphermox | ||
=== mthaddon` is now known as mthaddon | ||
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:32 |
wgrant | teward: Examples? | 23:39 |
teward | wgrant: the active ZNC build that took an hour longer than the others | 23:46 |
teward | though it finished building | 23:47 |
teward | meh, maybe it's just an odd hours difference in completion *shrugs* | 23:47 |
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:57 |
teward | so issue disappeared, i guess | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!