Patch fixing build failures of clisp on several archs

Peter Van Eynde pvaneynd at mailworks.org
Mon Sep 25 07:22:07 UTC 2017


Hello Sébastien,

> BTW, the git repository of clisp packaging is rather complex with many
> different branches (even one branch per release recently), making the
> git-buildpackage workflow uneasy.

My workflow predates a lot of the tooling available now...

I could not find another way of having ‘clean’ patches against upstream then by doing a ‘git rebase’ when a new upstream release comes out. So I have:


upstream v1-branch
   |
   \
    ——> Debian v1-1 branch

upstream v2-branch
   |
   \
    ——> Debian v2-1 branch

Where Debian v2-1 is Debian v1-1 rebased on top of upstream v2. This way it’s easy to backport changes and keep multiple versions alive.

I’m currently looking at the ZFS packages and they use tags and master/upstream and I get all lost. For example, https://github.com/Fabian-Gruenbichler/zfs.git <https://github.com/Fabian-Gruenbichler/zfs.git> debian/wip-0.7  branch has:

> commit a94f106d4ff94e6b9117e1dbc11ac98883382ae1
> Author: Brian Behlendorf <behlendorf1 at llnl.gov>
> Date:   Tue Aug 8 08:38:53 2017 -0700
> 
>     Fix dnode allocation race


While https://github.com/zfsonlinux/zfs.git <https://github.com/zfsonlinux/zfs.git> master has:


> commit 9631681b75336ec6265d8fa5cecb353687c1f373
> Author: Brian Behlendorf <behlendorf1 at llnl.gov>
> Date:   Tue Aug 8 08:38:53 2017 -0700
> 
>     Fix dnode allocation race

Notice that the commit ID is not the same, so I cannot even merge/pull/rebase. Color me very confused.

However if there is an easier and more standard way of doing things I would be all in favour of using if, provided that there is documentation in the form of ‘execute these commands’ to

- create a build
- create a new Debian release (go from -n to -n+1)
- integrate a new upstream release


Best regards, Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/attachments/20170925/1457061c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 971 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/attachments/20170925/1457061c/attachment.sig>


More information about the pkg-common-lisp-devel mailing list