[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]


Peter Van Eynde <pvaneynd at debian.org> writes:
> On 04/03/11 23:52, Christoph Egger wrote:
>> Would be fine. I have experimented with disabling gengc on ia64 as
>> bilding with that option enabled won't work -- removing it selectively
>> would fix that. What's your opinion about that? That would be the head
>> commit on the experimental branch.
> That would be interesting to test. Often I do need to use the build
> machines to test stuff like this. Did you try this on an ia64 machine?
> Does the resulting binary work?

It builds on merulo -- the ia64 porterbox and the ecl binary seems to
work for basic stuff when setting LD_LIBRARY_PATH (I can't install
packages there so testing's currently like that. As there are no
libraries or so I didn't do more complete tests

>> Last question: What do you think about the v3 source formats, the dh7
>> style minimal rules files? I know there are people with stronger opinion
>> on that then me so I'll adopt to whatever the other people here would
>> prefer.
> Well.
> In the past I really really hated quilt.
> I thought that patches should be in git. But then you run into problem
> that you forget that you did a patch and upstream is unaware. So I
> wanted to keep patches in separate branches. That works fine until a new
> upstream comes along, because then you should rebase the patch.
> But you cannot rebase a branch that you pushed to a remote site...
> So you get lost in a forest of branches.

I have one topgit package still -- topgit does the git branch -> quilt
series thing and has some stuff to update for new upstreams. It's quite
good for the cases where git merge is powerful enough to update the
patches automatically but patch isn't. However this topgit isn't really
mature so I have stuck with quilt now for most of my stuff as well.

> quilt is easier to use, you just do 'quilt push -v -a' to see the
> sources with all your patches, and you do 'quilt new <patch name>' to
> start a new patch. 'quilt edit <filename>' to do the changes and then
> you ask quilt to register the patch with 'quilt refresh'.
> All in all this works nicely and should survive new upstream versions
> better. Also we can label the patches with DEP3 so it becomes clear why
> we have this patch and if we forwarded it upstream.
> I will integrate your changes to ECL in my new branch and then I will
> start working on sbcl.  But first I need to rebuild clisp...

SBCL should already be quilt maintained since (I guess .45).

> I will send a separate 'sync' email when I'm finished before we destroy
> the master branch and base that on the new quilted version.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 838 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/attachments/20110305/411b4386/attachment.pgp>

Reply to: