With respect to the package: Vcs-Git: git://git.debian.org/collab-maint/libreoffice-converter.git Vcs-Browser: http://git.debian.org/?p=collab-maint/libreoffice- converter.git;a=summary
On Saturday, April 07, 2012 05:05:21 AM Bernhard R. Link wrote: > * Paul Elliott <[email protected]> [120407 10:43]: > > My upstream released a new tar ball. > > I did a git-dpm import-new-upstream --ptc new-tarball. > > on this tarball. > > Followed by > > git-dpm dch -- -i > > > > I edited the changelog to indicate correct version. > > > > I really do not understand this from the man page: > > man> git-dpm dch -v newupstream-1 "new upstream version" > > Oh, there is a -- missing before -v in the manpage. > > It should be > git-dpm dch -- -v newupstream-1 "new upstream version" > > Everything after the -- is passed to dch (and is described in dch's > manpage) > > -i > tells dch to create a new changelog item with the new version being the > old version incremented. > > -v version > tell dch to create a new changelog item with the new version as given. > > Anything not being an option given to dch is taken as changelog message. > Only if no changelog message is given, it spawns an editor. > > So 'dch -v blabla "some text"' is the same like running 'dch -i', > replacing the version in the first line with 'blabla' moving to the > new line with '*' generated and appending 'some text' there. > > > I find it easier to edit the version > > as part of editing the changelog. > > One is as good as the other. git-dpm just calls dch with the arguments > you gave it and looks what debian/changelog looks like when that > returns. It does not matter how the contents are generated. > > > Then I saw a debian change that needed to be made > > requireing a minor (debian only) new version. > > > > I edited and git added debian/control (only), and tried to do > > a git-dpm dch -- -i > > That's how it is supposed to work. > > > Never made it to the editor. Instead I got > > > > > $ git-dpm dch -- -i > > > > > > git-dpm: ERROR: debian branch contains non-debian changes: > > > libreoffice-converter.spec > > > > libreoffice-converter.spec is a file the upstream modified > > in the last upstream release. (That I already pushed). > > > > What did I do wrong? > > That should only happen if that file has modifications not from > the patched branch (including the upstream branch). > > It's also strange that the first git-dpm dch did not show the first > message. > > Some reasons I can think of: > > - switching to the new upstream was not complete. i.e. there were > patches recorded that still need a git-dpm rebase-patched and > git-dpm update-patches. > (Though I do not understand why the first git-dpm dch has worked > then). This package has no patches. > > - the file has actually non-upstream changes. Did you perhaps try > a build between the two git-dpm calls and the build is modifying > that file? (in that case you might need to clean that up in > debian/rules clean). The file git-dpm is complaining about, libreoffice-converter.spec is identical to the version in the upstream release, but it is the file that release modified. > > - something else got corrupted. > In case of libreoffice-converter, the history of the master branch > does not look like something git-dpm would create, but rather > something you might get with a git rebase mixing the upstream and > the master branch together. You have > > the commit 72c2d2ea75d56c21b602b0def0cb12761b445c90 in the upstream > branch, which looks like the original. > > the commit 93cb3d76d5d546cdc5394d3220addd2a1e307e97 in the master > branch, which looks like a cherry-pick or rebase of the first. > > the commit 24d249845e9b37676e0dd7e48fab9bb7ecdec020 still recorded > as upstream in debian/.git-dpm, which is the previous upstream. > > That looks like there was a rebase done in master linearizing all > commits including the upstream branch. > This made it no longer contain your upstream branch and lost the > debian/.git-dpm changes (as those are changes in a merge rebase > loses them, but as the rebase also loses the commits its refer to > that does not matter that much). > > There are three ways to fix that: > - Go back to before the rebase, assuming you still have them in git's > log and you not care if the published branch moves non-forward. > > - Re-register and merge the correct upstream branch: > git-dpm new-upstream --allow-changes-in-debian-branch > ../libreoffice-converter_3.3.32.1+ds.orig.tar.gz (Note that this is The new upstream release is: libreoffice-converter_3.3.34.1+ds.orig.tar.gz That is 3.3.34.1 But the commit that should have changed it in debian/.git commit 72c2d2ea75d56c21b602b0def0cb12761b445c90 Author: Paul Elliott <[email protected]> Date: Sat Apr 7 01:16:21 2012 -0500 Import libreoffice-converter_3.3.34.1+ds.orig.tar.gz did not change the tarball field in debian/.git-dpm > # see git-dpm(1) from git-dpm package > 24d249845e9b37676e0dd7e48fab9bb7ecdec020 > 24d249845e9b37676e0dd7e48fab9bb7ecdec020 > 24d249845e9b37676e0dd7e48fab9bb7ecdec020 > 24d249845e9b37676e0dd7e48fab9bb7ecdec020 > libreoffice-converter_3.3.32.1+ds.orig.tar.gz > 5f0a015a03b20dddf73133e624fa7bcf5c1d8ceb > 6529 I fixed it going forward by doing: git-dpm new-upstream --allow-changes-in-debian-branch ../libreoffice-converter_3.3.34.1+ds.orig.tar.gz That fixed things so that new "git-dpm dch" now work, but I still have two commits that are messed up and can't be fixed because they are already published. In the future I will always check debian/.git-dpm after doing a import-new- upstream. and do a "git-dpm new-upstream --append" if it does not show the tarball changed. I wish this could be fixed so this is not needed. > new-upstream and not import-new-upstream as it is only about recording > your current 'upstream' branch and not creating it. Note that you need > --allow-changed-in-debian-branch and you will get a warning about them > because git-dpm only sees changes in your debian-branch (from the rebased > new upstream) and does not know that those changes it will discard are > exactly the changes it will merge in from the upstream branch again). > > > Hope that helps, > Bernhard R. Link > > _______________________________________________ > Git-dpm-user mailing list > [email protected] > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/git-dpm-user Thank You for your help. -- Paul Elliott 1(512)837-1096 [email protected] PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Git-dpm-user mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/git-dpm-user
