Re: RFS: open-axiom
- To: Igor Pashev <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Re: RFS: open-axiom
- From: David Bremner <email@example.com>
- Date: Sun, 04 Sep 2011 11:35:12 -0300
- Message-id: <firstname.lastname@example.org>
- In-reply-to: <4E633CD3.email@example.com>
- References: <CALL-Q8z5AppFEH395+Stfw5C4N_QygWQmC4BGwLVPjqkyB9tTA@mail.gmail.com> <firstname.lastname@example.org> <CALL-Q8w5FC=x=SPXhDYjBwzzVkKh-6DsY2LkykZoH+p7C4GuWA@mail.gmail.com> <email@example.com> <4E5A6470.firstname.lastname@example.org> <CALL-Q8zP9MPwtEu_1zd1ML8Atd_3JMMy_enEAGbzpNMjjqf4email@example.com> <firstname.lastname@example.org> <CALL-Q8zujdn2AD3O7CNFhCncVYxtxwP2-Uub2CbeYJ9+zCg6ag@mail.gmail.com> <email@example.com> <4E5BA384.firstname.lastname@example.org> <email@example.com> <4E5CD4DA.firstname.lastname@example.org> <email@example.com> <4E62188B.firstname.lastname@example.org> <email@example.com> <4E623AEF.firstname.lastname@example.org> <email@example.com> <4E633CD3.firstname.lastname@example.org>
On Sun, 04 Sep 2011 12:54:43 +0400, Igor Pashev <email@example.com> wrote:
> 03.09.2011 19:22, David Bremner пишет:
> 1. Is it ok to use different lisps on different archs?
> Or is it better to wait for sbcl (in lenny there were many archs) ?
Yes, that is OK.
> 2. I set build-dep to sbcl >= 1.0.30, but I see sbcl has an epoch.
> Should I change it? sbcl >=2:1.0.30 (wheezy and sid have 2) ?
no, you don't need the epoch.
I pushed some things to
you might find interesting.
upstream has the upstream tarball imported
pristine-tar is auxilary data for the pristine tar utility
master has one patch to fix a lintian warning
build has merged debian packaging and upstream source.
It's up to you how you want to organize things, but I personally find it
most convenient to work with a branch like "build" and commit directly
there, after merging in the new upstream release. Most of my packaging
repos have such a branch as master. Most of the tools like gitpkg and
git-buildpackage expect such a branch.
Of course it costs a bit of diskspace to store the upstream source as
well, but github won't complain about 86M. And if they do you can always
Oh, and for next upload please add Vcs-Browser and Vcs-Git headers