On 10 May 2016 at 11:17, Mattia Rizzolo <mat...@debian.org> wrote: > Sorry for the delay, these days are crazy for me....
That's life, right?! :-) > On Fri, May 06, 2016 at 02:05:17PM -0400, Nicholas D Steeves wrote: >> I've just purged that repo and uploaded a bpo of libsndio to mentors. > > mh, no. > > There is already one in bpo-NEW from 2 days ago :) > https://ftp-master.debian.org/new/sndio_1.1.0-2~bpo8%2B1.html > > So, I'm going to use a local bpo of sndio instead (also because yours > would not be nice to upload due to the +2. why 2 identical changelog > entries??), and try to build audacious again. Tomorrow first thing in > the morning most probably. ;-) That's mine. I contacted Peter Piwowarski asking if he'd like me to maintain a backport as soon as I realised that an audacious bpo depended on having a sndio bpo in the archive. I'm not sure where two identical changelog entries for bpo+1 and bpo+2 came from...that's very strange. Thankfully my sponsor caught it during the application process! >> Message-ID: >> <CAD=qjkhx07nq17gnoeowi24vdrehy-nj52unctrv1e1uisa...@mail.gmail.com> > > On Thu, May 5, 2016 at 3:19 AM, Nicholas D Steeves <nstee...@gmail.com> wrote: >> Thank you very much for fixing the mess I made. To maintain this >> backport, is the following sequence of commands appropriate?: >> >> git checkout --detach --rebase debian/version-revision > > actually --detach shouldn't be needed at all, and I can't really see > what --rebase would do here (also because it's not even in > git-checkout(1)) It seems I somehow mixed up git-checkout and git-rebase. > Now, umh, with `push debian/%(bpo_tag)s would be what I usually do > without a branch. Ohhh, I think I'm starting to understand now. So what happens that the local master branch gets ahead of the remote without --detach, but that's ok. It's ok because git pushes a snapshot of the local changed state to a remote state is only referenced by the tag. If for some reason there was a bug in the debian/%(bpo_tag)s version, that's not in the debian/version-revision...well, that's where it feels strange to me. So then one would make further changes to the local repo, local master would get further out of sync from remote master, but that wouldn't matter because the local state of master is only ever reflected as a tag on the remote? Had I made my mistake at this point, it seems like it would have been a huge mess! > given that now a branch is used instead the workflow is: > > git checkout jessie-backports # enter the bpo branch > git merge debian/version-revision # merge changes since last bpo > # this might lead to > # conflicts in > changelog, but > # nothing impossible. > dch --bpo # update changelog > gbp buildpackage --git-tag # build+tag > git status > git add # same as above > git push # push the current branch > git push --tags # push the tag This makes sense to me, but I'm still unclear why "git checkout jessie-backports && git merge debian/version-revision" is preferred over "git rebase debian/version-revision", when version-bumping the bpo. I guess the question is: For a version bump of a bpo, should the changelog of a new-version bpo mention the previous bpo, or should it only contain a single "Rebuild for $stable-backports" entry? The semantics of checkout+merge seem to favour a bpo changelog that mentions prior versions (independent parallel branch with coherent history and imported updates), while the semantics of git rebase seem to favour a series of bpo forks (branch is a history of forks). I've consulted this doc: https://git-scm.com/docs/git-rebase Mattia, thank you for taking the time to help me understand, I appreciate it a lot, Nicholas _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers