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