=== JanC_test_ is now known as JanC_test [12:17] Greetings [12:19] So, I had two branches: lp:kazam/stable and lp:kazam/unstable. It turns out that I pushed stable local copy into unstable branch. Now, the history of both branches is the same. It seems that I managed to overwrite everything. Can this be reversed somehow? [12:49] BigWhale: Unless you used push --overwrite, nothing is actually lost, you just end up looking at history from a different starting viewpoint [12:50] If one wants a private PPA but not everything else that comes with a commerical subscription, is there alternative pricing available beyond the normal $250 commercial sub? [12:50] maxb, yeah, I figured that things should still be there somewhere. :) I just have to revert them. [12:51] I had to ask just to be sure. :) [12:51] Thanks. [12:51] I've never heard of any alternative pricing structures be mentioned [12:53] BigWhale: Although you now have a slight issue that a LP automatic translations commit has landed in unstable on top of the pushed stable revisions [12:54] You could just choose to discard that, I guess, since I assume it would get re-exported at some point [12:55] yeah, that shouldn't be an issie [12:55] issue [13:08] maxb: I am failing to find a way on how to at least show what was done ... [13:13] There's no direct record of X changed to Y [13:13] I find the easiest thing to do is to use the 'bzr qlog' graphical log viewer to spot which revision should actually be the tip of the unstable branch [13:18] maxb, the problem is that it will show just those version from the branch I pushed. :) [13:18] no [13:19] Or yes, if you consider that the old tip revision of the unstable branch was actually contained within the history of the branch you pushed [13:19] However you use the terminology, the old tip revision of unstable is definitely within the set of revisions [13:20] well, I did merge from one branch to the other, back and forth, but those were just merges that were then pushed to the correct branch. [13:28] Perhaps I can simplify matters slightly... [13:30] So, I just looked in the history of the unstable branch, picked the appropriate revision, and pushed it to https://code.launchpad.net/~maxb/kazam/unstable [13:31] yeah that was the version I was looking for. :) [13:31] actually it was 398 .. so, now I just push this to unstable? [13:32] I can't see how it could have been 398 [13:33] You can push --overwrite to unstable once you're happy you're pushing the right thing [13:33] oh.. it was 397 ... [13:35] The other thing you could do, instead of overwriting at all... [13:35] Is to merge the current lp:kazam/unstable into a branch at 397 [13:36] Which you could then push back to lp:kazam/unstable, without overwrite, as a new r398, with the revision numbers you were previously accustomed to preceding it [13:38] Hmm, I'll think about it. [13:38] This option is the one I prefer. :) [13:38] I have to run now. Thanks for all the help! [15:11] uhhh [15:11] my upload was rejected [15:12] pastebinning [15:12] http://paste.ubuntu.com/5704982 [15:13] debuild -S -sd did say : dpkg-source: warning: diff `kde-baseapps-4.10.2/debian/patches/4.10.patch' patches file kde-baseapps-4.10.2/plasma/applets/folderview/iconview.cpp twice [15:13] would that be the cause? [15:39] i imported my ssh key to launchpad. after this how do i tell my ssh client to use this key??? [15:41] there isn't any ~/.ssh/config file in the location. [16:57] wgrant: ping [17:14] wgrant: I get this : http://paste.ubuntu.com/5704982 : when uploading a package, Riddell mentioned you probably know best why this happens [17:54] shadeslayer: Looks fairly clear cut that the rejection is because dpkg-source generated an error unpacking your source package - it ought to be replicable locally [17:57] not really, I can get pbuilder to build the whole package [17:57] otoh debuild -S -sd did say : dpkg-source: warning: diff `kde-baseapps-4.10.2/debian/patches/4.10.patch' patches file kde-baseapps-4.10.2/plasma/applets/folderview/iconview.cpp twice [18:03] I expect launchpad is operating in a treat-warnings-as-errors mode [18:04] Certainly one file being touched twice in a single patch is significantly anomalous [18:05] hmm [18:05] the patch I have is a combination of a series of patches [18:05] so it touches the same file twice [18:05] You should either represent them as multiple files, or apply them in sequence and then regenerate a composite patch [18:05] could make it into 2 patches, but that's a load of work [18:06] hmm [18:06] okay