brian.campbell at editshare.com
Mon Feb 17 23:20:19 UTC 2014
Sorry for taking a while to respond, been a busy week, but now have
time to get back to Netatalk.
I cleaned up my patch and tried to push it, but it looks like I don't
have permission to write to the Git repository; it has owner and group
js, rather than having group scm_pkg-netatalk which would give me
On Tue, Feb 11, 2014 at 11:13 AM, Jonas Smedegaard <dr at jones.dk> wrote:
> Quoting Brian Campbell (2014-02-11 14:20:08)
>> On Mon, Feb 10, 2014 at 8:11 PM, Jonas Smedegaard <dr at jones.dk> wrote:
>> > I have prepared a new release here:
>> > git://anonscm.debian.org/git/pkg-netatalk/netatalk
>> Looks like you've been busy! That is looking pretty good.
> Thanks :-)
>> I needed to make the following change to get it to work; there's no
>> need to patch our own changelog during the build.
> Oh - I was wondering where that typo correction went :-)
>> Before I push, however, I have a few questions about Debian packaging
>> workflow; as I said, I'm new to it. For one, when updating the
>> changelog, do you generally update the version number while it's in
>> development? I noticed that it was still 2.2.2-2, instead of 2.2.5-1.
>> Also, when doing a collaborative release like this, do I change the
>> changelog trailer to include my name and email? That's the most
>> convenient since I use Debian Changelog mode in Emacs, which doesn't
>> allow you to add more items until you "unfinalize" the changelog
>> entry, and finalizing it again puts my own information in the trailer.
> The style that I use is to commit actual changes separately from
> changelog edits and automated changes caused by those.
> That style makes it easier to later revert a change or cherry-pick it
> for another branch (e.g. a stable security-update).
> Backside is that we then all need to be cautious when updating changelog
> to make sure we include all changes since changelog was last edited.
> I don't use Emacs so cannot help specifically (I use Midnight Commander)
> but if any help for you, this is the command I use (and always polish
> and proof-read manually before committing the result):
> git dch -a
> What I can imagine is that you extend your workflow to first run that
> command to catch previous commits by others not yet reflected in
> changelog, then commit that, and then use your finalize-each-change
> style for your own work. I then just hope that your tool can manage to
> commit the changelog separately from the actual changes.
Got it. Makes sense; I wasn't quite sure how to integrate git commit
messages with the Debian changelog. Just running "git dch -a" makes
sense. And if we're building the changelog based on the git commit
history, I don't need to worry about the emacs mode, I just won't
bother updating the changelog until we do it in a batch when uploading
>> And second, any time I tried to build this with simply "gbp
>> buildpackage -us -uc" I got the following error; however, if I use
>> "--export-dir=../netatalk-build" it works fine. Is this supposed to
>> work with just a plain "gbp buildpackage"? Do you have a particular
>> configuration of "git-buildpackage" that avoids this issue, or do you
>> simply always use an export dir?
> Seems it is simply the problem you mentioned initially: Patches don't
> apply cleanly.
> Please go ahead and correct that (to take credit for spotting it), and
> tell me if you still cannot build directly directly from the git.
Ah, I figured out why it wouldn't build. At some point in the process
of learning how to use git-buildpackage and uscan to update to
Netatalk 2.2.5, I had managed to generate a tarball in the parent
directory named netatalk_2.2.5.orig.tar.gz but which actually
contained Netatalk 3.1.0. It looks like it was picking that up and
trying to apply the patches to that, and of course failing as you
might expect. When I used --export-dir, it regenerated the tarball and
worked appropriately, but when running from the working copy it was
picking up the wrong tarball.
> I do use a custom wrapper but one modelled after gbp-buildpackage so
> should behave the same: Should work with and without --export-dir when
> a) upstream code is clean (patches must apply cleanly) and either b1)
> debian code is clean or b2) --git-ignore-new is applied.
> - Jonas
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136 Website: http://dr.jones.dk/
> [x] quote me freely [ ] ask before reusing [ ] keep private
> Pkg-netatalk-devel mailing list
> Pkg-netatalk-devel at lists.alioth.debian.org
More information about the Pkg-netatalk-devel