Re: [Git-dpm-user] git-dpm thinks it is working with old upstream.
* Paul Elliott [120407 22:08]: > 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. import-new-upstream should always create the right debian/.git-dpm. I guess it was right after you run import-new-upstream, which I guess was Sat Apr 7 01:16:21 2012 -0500 (the commiter and author date of 72c2d2ea75d56c21b602b0def0cb12761b445c90). At Sat Apr 7 01:19:54 2012 -0500 there seems to have been the git-dpm dch recording the new version done (judging from the author time). But then Sat Apr 7 01:41:08 2012 -0500 the commits 93cb3d76d5d546cdc5394d3220addd2a1e307e97 and a333e312c1569f8adac4f90e045a4ecf3172ff99 were done (commit date), which (looking at the author timestamps and the commit messages) are most likely a rebase of 72c2d2ea75d56c21b602b0def0cb12761b445c90 and the git-dpm dch calls. I guess this rebase (besides making it no longer merging in your upstream branch but containing the chances as a commit directly modifying it) also dropped the commit merging upstream in your master branch and changing debian/.git-dpm. I cannot imagine how such a rebase could be done by git-dpm and guess you were doing it manually. If you did not do anything like that, I'd like to get a copy of your .git/logs/refs/heads/master file (via private mail if you prefer it not being public) so I might have a chance to guess what happened then. (That file should exist and show all past changes of the master branch done in that working copy if logging is enabled (which current git versions do by default)). Bernhard R. Link ___ Git-dpm-user mailing list Git-dpm-user@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/git-dpm-user
Re: [Git-dpm-user] git-dpm thinks it is working with old upstream.
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 [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 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-d
Re: [Git-dpm-user] git-dpm thinks it is working with old upstream.
* Paul Elliott [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). - 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). - 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 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). - manually fix it (only more error prone than the 2nd way I'd guess): git merge upstream sed -i -e "s/$(git rev-parse upstream^1)/$(git rev-parse upstream)/" debian/.git-dpm git add debian/.git-dpm git commit --amend Hope that helps, Bernhard R. Link ___ Git-dpm-user mailing list Git-dpm-user@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/git-dpm-user
