Debian Bug report logs - #609047
ITP: ccl -- Clozure CL

Package: wnpp; Maintainer for wnpp is wnpp@debian.org;

Reported by: Darren Hoo <darren.hoo@gmail.com>

Date: Wed, 5 Jan 2011 19:21:02 UTC

Owned by: Faheem Mitha <faheem@faheem.info>

Severity: wishlist

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Darren <darren.hoo@gmail.com>:
Bug#609047; Package wnpp. (Wed, 05 Jan 2011 19:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Darren Hoo <darren.hoo@gmail.com>:
New Bug report received and forwarded. Copy sent to wnpp@debian.org, Darren <darren.hoo@gmail.com>. (Wed, 05 Jan 2011 19:21:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Darren Hoo <darren.hoo@gmail.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Cc: pkg-common-lisp-devel@lists.alioth.debian.org
Subject: ITP: ccl - Clozure CL
Date: Thu, 6 Jan 2011 03:16:58 +0800
Subject: ITP: ccl - Clozure CL
Package: wnpp
Owner: Darren <darren.hoo@gmail.com>
Severity: wishlist

* Package name    : ccl
  Version         : 1.6
  Upstream Author : Clozure Associates
* URL             : http://www.clozure.com/clozurecl.html
* License         : LLGPL (Lisp Lesser GNU Public License)
  Programming Lang: C, Lisp
  Description     : ccl - Clozure CL

I've used ccl for quite a while, lately after I tried
building it, I found that it was quite happy to hack
with its internals. but it is still missing in Debian.
There was a RFP (bug #531616) already, So I really
want to package it into Debian.

For now I have built the packages that can work with
Common Lisp Controller setup ie, install-clc, remove-clc
etc, but there are still several problems left to be
solved.

first, to build ccl there is a triple dependency between
kernel, boot-image and full-image.A big full-image from
upstream is needed to build from scratch.

I am wondering how SBCL first got into Debian since it
build-depends on SBCL itself. I have not found any way
to cross compile ccl using SBCL, if that's possible then
it is much easier.

and second, there are some problems when I try to split
the package into ccl and ccl-source , because ccl needs
lisp source file to work properly.
I'm currently working on this. Help is welcome.




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Darren <darren.hoo@gmail.com>:
Bug#609047; Package wnpp. (Thu, 13 Jan 2011 03:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Desmond O. Chang" <dochang@gmail.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Darren <darren.hoo@gmail.com>. (Thu, 13 Jan 2011 03:24:03 GMT) Full text and rfc822 format available.

Message #10 received at 609047@bugs.debian.org (full text, mbox):

From: "Desmond O. Chang" <dochang@gmail.com>
To: Darren Hoo <darren.hoo@gmail.com>, 609047@bugs.debian.org, pkg-common-lisp-devel@lists.alioth.debian.org
Subject: Re: ITP: ccl - Clozure CL
Date: Thu, 13 Jan 2011 11:21:40 +0800
Hi Darren,

On Thu, Jan 6, 2011 at 03:16, Darren Hoo <darren.hoo@gmail.com> wrote:

> * URL             : http://www.clozure.com/clozurecl.html

I think http://ccl.clozure.com/ provides more information.

> For now I have built the packages that can work with
> Common Lisp Controller setup ie, install-clc, remove-clc
> etc, but there are still several problems left to be
> solved.

Drop c-l-c integration.

http://article.gmane.org/gmane.linux.debian.alioth.common-lisp/2493

>
> first, to build ccl there is a triple dependency between
> kernel, boot-image and full-image.A big full-image from
> upstream is needed to build from scratch.
>
> I am wondering how SBCL first got into Debian since it
> build-depends on SBCL itself. I have not found any way
> to cross compile ccl using SBCL, if that's possible then
> it is much easier.
>
> and second, there are some problems when I try to split
> the package into ccl and ccl-source , because ccl needs
> lisp source file to work properly.
> I'm currently working on this. Help is welcome.

Running CCL only requires the kernel and the full-image (and
tools/asdf.lisp if you want)

I think you can upload a binary package like 'ccl-bootstrap' and build
the real 'ccl' package using it.  Then use 'ccl' to build the next
version directly.  This would implement self-hosting.

NOTE, no need to put the compiled kernel and image file in the source
package.  CCL has different images on i386, ppc, amd64 and arm, they
are all too big!

Thanks,
Des




Changed Bug title to 'ITP: ccl -- Clozure CL' from 'ITP: ccl - Clozure CL' Request was from Aníbal Monsalve Salazar <anibal@debian.org> to control@bugs.debian.org. (Wed, 16 Mar 2011 01:51:17 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Darren <darren.hoo@gmail.com>:
Bug#609047; Package wnpp. (Sun, 01 Jul 2012 16:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Darren <darren.hoo@gmail.com>. (Sun, 01 Jul 2012 16:51:06 GMT) Full text and rfc822 format available.

Message #17 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: Darren Hoo <darren.hoo@gmail.com>
Cc: "Desmond O. Chang" <dochang@gmail.com>, 609047@bugs.debian.org, pkg-common-lisp-devel@lists.alioth.debian.org
Subject: Re: ITP: ccl - Clozure CL (Debian bug #609047)
Date: Sun, 1 Jul 2012 22:10:56 +0530 (IST)
Hi Darren,

It seems you are the owner of this ITP against ccl. I was wondering what 
the current status is.

It seems from the bug thread that you have a working Debian ccl package 
for some recent version of ccl, as of 2011. If you are no longer working 
of this, would you considering publishing this packaging, preferably as a 
version control repository? Bitbucket (for Git and Mercurial) and GitHub 
(for Git) are both popular, though there are of course many other 
alternative hosting sites.

I'm interested in getting a ccl package into Debian. However, it doesn't 
seem efficient to start from scratch if there is a working version out 
there. Building on your work may be preferable.

If anyone else has any information about packaging ccl and/or is willing 
to assist with such packaging, even if only in an advisory capacity, let 
me know. Please CC me on any reply. Thanks.

                                                         Regards, Faheem




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Darren <darren.hoo@gmail.com>:
Bug#609047; Package wnpp. (Thu, 19 Jul 2012 06:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Darren <darren.hoo@gmail.com>. (Thu, 19 Jul 2012 06:12:03 GMT) Full text and rfc822 format available.

Message #22 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: openmcl-devel@clozure.com, debian-mentors@lists.debian.org, 609047@bugs.debian.org, pkg-common-lisp-devel@lists.alioth.debian.org
Subject: Preliminary Debian packaging for Clozure Common Lisp (ccl.clozure.com)
Date: Thu, 19 Jul 2012 11:31:56 +0530 (IST)
Hi,

Please CC replies to my email address. Thanks.

I have put my preliminary packaging of CCL on Bitbucket as a Mercurial
repository, located at https://bitbucket.org/faheem/ccl-debian-tmp

Please test and report problem and suggest improvements. For
preference, open an issue.

This packaging is relative to the recommened release checkout from
svn, i.e.

svn co http://svn.clozure.com/publicsvn/openmcl/release/1.8/linuxx86/ccl

per the documentation in

http://ccl.clozure.com/manual/chapter2.2.html#obtaining-via-svn
2.2.3.2.2. Downloading a Release Version

which appears to be equivalent to the tarball in
ftp://ftp.clozure.com/pub/release/1.8/ccl-1.8-linuxx86.tar.gz

Instructions for use:

i) Checkout out CCL sources from svn or download and unpack the tarball.

ii) Copy the cloned repository into the source directory as the debian/
subdirectory.

iii) Run

debuild binary

or a similar command in the source directory to produce the
binary. See `man debuild`.

This packaging should be considered preliminary, because it is not in
a form that would be acceptable for the Debian archives. The sources
above contain precompiled binaries for the x86 and amd64 archs. Since
CCL is not currently in the Debian archive, and since CCL requires
itself to compile. it is necessary to use precompiled binaries from
somewhere.

I was informed that the correct way to address this is to use the
source without any precompiled binaries, and have some adjunct binary
packages which contain necessary precompiled binaries which bootstrap
the compiler. More about this later.

I have some queries and comments about this packaging. I'll divide
this into Debian-specific and CCL-specific questions. So, the former
may be of interest to Debian people, and the latter to CCL people.

First, the Debian-specific questions.

1) I'd like to take over the outstanding ITP for CCL (#609047,
cc'd). I've written to Darren Ho, the creator of this ITP, on 1st July
2012, (see http://bugs.debian.org/609047), but have not yet received a
reply. What else do I need to do, if anything?

I guess I need to get a sponsor at some point. When should this happen?

2) The main outstanding issue is how to handle the bootstrapping
issue, namely that CCL is not in Debian, but requires CCL to compile.

R. Matthew Emerson wrote in the openmcl-devel mailing list

#####################################################################
But, that said, what I myself actually do is this:

1.  Check out the sources.  I use the svn:// scheme so that I can
    commit.  (Note that the "publicsvn" component of the URL used for
    the http: scheme is not used with the svn: scheme.)

    svn co svn://svn.clozure.com/openmcl/trunk/source ccl

2.  Get bootstrapping binaries from somewhere.

    One way to get them is via the following checkout:

    svn co --ignore-externals \
    svn://svn.clozure.com/openmcl/trunk/linuxx86/ccl bootstrap cp
    bootstrap/* ccl/

3.  Get interface databases from somewhere.

    cd ccl svn co svn://svn.clozure.com/openmcl/trunk/x86-headers svn
    co svn://svn.clozure.com/openmcl/trunk/x86-headers64
#######################################################################

It looks reasonable to me to divide up the build requirements into two
separate pieces, as Matthew suggests, namely the source, and second
the bootstrapping binaries and the interface database. However, I'm
not sure about the details of how this should be done. Some specific
questions.

First, it seems that the source should be the only thing in
*.orig.tar.gz, per usual Debian guidelines. From what I have read, it
seems that the other two items (binaries + interface databases) should
be in a separate "special" binary package (or packages). There would
be several of these packages to cover all the different archs.

I think Debian prefers pristine upstream tarballs, but I have also
seen versions of software get packaged, so I assume there is no
problem packaging the results of `svn co
svn://svn.clozure.com/openmcl/trunk/source` as *.orig.tar.gz.

As regards the binary stuff, I'm less clear what to do with it. The
idea would be just to stick the binaries + interface into a binary
(deb) package. So, does there need to be a corresponding
*.orig.tar.gz, *debian.tar.gz and *dsc to create this binary, or not?
Also, can I put both of these into one package? If so what should the
package be called? And where should the files live? Would a package
name like ccl-bootstrap, and location like /usr/lib/ccl-bootstrap/ be
Ok?

Now the CCL specific questions:

3) My current package description for the package is

######################################################################
Package: ccl
Architecture: i386 amd64
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: slime
Provides: lisp-compiler
Recommends: binfmt-support (>= 1.1.2)
Description: Common Lisp compiler and development system
 CCL  is a development environment for the ANSI Common Lisp language.
 It provides a native-code compiler and an integrated debugger, as well
 as all the features in the ANSI specification.
 .
 To browse CCL source definitions with development environments,
 install the ccl-source package. For documentation on CCL's usage and
 internals, the package ccl-doc, containing the CCL manual, is
 provided.
######################################################################

I'm sure it is possible to do better than this. By way of comparison,
here is the SBCL description this is based on.

#######################################################################
Description-en: Common Lisp compiler and development system
 SBCL is a development environment for the ANSI Common Lisp language.
 It provides a native-code compiler and an integrated debugger, as well
 as all the features in the ANSI specification.
 .
 SBCL also contains other extensions to the ANSI specification, including
 a foreign-function interface, a pseudo-server API, user-extensible
 stream functionality, a Meta-Object Protocol, and an ability to run
 external processes.
 .
 To browse SBCL source definitions with development environments,
 install the sbcl-source package. For documentation on SBCL's usage
 and internals, the package sbcl-doc is provided.
######################################################################

Feedback from CCL experts welcome.

4) Debian requires a copyright statement, which is located in the
"copyright" file in the repository. On installation it is installed in
/usr/share/doc/pkgname/copyright. Here is the current text, taken from
the openmcl package that was in Debian a few years ago.

###################################################################
This is a Debian prepackaged version of Clozure Common Lisp.  The
source code was obtained from ftp://ftp.clozure.com/.

Upstream Authors: Gary Byers <openmcl-devel@clozure.com> and Digitool,
Inc

Copyright (C) 1994-2003 Digitool, Inc

OpenMCL is licensed under the terms of the Lisp Lesser GNU Public
License (LLGPL).  The LLGPL consists of a preamble (see below) and the
Lessor GNU Public License 2.1 (LGPL-2.1).  Where these conflict, the
preamble takes precedence.  OpenMCL is referenced in the preamble as
the "LIBRARY." On Debian systems the complete text of the LGPL 2.1 is
in the file /usr/share/common-licenses/LGPL-2.1. The preamble is
located in the file doc/LICENSE, in the CCL sources, and it is
reproduced verbatim below.

[this is followed by the preamble text]
####################################################################

Developers, please comment on this text as appropriate. In particular,
the copyright information is probably out of date.

5) The doc/src/makefile-common that builds the manual could use a
little TLC. Specifically, the `make all` target does not make the
multi-page html version of the manual, for no reason I can think of,
though it *is* built by the `make install` target.

I'm not sure what the

(cd .. ; $(SVN) commit -m "updated" ccl-documentation.html)

line is supposed to do. I assume this is for internal use. Also, the
`make clean` target for this makefile doesn't actually clean the
generated targets as one would expect, namely
doc/ccl-documentation.html, doc/src/ccl-documentation.html and
doc/manual, but only the build directory in which the single-html page
version of the manual is built.

IMO, having an install target here is a little bit out of
place. Usually the install target is for when a generated binary is
being written to somewhere on a system, but here it is just being
written somewhere else in the source tree.

Since your current install target does two things, namely copy
doc/src/ccl-documentation.html to doc/ccl-documentation.html, and
generate doc/manual (not counting the svn commit thing), I suggest you
get rid of the install target, (unless you want it for the svn
commit), and move these to `make all`. Then get rid of the two copies
of ccl-documentation.html, and just have the $(HTMLFILES) target move
ccl-documentation.html from the build directory to
doc/ccl-documentation.html.

On a tangential note, the source should probably not contain
doc/ccl-documentation.html, which is a generated file.

                                                      Regards, Faheem




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Darren <darren.hoo@gmail.com>:
Bug#609047; Package wnpp. (Tue, 14 Aug 2012 11:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Egger <christoph@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Darren <darren.hoo@gmail.com>. (Tue, 14 Aug 2012 11:09:03 GMT) Full text and rfc822 format available.

Message #27 received at 609047@bugs.debian.org (full text, mbox):

From: Christoph Egger <christoph@debian.org>
To: Faheem Mitha <faheem@faheem.info>
Cc: openmcl-devel@clozure.com, debian-mentors@lists.debian.org, 609047@bugs.debian.org, pkg-common-lisp-devel@lists.alioth.debian.org
Subject: Re: Preliminary Debian packaging for Clozure Common Lisp (ccl.clozure.com)
Date: Tue, 14 Aug 2012 12:45:34 +0200
Hi!

  Please Send any mail also directly to me if you're interested in my
Input as I'm not reading -mentors regularly and pkg-common-lisp-devel@
is -- it appears -- not getting enough of my attention to see your
messages in time.

Faheem Mitha <faheem@faheem.info> writes:
> 1) I'd like to take over the outstanding ITP for CCL (#609047,
> cc'd). I've written to Darren Ho, the creator of this ITP, on 1st July
> 2012, (see http://bugs.debian.org/609047), but have not yet received a
> reply. What else do I need to do, if anything?

  Send a mail to the bug report explaining that you'll take over and set
yourself as the owner of the bug.

> I guess I need to get a sponsor at some point. When should this happen?

  It needs to be done once you have a package ready on mentors.debian.net

> 2) The main outstanding issue is how to handle the bootstrapping
> issue, namely that CCL is not in Debian, but requires CCL to compile.

  For sbcl I do bootstrapping with a crossbuild from another
architecture .. building just a non-packaged version and using that to
bring up the package. Once there is a version in the archive everything
works automatically. So ideally I can build the first package with a
locally installed ccl (e.g. in /usr/local/bin, ..). sbcl's debian/rules
has some magic now to do this (and the last commit is totally messed up
:-(

  I guess bootstrapping only needs to be done once and later versions of
ccl can be built using the version that is then included in Debian?

> 3) My current package description for the package is
> 4) Debian requires a copyright statement, which is located in the
> "copyright" file in the repository. On installation it is installed in
> /usr/share/doc/pkgname/copyright. Here is the current text, taken from
> the openmcl package that was in Debian a few years ago.
>
> ###################################################################
> OpenMCL is licensed under ...
CCL?
> ####################################################################
>

Regards

    Christoph



Owner changed from Darren <darren.hoo@gmail.com> to Faheem Mitha <faheem@faheem.info>. Request was from Faheem Mitha <faheem@faheem.info> to control@bugs.debian.org. (Wed, 15 Aug 2012 01:03:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#609047; Package wnpp. (Wed, 15 Aug 2012 04:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Wed, 15 Aug 2012 04:15:03 GMT) Full text and rfc822 format available.

Message #34 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: Christoph Egger <christoph@debian.org>
Cc: openmcl-devel@clozure.com, debian-mentors@lists.debian.org, 609047@bugs.debian.org, pkg-common-lisp-devel@lists.alioth.debian.org
Subject: Re: Preliminary Debian packaging for Clozure Common Lisp (ccl.clozure.com)
Date: Wed, 15 Aug 2012 09:41:28 +0530 (IST)
Hi Christoph,

Thank you for your response. Feedback from members of Debian's Common Lisp 
team is always helpful.

On Tue, 14 Aug 2012, Christoph Egger wrote:

> Hi!
>
>  Please Send any mail also directly to me if you're interested in my
> Input as I'm not reading -mentors regularly and pkg-common-lisp-devel@
> is -- it appears -- not getting enough of my attention to see your
> messages in time.

Ok, I'll do that.

> Faheem Mitha <faheem@faheem.info> writes:
>> 1) I'd like to take over the outstanding ITP for CCL (#609047,
>> cc'd). I've written to Darren Ho, the creator of this ITP, on 1st July
>> 2012, (see http://bugs.debian.org/609047), but have not yet received a
>> reply. What else do I need to do, if anything?
>
>  Send a mail to the bug report explaining that you'll take over and set
> yourself as the owner of the bug.

Done.

>> I guess I need to get a sponsor at some point. When should this happen?
>
>  It needs to be done once you have a package ready on mentors.debian.net

Ok. I should be able to upload to mentors soon.

>> 2) The main outstanding issue is how to handle the bootstrapping
>> issue, namely that CCL is not in Debian, but requires CCL to compile.
>
>  For sbcl I do bootstrapping with a crossbuild from another
> architecture .. building just a non-packaged version and using that to
> bring up the package. Once there is a version in the archive everything
> works automatically. So ideally I can build the first package with a
> locally installed ccl (e.g. in /usr/local/bin, ..). sbcl's debian/rules
> has some magic now to do this (and the last commit is totally messed up
> :-(

Could one just use upstream binaries instead? CCL has upstream binaries 
available, which I use to initially build my Debian package, for at least 
i386 and amd64. My package currently does not attempt to build on any 
other architecture, because I can't test it.

>  I guess bootstrapping only needs to be done once and later versions of
> ccl can be built using the version that is then included in Debian?

Well this is precisely my question to the CCL developers. So far, I have 
not got a response. See the thread 
http://thread.gmane.org/gmane.lisp.openmcl.devel/8046

I'm copied you on my most recent message to that thread. If you don't want 
me to CC you, let me know.

>> 3) My current package description for the package is
>> 4) Debian requires a copyright statement, which is located in the
>> "copyright" file in the repository. On installation it is installed in
>> /usr/share/doc/pkgname/copyright. Here is the current text, taken from
>> the openmcl package that was in Debian a few years ago.

>> ###################################################################
>> OpenMCL is licensed under ...
> CCL?
>> ####################################################################

I've fixed that. Thanks.

As mentioned elsewhere, my Debian CCL packaging is at 
https://bitbucket.org/faheem/ccl-debian

You may want to glance at 
https://bitbucket.org/faheem/ccl-debian/src/tip/README.source which goes 
into some detail about my current build strategy.

                                                         Regards, Faheem



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Faheem Mitha <faheem@faheem.info>:
Bug#609047; Package wnpp. (Sun, 19 Aug 2012 13:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Egger <christoph@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Faheem Mitha <faheem@faheem.info>. (Sun, 19 Aug 2012 13:36:03 GMT) Full text and rfc822 format available.

Message #39 received at 609047@bugs.debian.org (full text, mbox):

From: Christoph Egger <christoph@debian.org>
To: Faheem Mitha <faheem@faheem.info>
Cc: openmcl-devel@clozure.com, debian-mentors@lists.debian.org, 609047@bugs.debian.org, pkg-common-lisp-devel@lists.alioth.debian.org
Subject: Re: Preliminary Debian packaging for Clozure Common Lisp (ccl.clozure.com)
Date: Sun, 19 Aug 2012 15:34:04 +0200
Hi again

Faheem Mitha <faheem@faheem.info> writes:
>>> 2) The main outstanding issue is how to handle the bootstrapping
>>> issue, namely that CCL is not in Debian, but requires CCL to compile.
>>
>>  For sbcl I do bootstrapping with a crossbuild from another
>> architecture .. building just a non-packaged version and using that to
>> bring up the package. Once there is a version in the archive everything
>> works automatically. So ideally I can build the first package with a
>> locally installed ccl (e.g. in /usr/local/bin, ..). sbcl's debian/rules
>> has some magic now to do this (and the last commit is totally messed up
>> :-(
>
> Could one just use upstream binaries instead? CCL has upstream
> binaries available, which I use to initially build my Debian package,
> for at least i386 and amd64. My package currently does not attempt to
> build on any other architecture, because I can't test it.

  Jep that'll work you just need to provide the sponsor with enough
information to bootstrap the package with binaries from a sane enough
source (and I'd consider upstream such a source). Best to add this
information to debian/README.source IMHO.

>>  I guess bootstrapping only needs to be done once and later versions of
>> ccl can be built using the version that is then included in Debian?
>
> Well this is precisely my question to the CCL developers. So far, I
> have not got a response. See the thread
> http://thread.gmane.org/gmane.lisp.openmcl.devel/8046

  If it's not possible to build ccl with a (slightly) older version of ccl
it'll be pain to maintain. One can (as Peter noted in the thread) go the
cmucl route but that'll need the maintainer (you) to do bootstrapping
every time, the sponsor to do bootstrapping every time and for evvery
architeccture you might want to support (as you might have noticed cmucl
is only available on linux-i386 and not even on 64bit systems)

Regards

    Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer



Information forwarded to debian-bugs-dist@lists.debian.org, pvaneynd@mailworks.org, christoph@debian.org, openmcl-devel@clozure.com, pkg-common-lisp-devel@lists.alioth.debian.org, faheem@faheem.info, wnpp@debian.org:
Bug#609047; Package wnpp. (Sun, 19 Aug 2012 13:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to pvaneynd@mailworks.org, christoph@debian.org, openmcl-devel@clozure.com, pkg-common-lisp-devel@lists.alioth.debian.org, faheem@faheem.info, wnpp@debian.org. (Sun, 19 Aug 2012 13:51:06 GMT) Full text and rfc822 format available.

Message #44 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: submit@bugs.debian.org
Cc: 609047@bugs.debian.org
Subject: RFS: ccl/1.8+svn15443-1 [ITP]
Date: Sun, 19 Aug 2012 19:18:58 +0530 (IST)
X-Debbugs-CC: Peter Van Eynde <pvaneynd@mailworks.org>, Christoph Egger <christoph@debian.org>, openmcl-devel@clozure.com, pkg-common-lisp-devel@lists.alioth.debian.org, Faheem Mitha <faheem@faheem.info>
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ccl"

  * Package name    : ccl
    Version         : 1.8+svn15443-1
    Upstream Author : Clozure Associates
  * URL             : http://ccl.clozure.com
  * License         : LLGPL
    Section         : lisp

It builds those binary packages:

  ccl   - Common Lisp compiler and development system
  ccl-source - Source code files for CCL

To access further information about this package, please visit the following URL:

  http://mentors.debian.net/package/ccl

Alternatively, one can download the package with dget using this command:

  dget -x http://mentors.debian.net/debian/pool/main/c/ccl/ccl_1.8+svn15443-1.dsc

More information about CCL can be obtained from http://ccl.clozure.com.

Rationale: aka, why should Debian bother with this software?

CCL has a long history. Its ancestor Coral Common Lisp had its first
release in 1987. An earlier version of CCL was in Debian as OpenMCL,
circa the sarge release, but was later removed.

There are currently around 7 active (at least somewhat) free (in the
sense of the Debian DFSG) CL implementations, listed on
http://common-lisp.net/~dlw/LispSurvey.html, which seems in line with
my personal observations. These are

  ABCL, CMUCL, CCL, ECL, GCL, CLISP, and SBCL.

Of these, CMUCL, ECL, GCL, CLISP, and SBCL are currently in
Debian. Of this group of 7, CCL seems to be used more often than
most. SBCL is the most popular by a long way, but CCL is up
there. I'm a Common Lisp beginner, but my impresssion of CCL is that
is a high quality implementation and actively maintained. It has a
very reliable garbage collector, something that can be a weak point
in CL implementations. Also, it is fast, compared to most of the
others in this group. I have found bugs in SBCL. Thus far, I have
found none in CCL. As a Debian user, I think CCL should be in
Debian, and hope having CCL in Debian will make it more
popular. This concludes the rationale.

To initially build the package, you will need upstream binaries,
which I have packaged as ccl-bootstrap, and also uploaded to
mentors, for convenience. The package information is as follows:

  * Package name    : ccl-bootstrap
    Version         : 1.8+svn15443-1
    Upstream Author : Clozure Associates
  * URL             : http://ccl.clozure.com
  * License         : LLGPL
    Section         : lisp

It builds those binary packages:

  ccl-bootstrap - Binaries for bootstrapping Clozure Common Lisp

To access further information about this package, please visit the following URL:

  http://mentors.debian.net/package/ccl-bootstrap

Alternatively, one can download the package with dget using this command:

  dget -x http://mentors.debian.net/debian/pool/main/c/ccl-bootstrap/ccl-bootstrap_1.8+svn15443-1.dsc

My Debian packagings of ccl and ccl-bootstrap are available as
Mercurial repositories at https://bitbucket.org/faheem/ccl-debian
and https://bitbucket.org/faheem/ccl-bootstrap-debian.

For further information about building CCL, see the README.source in
the ccl packaging, e.g. at
https://bitbucket.org/faheem/ccl-debian/src/tip/README.source

Thanks to the IRC channel #debian-mentors on OFTC for much help with
packaging issues.

                                               Regards, Faheem Mitha



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#609047; Package wnpp. (Sun, 19 Aug 2012 13:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Sun, 19 Aug 2012 13:57:03 GMT) Full text and rfc822 format available.

Message #49 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: Christoph Egger <christoph@debian.org>
Cc: openmcl-devel@clozure.com, debian-mentors@lists.debian.org, 609047@bugs.debian.org, pkg-common-lisp-devel@lists.alioth.debian.org
Subject: Re: Preliminary Debian packaging for Clozure Common Lisp (ccl.clozure.com)
Date: Sun, 19 Aug 2012 19:25:11 +0530 (IST)

On Sun, 19 Aug 2012, Christoph Egger wrote:

> Hi again
>
> Faheem Mitha <faheem@faheem.info> writes:

>> Could one just use upstream binaries instead? CCL has upstream
>> binaries available, which I use to initially build my Debian package,
>> for at least i386 and amd64. My package currently does not attempt to
>> build on any other architecture, because I can't test it.
>
>  Jep that'll work you just need to provide the sponsor with enough
> information to bootstrap the package with binaries from a sane enough
> source (and I'd consider upstream such a source). Best to add this
> information to debian/README.source IMHO.

Yes, I've done that. The README.source is now quite extensive. See 
https://bitbucket.org/faheem/ccl-debian/src/tip/README.source

>>>  I guess bootstrapping only needs to be done once and later versions of
>>> ccl can be built using the version that is then included in Debian?

>> Well this is precisely my question to the CCL developers. So far, I
>> have not got a response. See the thread
>> http://thread.gmane.org/gmane.lisp.openmcl.devel/8046

>  If it's not possible to build ccl with a (slightly) older version of ccl
> it'll be pain to maintain. One can (as Peter noted in the thread) go the
> cmucl route but that'll need the maintainer (you) to do bootstrapping
> every time, the sponsor to do bootstrapping every time and for evvery
> architeccture you might want to support (as you might have noticed cmucl
> is only available on linux-i386 and not even on 64bit systems)

Agreed. Bootstrapping every time will be painful. Currently the package 
only builds on i386 and amd64, since I can't test it. If the sponsor wants 
it, it can easily be extended to build on other platforms, but I won't be 
able to test it.

I uploaded CCL to http://mentors.debian.net/ today, and just sent out a 
RFS (and CCed you).

                                                        Regards, Faheem



Added blocking bug(s) of 609047: 685307 Request was from Bart Martens <bartm@quantz.debian.org> to control@bugs.debian.org. (Sun, 19 Aug 2012 15:09:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Faheem Mitha <faheem@faheem.info>:
Bug#609047; Package wnpp. (Wed, 21 Aug 2013 13:48:32 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lucas Nussbaum <lucas@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Faheem Mitha <faheem@faheem.info>. (Wed, 21 Aug 2013 13:48:32 GMT) Full text and rfc822 format available.

Message #56 received at 609047@bugs.debian.org (full text, mbox):

From: Lucas Nussbaum <lucas@debian.org>
To: 609047@bugs.debian.org
Cc: control@bugs.debian.org
Subject: ccl: changing back from ITP to RFP
Date: Wed, 21 Aug 2013 15:44:10 +0200
retitle 609047 RFP: ccl -- Clozure CL
noowner 609047
tag 609047 - pending
thanks

Hi,

A long time ago, you expressed interest in packaging ccl. Unfortunately,
it seems that it did not happen. In Debian, we try not to keep ITP bugs open
for a too long time, as it might cause other prospective maintainers to
refrain from packaging the software.

This is an automatic email to change the status of ccl back from ITP
(Intent to Package) to RFP (Request for Package), because this bug hasn't seen
any activity during the last 10 months.

If you are still interested in packaging ccl, please send a mail to
<control@bugs.debian.org> with:

 retitle 609047 ITP: ccl -- Clozure CL
 owner 609047 !
 thanks

It is also a good idea to document your progress on this ITP from time to
time, by mailing <609047@bugs.debian.org>.  If you need guidance on how to
package this software, please reply to this email, and/or contact the
debian-mentors@lists.debian.org mailing list.

Thank you for your interest in Debian,
-- 
Lucas, for the QA team <debian-qa@lists.debian.org>



Changed Bug title to 'RFP: ccl -- Clozure CL' from 'ITP: ccl -- Clozure CL' Request was from Lucas Nussbaum <lucas@debian.org> to control@bugs.debian.org. (Wed, 21 Aug 2013 13:53:27 GMT) Full text and rfc822 format available.

Removed annotation that Bug was owned by Faheem Mitha <faheem@faheem.info>. Request was from Lucas Nussbaum <lucas@debian.org> to control@bugs.debian.org. (Wed, 21 Aug 2013 13:53:27 GMT) Full text and rfc822 format available.

Changed Bug title to 'ITP: ccl -- Clozure CL' from 'RFP: ccl -- Clozure CL' Request was from Faheem Mitha <faheem@faheem.info> to control@bugs.debian.org. (Tue, 10 Sep 2013 18:33:10 GMT) Full text and rfc822 format available.

Owner recorded as Faheem Mitha <faheem@faheem.info>. Request was from Faheem Mitha <faheem@faheem.info> to control@bugs.debian.org. (Tue, 10 Sep 2013 19:57:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#609047; Package wnpp. (Tue, 10 Sep 2013 20:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Tue, 10 Sep 2013 20:03:04 GMT) Full text and rfc822 format available.

Message #69 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: control@bugs.debian.org
Cc: Julien Danjou <acid@debian.org>, Christoph Egger <christoph@debian.org>, Peter Van Eynde <pvaneynd@debian.org>, pkg-common-lisp-devel@lists.alioth.debian.org, 609047@bugs.debian.org
Subject: update on CCL packaging status (resent)
Date: Wed, 11 Sep 2013 01:25:27 +0530 (IST)
retitle 609047 ITP: ccl -- Clozure CL
owner 609047 !
thanks

[Please CC responses to the bug report at 609047@bugs.debian.org]

Hi,

The current state of this package is reflected in the repositories 
https://bitbucket.org/faheem/ccl-debian and 
https://bitbucket.org/faheem/ccl-ffigen-debian

The packaging is essentially done. Earlier this year Julien Danjou submitted 
ccl-ffigen to NEW, (ccl-ffigen is a build dependency on ccl) and it got bounced 
by someone on the FTP masters team with the following message:

####################################################################
Date: Tue, 09 Apr 2013 21:00:37 +0000
From: Luca Falavigna <ftpmaster@debian.org>
To: Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, 
Faheem Mitha <faheem@faheem.info>, acid@debian.org
Subject: ccl-ffigen_1.2-1_amd64.changes REJECTED

Hi,

sorry, but we do not think introducing a convenience copy of gcc
is a good thing. Also, the 4.0 sources contain files licensed under
GFDL with invariant sections, which are not suitable for main.

Please try to build your code using existing gcc versions in the archive
implementing Built-Using field.

Cheers,
Luca

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.
####################################################################

I think the writer misunderstood the point of the package, which is to build 
interface headers for ccl, and is pretty much hardwired to 4.0. Getting it to 
work for more recent versions of GCC is an extremely non-trivial task that I 
doubt anyone but the author of that code would attempt.

I haven't had time to follow up on this, and I expect Julien is similarly busy. 
So there matters rest for the moment.

The main outstanding thing that (probably) should be fixed before the CCL 
package itself is ready to be submitted to NEW is to remove the local copy of 
ASDF from CCL and configure CCL to look for the Debian installation of ASDF. I 
think at least Christoph Egger suggested this, and it is clearly a good idea.

Feedback/comments welcome as always.
                                                           Regards, Faheem



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#609047; Package wnpp. (Wed, 11 Sep 2013 01:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Wed, 11 Sep 2013 01:03:04 GMT) Full text and rfc822 format available.

Message #74 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: Luca Falavigna <ftpmaster@debian.org>
Cc: Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, acid@debian.org, 609047@bugs.debian.org
Subject: Re: ccl-ffigen_1.2-1_amd64.changes REJECTED
Date: Wed, 11 Sep 2013 06:29:04 +0530 (IST)
On Tue, 9 Apr 2013, Luca Falavigna wrote:

> Hi,
>
> sorry, but we do not think introducing a convenience copy of gcc
> is a good thing. Also, the 4.0 sources contain files licensed under
> GFDL with invariant sections, which are not suitable for main.
>
> Please try to build your code using existing gcc versions in the archive
> implementing Built-Using field.
>
> Cheers,
> Luca
>
> ===
>
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.

Extremely belated reply to this message, I've been busy. But if I waited 
for a good time, this might never be answered.

I think the package was rejected based on a misunderstanding.

As described at 
https://bitbucket.org/faheem/ccl-ffigen-debian/src/tip/README.Debian?at=default 
this package exists to build CCL's interface databases.

As described in http://trac.clozure.com/ccl/wiki/CustomFramework (FFI
is Foreign Function Interface)

"""To support its FFI, CCL maintains a binary database of information
about classes, methods, functions, types, and variables available from
foreign libraries in several ".cdb" files. You will need to generate
this information for your particular library. In order to do this, you
will need to obtain and build ffigen4. """

This has little or nothing to do with GCC per se. It is *not* a fork.
Basically, it uses the GCC frontend for a purpose that is presumably
sufficiently similar to conventional compilation to enable a compiler
frontend to be used., namely building .cdb files which reflect the C
API of some .h files. I'm fuzzy about the details myself.

Anyway, getting it to build the code using existing versions of GCC in the 
archive would be impracticably difficult for a non-expert. (For the 
record, getting CCL to build correctly and in particular build the 
interface databases in question was quite hair-raisingly difficult 
enough.) If you doubt me, look at the 'source' subdirectory in the ffigen 
tarball, which has the patches against gcc 4.0, and tell me if you 
understand what they do.

I doubt even the main CCL developers would attempt it. They farmed out
the job to someone else years ago, who used the then-current GCC
compiler to get this to work. I could dig up more details, and talk to
the CCL developers themselves (who are usually grumpy and not
particularly sympathetic towards Debian, however) if you really need
further clarification. I'm including the ffigen README below, which
adds some details and history.

As for the documentation thing, I guess I could just strip out the
doc/FDL files from the tarball?

                                                          Regards, Faheem.

###########################################################################

# $Log$
# Revision 1.2  2005/08/10 05:05:46  gb
# Updated.
#
# Revision 1.1  2005/04/08 07:03:16  gb
# New file.
#

'ffigen' is a modified version of the GCC backend, based on similar
modifications to the 'LCC' compiler described at:

<http://www.ccs.neu.edu/home/lth/ffigen/index.html>

It's a work derived from GCC, and therefore licensed under the GPL.

Versions of ffigen - based on GCC 2.95 sources - were distributed
as adjunct components of OpenMCL in 2001 and 2002.  It's become
increasingly difficult to use those versions, since they're sensitive
to the exact format of the 2.95 C preprocessor output (and since GCC
2.95 is fading into obsolescence.)  The source distributions consisted
of a set of patches (relative to a canonical 2.95 source tree) and
a README file that explained the build process.

In the summer of 2004, Helmut Eller made available a set of patches
relative to GCC 3.4.1.  (Unlike previous versions, GCC 3.x's
preprocessor and frontend are a single program, so an ffigen program
derived from GCC 3 is likely to be a little more self-contained than
earlier versions.)

This version is based on GCC 4.0, builds on Helmut's work, and adds
some initial support for translating Objective-C class and method
information.  In addition, it provides a heavily conditionalized
Makefile which builds a binary package (.tar.gz file) on both LinuxPPC
and DarwinPPC.

In order to build the program, it's necessary to obtain canonical
versions of GCC (with ObjC support) for the target platform; the
Makefile tersely explains what's missing and suggests where to find
it.  You need to obtain the following files from gcc.gnu.org or a
mirror site and install them in this directory:

gcc-core-4.0.0.tar.bz2
gcc-objc-4.0.0.tar.bz2

Once those archives are installed, doing:

shell> make

will build the modified frontend, create an archive containing that
frontend and related support files, and create a text file explaining
how to install things.

These patches are maintained in CVS on clozure.com.  For anonymous
access:

shell> cvs -d :pserver:cvs@clozure.com:/usr/local/publiccvs login

[The anonymous CVS password is 'cvs']

shell> cvs -d :pserver:cvs@clozure.com:/usr/local/publiccvs get ffigen4



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Faheem Mitha <faheem@faheem.info>:
Bug#609047; Package wnpp. (Wed, 11 Sep 2013 04:33:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faré <fahree@gmail.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Faheem Mitha <faheem@faheem.info>. (Wed, 11 Sep 2013 04:33:04 GMT) Full text and rfc822 format available.

Message #79 received at 609047@bugs.debian.org (full text, mbox):

From: Faré <fahree@gmail.com>
To: Faheem Mitha <faheem@faheem.info>
Cc: control@bugs.debian.org, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, Julien Danjou <acid@debian.org>, 609047@bugs.debian.org
Subject: Re: update on CCL packaging status (resent)
Date: Wed, 11 Sep 2013 00:30:56 -0400
>: Faheem Mitha
> The main outstanding thing that (probably) should be fixed before the CCL
> package itself is ready to be submitted to NEW is to remove the local copy
> of ASDF from CCL and configure CCL to look for the Debian installation of
> ASDF. I think at least Christoph Egger suggested this, and it is clearly a
> good idea.
>
That's a totally crazy thing to do, of the kind of horror that was
necessary in the days of ASDF 1. Please don't do it. If Christoph
suggested it, he might have been traumatized in those days.

Please let CCL come with its own ASDF 3, or maybe ASDF 2, if you're
packaging the CCL release rather than trunk.

ASDF 3 is a big boy, and will upgrade itself to the version from
debian, if available, and will know how NOT to downgrade itself, thank
you.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
In a free market there are no market failures, only market opportunities.
In a bureaucracy there is no possible success, only a perpetual
ever-worsening crisis.



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#609047; Package wnpp. (Wed, 11 Sep 2013 08:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Wed, 11 Sep 2013 08:27:04 GMT) Full text and rfc822 format available.

Message #84 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: Faré <fahree@gmail.com>
Cc: Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, Julien Danjou <acid@debian.org>, 609047@bugs.debian.org, Christoph Egger <christoph@debian.org>, Peter Van Eynde <pvaneynd@debian.org>
Subject: Re: update on CCL packaging status (resent)
Date: Wed, 11 Sep 2013 13:52:13 +0530 (IST)
[Message part 1 (text/plain, inline)]
On Wed, 11 Sep 2013, Faré wrote:

>> : Faheem Mitha

>> The main outstanding thing that (probably) should be fixed before the 
>> CCL package itself is ready to be submitted to NEW is to remove the 
>> local copy of ASDF from CCL and configure CCL to look for the Debian 
>> installation of ASDF. I think at least Christoph Egger suggested this, 
>> and it is clearly a good idea.

> That's a totally crazy thing to do, of the kind of horror that was 
> necessary in the days of ASDF 1. Please don't do it. If Christoph 
> suggested it, he might have been traumatized in those days.

> Please let CCL come with its own ASDF 3, or maybe ASDF 2, if you're 
> packaging the CCL release rather than trunk.

> ASDF 3 is a big boy, and will upgrade itself to the version from debian, 
> if available, and will know how NOT to downgrade itself, thank you.

Hi Faré.

Sorry, I did not mean to distress you.

I'm ccing Christoph and Peter in case they have comments.

My reasons for suggesting this is that it is in line with Debian 
policy.that says you should not have local copies of libraries already in 
the Debian archives.

Yes, I'd be packaging the release.

Can you elaborate on the reasons why looking to an external ASDF is not a 
good idea? I assume that having multiple versions of ASDF in the archive 
is Ok. This is done for lots of other packages.

In any case, the ftp masters will need to be ok with this.

Christoph/Peter/anybody, comments?
                                                          Regards, Faheem

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Faheem Mitha <faheem@faheem.info>:
Bug#609047; Package wnpp. (Wed, 11 Sep 2013 16:18:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faré <fahree@gmail.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Faheem Mitha <faheem@faheem.info>. (Wed, 11 Sep 2013 16:18:04 GMT) Full text and rfc822 format available.

Message #89 received at 609047@bugs.debian.org (full text, mbox):

From: Faré <fahree@gmail.com>
To: Faheem Mitha <faheem@faheem.info>
Cc: Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, Julien Danjou <acid@debian.org>, 609047@bugs.debian.org, Christoph Egger <christoph@debian.org>, Peter Van Eynde <pvaneynd@debian.org>
Subject: Re: update on CCL packaging status (resent)
Date: Wed, 11 Sep 2013 12:14:37 -0400
>>> : Faheem Mitha
>> Please let CCL come with its own ASDF 3, or maybe ASDF 2, if you're
>> packaging the CCL release rather than trunk.
>
>> ASDF 3 is a big boy, and will upgrade itself to the version from debian,
>> if available, and will know how NOT to downgrade itself, thank you.
>
>
> Hi Faré.
>
> Sorry, I did not mean to distress you.
>
> I'm ccing Christoph and Peter in case they have comments.
>
> My reasons for suggesting this is that it is in line with Debian policy.that
> says you should not have local copies of libraries already in the Debian
> archives.
>
This policy makes a lot of sense for libraries,
but does not make sense for ASDF, which is more of a library-loader,
and in this case, is tied to the implementation.

> Can you elaborate on the reasons why looking to an external ASDF is not a
> good idea? I assume that having multiple versions of ASDF in the archive is
> Ok. This is done for lots of other packages.
>
For the horror of ASDF1 days and its upgrade strategy, see
http://fare.livejournal.com/149264.html

The issue is: when an implementation comes with an updated version of
ASDF that it depends on, then the packager of that implementation must
update the ASDF package in debian, and make sure it works with all
other packaged implementations. Oops. Now you have an expensive
coordination problem. And if any implementation depends on patches
that didn't make it to an ASDF release yet, you're really screwed.

Also, now that ASDF 3 includes its own mechanism for self-upgrade and
avoiding self-downgrade, and will automatically look at the
debian-provided version if available (and unless told not to), you
don't gain much, if at all, by doing these complex packaging tricks.
Any time that your packaging tricks would have helped, ASDF 3 will
already bring the same benefits at the tiny cost of loading an extra
FASL for the newer ASDF. And then there are the times when the tricks
come back to bite you in the ass, so let just ASDF 3 sort it out.

In the bad old days of ASDF 1, few implementations shipped with ASDF,
and those that did usually sported an obsolete version. Special
packaging tricks for ASDF were not just useful, but necessary. These
days are happily long gone.

> In any case, the ftp masters will need to be ok with this.
>
I don't see why not. ASDF needn't count as a library. Plus it's
relatively small (depending on the implementation, the order of
magnitude of the installed copy is 1MB), and copied only once per
implementation, of which there are but a handful (in debian: sbcl,
clisp, ecl, now ccl, formerly gcl).

The only debian-packaged common lisp that doesn't work well with ASDF
3 is GCL, but then again, I believe GCL hasn't been re-packaged in
Debian in quite some time. And it's not like it worked that great with
ASDF 1, either. Also, it requires an old version of libgmp, if I
understand correctly, and sorely needs some re-packaging.

PS: it looks like current CCL trunk fails to pre-compile the asdf.lisp
it packages. Unless you wait for them to fix that, you may want to do
it yourself.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If a vegetarian eats vegetables, what does a humanitarian eat? — Mark Twain



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#609047; Package wnpp. (Wed, 11 Sep 2013 18:06:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Wed, 11 Sep 2013 18:06:05 GMT) Full text and rfc822 format available.

Message #94 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: Faré <fahree@gmail.com>
Cc: Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, Julien Danjou <acid@debian.org>, 609047@bugs.debian.org, Christoph Egger <christoph@debian.org>, Peter Van Eynde <pvaneynd@debian.org>
Subject: Re: update on CCL packaging status (resent)
Date: Wed, 11 Sep 2013 23:33:23 +0530 (IST)
[Message part 1 (text/plain, inline)]
Hi Faré,

Sorry to put you to the trouble of having to explain this again. I'm
sure you have had to do it before.

On Wed, 11 Sep 2013, Faré wrote:

>> Can you elaborate on the reasons why looking to an external ASDF is
>> not a good idea? I assume that having multiple versions of ASDF in
>> the archive is Ok. This is done for lots of other packages.

> For the horror of ASDF1 days and its upgrade strategy, see
> http://fare.livejournal.com/149264.html

> The issue is: when an implementation comes with an updated version
> of ASDF that it depends on, then the packager of that implementation
> must update the ASDF package in debian, and make sure it works with
> all other packaged implementations. Oops. Now you have an expensive
> coordination problem. And if any implementation depends on patches
> that didn't make it to an ASDF release yet, you're really screwed.

> Also, now that ASDF 3 includes its own mechanism for self-upgrade
> and avoiding self-downgrade, and will automatically look at the
> debian-provided version if available (and unless told not to), you
> don't gain much, if at all, by doing these complex packaging tricks.
> Any time that your packaging tricks would have helped, ASDF 3 will
> already bring the same benefits at the tiny cost of loading an extra
> FASL for the newer ASDF. And then there are the times when the
> tricks come back to bite you in the ass, so let just ASDF 3 sort it
> out.

> In the bad old days of ASDF 1, few implementations shipped with
> ASDF, and those that did usually sported an obsolete
> version. Special packaging tricks for ASDF were not just useful, but
> necessary. These days are happily long gone.

Ok. I don't really understand the details, and I don't have a problem
with an internal ASDF.

But just to play devil's advocate, it is possible to have multiple
versions of ASDF installed simultaneously, right?

And is it common (or is there even an actual known case) of an
implementation depending on a patched ASDF? Or even being very
sensitive to the particular ASDF version?

>> In any case, the ftp masters will need to be ok with this.

> I don't see why not. ASDF needn't count as a library. Plus it's
> relatively small (depending on the implementation, the order of
> magnitude of the installed copy is 1MB), and copied only once per
> implementation, of which there are but a handful (in debian: sbcl,
> clisp, ecl, now ccl, formerly gcl).

Ok. I don't personally care, but if the ftp masters object (assuming
that the CCL package actually gets to the point of being reviewed by
them), then is it Ok if I point them to you?

BTW, the current status as you can see on the 609047 bug thread, is
that the ccl-ffigen package, which is used to build the interface
databases for CCL, was rejected by the ftpmasters as it was a copy of
GCC, or something. This happened in April, but I only just got around
to writing a response. You can see the email in the bug thread.

If I get around to updating the package to the current CCL, would you
be willing to test it?

> The only debian-packaged common lisp that doesn't work well with
> ASDF 3 is GCL, but then again, I believe GCL hasn't been re-packaged
> in Debian in quite some time. And it's not like it worked that great
> with ASDF 1, either. Also, it requires an old version of libgmp, if
> I understand correctly, and sorely needs some re-packaging.

> PS: it looks like current CCL trunk fails to pre-compile the
> asdf.lisp it packages. Unless you wait for them to fix that, you may
> want to do it yourself.

Any version of CCL that I package for Debian will be the release. So I
guess this is not an issue.

                                                       Regards, Faheem

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Faheem Mitha <faheem@faheem.info>:
Bug#609047; Package wnpp. (Wed, 11 Sep 2013 19:54:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faré <fahree@gmail.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Faheem Mitha <faheem@faheem.info>. (Wed, 11 Sep 2013 19:54:04 GMT) Full text and rfc822 format available.

Message #99 received at 609047@bugs.debian.org (full text, mbox):

From: Faré <fahree@gmail.com>
To: Faheem Mitha <faheem@faheem.info>
Cc: Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, Julien Danjou <acid@debian.org>, 609047@bugs.debian.org, Christoph Egger <christoph@debian.org>, Peter Van Eynde <pvaneynd@debian.org>
Subject: Re: update on CCL packaging status (resent)
Date: Wed, 11 Sep 2013 15:50:02 -0400
On Wed, Sep 11, 2013 at 2:03 PM, Faheem Mitha <faheem@faheem.info> wrote:
> Sorry to put you to the trouble of having to explain this again. I'm
> sure you have had to do it before.
>
No problem.

>> In the bad old days of ASDF 1, few implementations shipped with
>> ASDF, and those that did usually sported an obsolete
>> version. Special packaging tricks for ASDF were not just useful, but
>> necessary. These days are happily long gone.
>
> Ok. I don't really understand the details, and I don't have a problem
> with an internal ASDF.
>
> But just to play devil's advocate, it is possible to have multiple
> versions of ASDF installed simultaneously, right?
>
Depends what you mean by "installed", but I'll take it that you mean
(a) each installed implementation's precompiled asdf FASL.
(b) the source-only code installation (NO precompiled FASL) from the
cl-asdf package, to be compiled in each user's personal FASL cache
with whatever implementation he uses (if any).

These are different enough things that I wouldn't call them "multiple
versions of ASDF installed simultaneously". And the magic of ASDF 3 is
that you, the debian packager, need not do any magic about it anymore,
like in the bad old days of ASDF 1.

> And is it common (or is there even an actual known case) of an
> implementation depending on a patched ASDF? Or even being very
> sensitive to the particular ASDF version?
>
It is common for an implementation to depend on a recent enough ASDF,
whether patched or not. The ASDF maintainer (previously, me) is
usually quick enough to merge patches upstream, though ASDF release
can lag a month (or sometimes two) after such patch merge.

>> I don't see why not. ASDF needn't count as a library. Plus it's
>> relatively small (depending on the implementation, the order of
>> magnitude of the installed copy is 1MB), and copied only once per
>> implementation, of which there are but a handful (in debian: sbcl,
>> clisp, ecl, now ccl, formerly gcl).
>
> Ok. I don't personally care, but if the ftp masters object (assuming
> that the CCL package actually gets to the point of being reviewed by
> them), then is it Ok if I point them to you?
>
Of course.

> BTW, the current status as you can see on the 609047 bug thread, is
> that the ccl-ffigen package, which is used to build the interface
> databases for CCL, was rejected by the ftpmasters as it was a copy of
> GCC, or something. This happened in April, but I only just got around
> to writing a response. You can see the email in the bug thread.
>
I saw that. As a fallback, could you "just" consider the bootstrapped
.cdb files as "source"? Or is the issue due to your trying to build
more .cdb files than CCL usually comes with?

> If I get around to updating the package to the current CCL, would you
> be willing to test it?
>
Most gladly. Are you packaging from trunk or from the latest CCL
release? I personally prefer trunk, but I can totally see a case for
the release branch.

>> PS: it looks like current CCL trunk fails to pre-compile the
>> asdf.lisp it packages. Unless you wait for them to fix that, you may
>> want to do it yourself.
>
> Any version of CCL that I package for Debian will be the release. So I
> guess this is not an issue.
>
Actually, this is an issue since CCL 1.6, that will hopefully be fixed
in trunk soon — see http://trac.clozure.com/ccl/ticket/1111

So, please make sure you pre-compile ASDF as part of your installation
of the CCL.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
It has been my observation that most people get ahead during the time
that others waste. — Henry Ford



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#609047; Package wnpp. (Wed, 11 Sep 2013 21:30:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Wed, 11 Sep 2013 21:30:09 GMT) Full text and rfc822 format available.

Message #104 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: Faré <fahree@gmail.com>, 609047@bugs.debian.org
Cc: Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, Julien Danjou <acid@debian.org>, Christoph Egger <christoph@debian.org>, Peter Van Eynde <pvaneynd@debian.org>
Subject: Re: Bug#609047: update on CCL packaging status (resent)
Date: Thu, 12 Sep 2013 02:56:52 +0530 (IST)
[Message part 1 (text/plain, inline)]
On Wed, 11 Sep 2013, Faré wrote:

> On Wed, Sep 11, 2013 at 2:03 PM, Faheem Mitha <faheem@faheem.info> wrote:

>> But just to play devil's advocate, it is possible to have multiple 
>> versions of ASDF installed simultaneously, right?

> Depends what you mean by "installed", but I'll take it that you mean (a) 
> each installed implementation's precompiled asdf FASL. (b) the 
> source-only code installation (NO precompiled FASL) from the cl-asdf 
> package, to be compiled in each user's personal FASL cache with whatever 
> implementation he uses (if any).

> These are different enough things that I wouldn't call them "multiple 
> versions of ASDF installed simultaneously". And the magic of ASDF 3 is 
> that you, the debian packager, need not do any magic about it anymore, 
> like in the bad old days of ASDF 1.

Sorry if I was unclear. I meant multiple cl-asdf Debian packages installed 
simultaneously, corresponding to different ASDF versions. I.e. option (b).

Here I am imagining a world where CL implementations don't have their own 
private copy of ASDF.

If I understand you correctly, (a) corresponds the case where the 
implementations do have their private implementation.

>> And is it common (or is there even an actual known case) of an
>> implementation depending on a patched ASDF? Or even being very
>> sensitive to the particular ASDF version?
>>
> It is common for an implementation to depend on a recent enough ASDF,
> whether patched or not. The ASDF maintainer (previously, me) is
> usually quick enough to merge patches upstream, though ASDF release
> can lag a month (or sometimes two) after such patch merge.

I've read the second sentence several times, but I don't get it. "Merge 
patches upstream" implies there is a downstream. Are there multiple forks 
of ASDF? Do the implementations develop/modify ASDF themselves? I got the 
impression they just take some released version of ASDF and stick it in, 
often only after been told by an ASDF maintainer.

>> Ok. I don't personally care, but if the ftp masters object (assuming 
>> that the CCL package actually gets to the point of being reviewed by 
>> them), then is it Ok if I point them to you?

> Of course.

Great, thanks.

>> BTW, the current status as you can see on the 609047 bug thread, is 
>> that the ccl-ffigen package, which is used to build the interface 
>> databases for CCL, was rejected by the ftpmasters as it was a copy of 
>> GCC, or something. This happened in April, but I only just got around 
>> to writing a response. You can see the email in the bug thread.

> I saw that. As a fallback, could you "just" consider the bootstrapped 
> .cdb files as "source"? Or is the issue due to your trying to build more 
> .cdb files than CCL usually comes with?

I'm like 100% sure Debian would not go for shipping the .cdb files from 
upstream, and I'd have to agree with them there. Anyway, generating the 
.cdb files is not a problem now, though it was ridiculously hard to get 
working correctly initially. No, the main issue is just that the 
ftpmasters don't like copies of libraries (or just software generally) 
that is already in Debian. And they considered ffigen to contain such a 
copy of gcc, though the outdated 4.0. In his email, Luca made the 
ridiculous suggestion that I should update ffigen for versions of gcc 
currently in Debian.

>> If I get around to updating the package to the current CCL, would you 
>> be willing to test it?

> Most gladly. Are you packaging from trunk or from the latest CCL 
> release? I personally prefer trunk, but I can totally see a case for the 
> release branch.

The latest CCL release. I don't think Debian cares, but it seems the
more natural thing to do. If it ever actually hits Debian, and enough
people want trunk instead, I could switch to trunk.

>>> PS: it looks like current CCL trunk fails to pre-compile the asdf.lisp 
>>> it packages. Unless you wait for them to fix that, you may want to do 
>>> it yourself.

>> Any version of CCL that I package for Debian will be the release. So I 
>> guess this is not an issue.

> Actually, this is an issue since CCL 1.6, that will hopefully be fixed 
> in trunk soon — see http://trac.clozure.com/ccl/ticket/1111

> So, please make sure you pre-compile ASDF as part of your installation 
> of the CCL.

Ok, but I'll need instructions on how to do this.
                                                         Regards, Faheem

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Faheem Mitha <faheem@faheem.info>:
Bug#609047; Package wnpp. (Thu, 12 Sep 2013 15:48:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faré <fahree@gmail.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Faheem Mitha <faheem@faheem.info>. (Thu, 12 Sep 2013 15:48:07 GMT) Full text and rfc822 format available.

Message #109 received at 609047@bugs.debian.org (full text, mbox):

From: Faré <fahree@gmail.com>
To: Faheem Mitha <faheem@faheem.info>
Cc: 609047@bugs.debian.org, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, Julien Danjou <acid@debian.org>, Christoph Egger <christoph@debian.org>, Peter Van Eynde <pvaneynd@debian.org>
Subject: Re: Bug#609047: update on CCL packaging status (resent)
Date: Thu, 12 Sep 2013 11:43:50 -0400
Dear Faheem,

>>> But just to play devil's advocate, it is possible to have multiple
>>> versions of ASDF installed simultaneously, right?
>>
>> Depends what you mean by "installed", but I'll take it that you mean (a)
>> each installed implementation's precompiled asdf FASL. (b) the source-only
>> code installation (NO precompiled FASL) from the cl-asdf package, to be
>> compiled in each user's personal FASL cache with whatever implementation he
>> uses (if any).
>
>> These are different enough things that I wouldn't call them "multiple
>> versions of ASDF installed simultaneously". And the magic of ASDF 3 is that
>> you, the debian packager, need not do any magic about it anymore, like in
>> the bad old days of ASDF 1.
>
> Sorry if I was unclear. I meant multiple cl-asdf Debian packages installed
> simultaneously, corresponding to different ASDF versions. I.e. option (b).
>
You don't get it. The current, working, solution is to have *both*
(a) one precompiled copy of ASDF with *each* implementation, and
(b) optionally, *one* installed source copy of ASDF from package cl-asdf.

This is a WORKING solution. Please don't change that until and unless
you can propose another solution that actually works —
and you understand enough of the problem that you can argue why it works,
and why it assuages all existing concerns.


> Here I am imagining a world where CL implementations don't have their own
> private copy of ASDF.
>
Is it even possible?
We *need* a precompiled ASDF in each implementation's binary package, anyway.
And each implementation's upstream source package comes with an approved and
tested version of ASDF known to work with it.

Is what you really mean is that you believe you can improve on things by
introducing a tight coupling between implementations and asdf, by replacing
each implementation's source copy of asdf by the version from cl-asdf,
at package build time? This sounds awfully complex, for precious little gain,
and great problems introduced by this new coupling.

> If I understand you correctly, (a) corresponds the case where the
> implementations do have their private implementation.
>
Wrong. It's not an either/or. It's an and.
Each implementation MUST provide a precompiled asdf
for use with (require ...) and this CANNOT be done via package cl-asdf,
only via each implementation's binary package.

>>> And is it common (or is there even an actual known case) of an
>>> implementation depending on a patched ASDF? Or even being very
>>> sensitive to the particular ASDF version?
>>>
>> It is common for an implementation to depend on a recent enough ASDF,
>> whether patched or not. The ASDF maintainer (previously, me) is
>> usually quick enough to merge patches upstream, though ASDF release
>> can lag a month (or sometimes two) after such patch merge.
>
> I've read the second sentence several times, but I don't get it. "Merge
> patches upstream" implies there is a downstream. Are there multiple forks of
> ASDF? Do the implementations develop/modify ASDF themselves? I got the
> impression they just take some released version of ASDF and stick it in,
> often only after been told by an ASDF maintainer.
>
Each implementation's copy of ASDF is conceptually a fork,
and used to actually be, in the dark days of ASDF 1;
in those days, there wasn't even a good common versioning system,
and each implementation had patches over
some unspecified CVS release of the official ASDF.
Since the days of ASDF 2, the official ASDF maintainers (i.e. me)
has been responsive enough about merging implementation-specific patches
that implementations don't bother actively forking ASDF,
but instead send their patches that get immediately integrated (or
improved upon).
Therefore, most implementations at most time include
some stable release of ASDF (e.g. 3.0.2);
at times, however, some implementations eager to release
despite an incompatibility discovered in the upstream ASDF
have shipped with a development version of ASDF
(e.g. hypothetically, 3.0.2.5, still from the official version control),
or worse, a locally patched version of ASDF
(e.g. hypothetically, 3.0.2.2 plus some patch).


>> Are you packaging from trunk or from the latest CCL release?
>> I personally prefer trunk, but I can totally see a case for the release
>> branch.
>
> The latest CCL release. I don't think Debian cares, but it seems the
> more natural thing to do. If it ever actually hits Debian, and enough
> people want trunk instead, I could switch to trunk.
>
I don't have a strong opinion.

>> Actually, this is an issue since CCL 1.6, that will hopefully be fixed in
>> trunk soon — see http://trac.clozure.com/ccl/ticket/1111
>
>> So, please make sure you pre-compile ASDF as part of your installation of
>> the CCL.
>
> Ok, but I'll need instructions on how to do this.
>
cd $CCL_DEFAULT_DIRECTORY
./lx86cl64 --no-init --eval '(progn (compile-file "tools/asdf") (quit))'

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Laziness is mother of Intelligence. Father unknown. [Rumor has it it's Greed.]
    — Faré



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#609047; Package wnpp. (Sun, 29 Sep 2013 20:09:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Sun, 29 Sep 2013 20:09:08 GMT) Full text and rfc822 format available.

Message #114 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: Luca Falavigna <ftpmaster@debian.org>
Cc: Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, acid@debian.org, 609047@bugs.debian.org
Subject: Re: ccl-ffigen_1.2-1_amd64.changes REJECTED
Date: Mon, 30 Sep 2013 01:33:36 +0530 (IST)
Hi,

I don't mean to be impatient, but would it be possible for the FTP Master 
team to make a call on this, please? It does not seem like *so* difficult 
a technical issue.

                                                           Thanks, Faheem

On Wed, 11 Sep 2013, Faheem Mitha wrote:

>
> On Tue, 9 Apr 2013, Luca Falavigna wrote:
>
>> Hi,
>> 
>> sorry, but we do not think introducing a convenience copy of gcc
>> is a good thing. Also, the 4.0 sources contain files licensed under
>> GFDL with invariant sections, which are not suitable for main.
>> 
>> Please try to build your code using existing gcc versions in the archive
>> implementing Built-Using field.
>> 
>> Cheers,
>> Luca
>> 
>> ===
>> 
>> Please feel free to respond to this email if you don't understand why
>> your files were rejected, or if you upload new files which address our
>> concerns.
>
> Extremely belated reply to this message, I've been busy. But if I waited for 
> a good time, this might never be answered.
>
> I think the package was rejected based on a misunderstanding.
>
> As described at 
> https://bitbucket.org/faheem/ccl-ffigen-debian/src/tip/README.Debian?at=default 
> this package exists to build CCL's interface databases.
>
> As described in http://trac.clozure.com/ccl/wiki/CustomFramework (FFI
> is Foreign Function Interface)
>
> """To support its FFI, CCL maintains a binary database of information
> about classes, methods, functions, types, and variables available from
> foreign libraries in several ".cdb" files. You will need to generate
> this information for your particular library. In order to do this, you
> will need to obtain and build ffigen4. """
>
> This has little or nothing to do with GCC per se. It is *not* a fork.
> Basically, it uses the GCC frontend for a purpose that is presumably
> sufficiently similar to conventional compilation to enable a compiler
> frontend to be used., namely building .cdb files which reflect the C
> API of some .h files. I'm fuzzy about the details myself.
>
> Anyway, getting it to build the code using existing versions of GCC in the 
> archive would be impracticably difficult for a non-expert. (For the record, 
> getting CCL to build correctly and in particular build the interface 
> databases in question was quite hair-raisingly difficult enough.) If you 
> doubt me, look at the 'source' subdirectory in the ffigen tarball, which has 
> the patches against gcc 4.0, and tell me if you understand what they do.
>
> I doubt even the main CCL developers would attempt it. They farmed out
> the job to someone else years ago, who used the then-current GCC
> compiler to get this to work. I could dig up more details, and talk to
> the CCL developers themselves (who are usually grumpy and not
> particularly sympathetic towards Debian, however) if you really need
> further clarification. I'm including the ffigen README below, which
> adds some details and history.
>
> As for the documentation thing, I guess I could just strip out the
> doc/FDL files from the tarball?
>
>                                                          Regards, Faheem.
>
> ###########################################################################
>
> # $Log$
> # Revision 1.2  2005/08/10 05:05:46  gb
> # Updated.
> #
> # Revision 1.1  2005/04/08 07:03:16  gb
> # New file.
> #
>
> 'ffigen' is a modified version of the GCC backend, based on similar
> modifications to the 'LCC' compiler described at:
>
> <http://www.ccs.neu.edu/home/lth/ffigen/index.html>
>
> It's a work derived from GCC, and therefore licensed under the GPL.
>
> Versions of ffigen - based on GCC 2.95 sources - were distributed
> as adjunct components of OpenMCL in 2001 and 2002.  It's become
> increasingly difficult to use those versions, since they're sensitive
> to the exact format of the 2.95 C preprocessor output (and since GCC
> 2.95 is fading into obsolescence.)  The source distributions consisted
> of a set of patches (relative to a canonical 2.95 source tree) and
> a README file that explained the build process.
>
> In the summer of 2004, Helmut Eller made available a set of patches
> relative to GCC 3.4.1.  (Unlike previous versions, GCC 3.x's
> preprocessor and frontend are a single program, so an ffigen program
> derived from GCC 3 is likely to be a little more self-contained than
> earlier versions.)
>
> This version is based on GCC 4.0, builds on Helmut's work, and adds
> some initial support for translating Objective-C class and method
> information.  In addition, it provides a heavily conditionalized
> Makefile which builds a binary package (.tar.gz file) on both LinuxPPC
> and DarwinPPC.
>
> In order to build the program, it's necessary to obtain canonical
> versions of GCC (with ObjC support) for the target platform; the
> Makefile tersely explains what's missing and suggests where to find
> it.  You need to obtain the following files from gcc.gnu.org or a
> mirror site and install them in this directory:
>
> gcc-core-4.0.0.tar.bz2
> gcc-objc-4.0.0.tar.bz2
>
> Once those archives are installed, doing:
>
> shell> make
>
> will build the modified frontend, create an archive containing that
> frontend and related support files, and create a text file explaining
> how to install things.
>
> These patches are maintained in CVS on clozure.com.  For anonymous
> access:
>
> shell> cvs -d :pserver:cvs@clozure.com:/usr/local/publiccvs login
>
> [The anonymous CVS password is 'cvs']
>
> shell> cvs -d :pserver:cvs@clozure.com:/usr/local/publiccvs get ffigen4
>



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Faheem Mitha <faheem@faheem.info>:
Bug#609047; Package wnpp. (Wed, 26 Feb 2014 11:54:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Rafael Jesús Alcántara Pérez <ralcantara@dedaloingenieros.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Faheem Mitha <faheem@faheem.info>. (Wed, 26 Feb 2014 11:54:04 GMT) Full text and rfc822 format available.

Message #119 received at 609047@bugs.debian.org (full text, mbox):

From: Rafael Jesús Alcántara Pérez <ralcantara@dedaloingenieros.com>
To: 609047@bugs.debian.org
Subject: Re: ITP: ccl - Clozure CL
Date: Wed, 26 Feb 2014 12:44:19 +0100
Hi:

Is there any advance on this ITP?

Greets.
Rafael J. Alcántara Pérez.
-- 




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#609047; Package wnpp. (Wed, 26 Feb 2014 15:39:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Wed, 26 Feb 2014 15:39:05 GMT) Full text and rfc822 format available.

Message #124 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: Rafael Jesús Alcántara Pérez <ralcantara@dedaloingenieros.com>, 609047@bugs.debian.org
Cc: Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>
Subject: Re: Bug#609047: ITP: ccl - Clozure CL
Date: Wed, 26 Feb 2014 20:59:28 +0530 (IST)
[Message part 1 (text/plain, inline)]
On Wed, 26 Feb 2014, Rafael Jesús Alcántara Pérez wrote:

> Hi:
>
> Is there any advance on this ITP?

Hi Rafael,

Thanks for your interest. As you can see, I last pinged 
ftpmaster@debian.org about this on 30th September and nothing has happened 
since then. I have been meaning to follow up again. I have even considered 
complaining elsewhere (possibly on debian-devel), but have not done so 
thus far.

Note that as far as I know the current packaging is essentially done, 
though maybe a careful review would show issues. However the version of 
CCL it was packaged against is now out of date, so that would need to be 
fixed, at least.

However, I have not been very motivated to upgrade this if nobody cares. 
However, it should not be difficult to do.

If you feel like complaining/following up with Debian, please do so, and 
CC me. It might only take a few people to get the ftpmasters to pay 
attention.

Thanks.
                                                   Regards, Faheem Mitha

> Greets.
> Rafael J. Alcántara Pérez.
> --

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#609047; Package wnpp. (Sat, 01 Mar 2014 12:09:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Sat, 01 Mar 2014 12:09:15 GMT) Full text and rfc822 format available.

Message #129 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: Luca Falavigna <ftpmaster@debian.org>
Cc: Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>, acid@debian.org, 609047@bugs.debian.org
Subject: Re: ccl-ffigen_1.2-1_amd64.changes REJECTED
Date: Sat, 1 Mar 2014 17:33:31 +0530 (IST)
Hi,

This is a second reminder. It is now 1st March 2014, i.e. approximately 5 
1/2 months since I followed up to the ftpmaster email on 11th September 
2013. I spent a great deal of time working on this packaging 
(approximately 1 month), and I would appreciate it if the ftpmasters would 
show me the minimal courtesy of replying to me. I thought Debian was 
supposed to appreciate its contributors. See 
https://www.debian.org/intro/diversity

Right now, I am not feeling particularly appreciated or encouraged.

                                           Thanking you,
                                           Sincerely, Faheem Mitha

On Mon, 30 Sep 2013, Faheem Mitha wrote:

>
> Hi,
>
> I don't mean to be impatient, but would it be possible for the FTP Master 
> team to make a call on this, please? It does not seem like *so* difficult a 
> technical issue.
>
>                                                           Thanks, Faheem
>
> On Wed, 11 Sep 2013, Faheem Mitha wrote:
>
>> 
>> On Tue, 9 Apr 2013, Luca Falavigna wrote:
>> 
>>> Hi,
>>> 
>>> sorry, but we do not think introducing a convenience copy of gcc
>>> is a good thing. Also, the 4.0 sources contain files licensed under
>>> GFDL with invariant sections, which are not suitable for main.
>>> 
>>> Please try to build your code using existing gcc versions in the archive
>>> implementing Built-Using field.
>>> 
>>> Cheers,
>>> Luca
>>> 
>>> ===
>>> 
>>> Please feel free to respond to this email if you don't understand why
>>> your files were rejected, or if you upload new files which address our
>>> concerns.
>> 
>> Extremely belated reply to this message, I've been busy. But if I waited 
>> for a good time, this might never be answered.
>> 
>> I think the package was rejected based on a misunderstanding.
>> 
>> As described at 
>> https://bitbucket.org/faheem/ccl-ffigen-debian/src/tip/README.Debian?at=default 
>> this package exists to build CCL's interface databases.
>> 
>> As described in http://trac.clozure.com/ccl/wiki/CustomFramework (FFI
>> is Foreign Function Interface)
>> 
>> """To support its FFI, CCL maintains a binary database of information
>> about classes, methods, functions, types, and variables available from
>> foreign libraries in several ".cdb" files. You will need to generate
>> this information for your particular library. In order to do this, you
>> will need to obtain and build ffigen4. """
>> 
>> This has little or nothing to do with GCC per se. It is *not* a fork.
>> Basically, it uses the GCC frontend for a purpose that is presumably
>> sufficiently similar to conventional compilation to enable a compiler
>> frontend to be used., namely building .cdb files which reflect the C
>> API of some .h files. I'm fuzzy about the details myself.
>> 
>> Anyway, getting it to build the code using existing versions of GCC in the 
>> archive would be impracticably difficult for a non-expert. (For the record, 
>> getting CCL to build correctly and in particular build the interface 
>> databases in question was quite hair-raisingly difficult enough.) If you 
>> doubt me, look at the 'source' subdirectory in the ffigen tarball, which 
>> has the patches against gcc 4.0, and tell me if you understand what they 
>> do.
>> 
>> I doubt even the main CCL developers would attempt it. They farmed out
>> the job to someone else years ago, who used the then-current GCC
>> compiler to get this to work. I could dig up more details, and talk to
>> the CCL developers themselves (who are usually grumpy and not
>> particularly sympathetic towards Debian, however) if you really need
>> further clarification. I'm including the ffigen README below, which
>> adds some details and history.
>> 
>> As for the documentation thing, I guess I could just strip out the
>> doc/FDL files from the tarball?
>>
>>                                                          Regards, Faheem.
>> 
>> ###########################################################################
>> 
>> # $Log$
>> # Revision 1.2  2005/08/10 05:05:46  gb
>> # Updated.
>> #
>> # Revision 1.1  2005/04/08 07:03:16  gb
>> # New file.
>> #
>> 
>> 'ffigen' is a modified version of the GCC backend, based on similar
>> modifications to the 'LCC' compiler described at:
>> 
>> <http://www.ccs.neu.edu/home/lth/ffigen/index.html>
>> 
>> It's a work derived from GCC, and therefore licensed under the GPL.
>> 
>> Versions of ffigen - based on GCC 2.95 sources - were distributed
>> as adjunct components of OpenMCL in 2001 and 2002.  It's become
>> increasingly difficult to use those versions, since they're sensitive
>> to the exact format of the 2.95 C preprocessor output (and since GCC
>> 2.95 is fading into obsolescence.)  The source distributions consisted
>> of a set of patches (relative to a canonical 2.95 source tree) and
>> a README file that explained the build process.
>> 
>> In the summer of 2004, Helmut Eller made available a set of patches
>> relative to GCC 3.4.1.  (Unlike previous versions, GCC 3.x's
>> preprocessor and frontend are a single program, so an ffigen program
>> derived from GCC 3 is likely to be a little more self-contained than
>> earlier versions.)
>> 
>> This version is based on GCC 4.0, builds on Helmut's work, and adds
>> some initial support for translating Objective-C class and method
>> information.  In addition, it provides a heavily conditionalized
>> Makefile which builds a binary package (.tar.gz file) on both LinuxPPC
>> and DarwinPPC.
>> 
>> In order to build the program, it's necessary to obtain canonical
>> versions of GCC (with ObjC support) for the target platform; the
>> Makefile tersely explains what's missing and suggests where to find
>> it.  You need to obtain the following files from gcc.gnu.org or a
>> mirror site and install them in this directory:
>> 
>> gcc-core-4.0.0.tar.bz2
>> gcc-objc-4.0.0.tar.bz2
>> 
>> Once those archives are installed, doing:
>> 
>> shell> make
>> 
>> will build the modified frontend, create an archive containing that
>> frontend and related support files, and create a text file explaining
>> how to install things.
>> 
>> These patches are maintained in CVS on clozure.com.  For anonymous
>> access:
>> 
>> shell> cvs -d :pserver:cvs@clozure.com:/usr/local/publiccvs login
>> 
>> [The anonymous CVS password is 'cvs']
>> 
>> shell> cvs -d :pserver:cvs@clozure.com:/usr/local/publiccvs get ffigen4



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Faheem Mitha <faheem@faheem.info>:
Bug#609047; Package wnpp. (Sun, 02 Mar 2014 16:12:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Rafael Jesús Alcántara Pérez <ralcantara@dedaloingenieros.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Faheem Mitha <faheem@faheem.info>. (Sun, 02 Mar 2014 16:12:08 GMT) Full text and rfc822 format available.

Message #134 received at 609047@bugs.debian.org (full text, mbox):

From: Rafael Jesús Alcántara Pérez <ralcantara@dedaloingenieros.com>
To: ftpmaster@debian.org
Cc: faheem@faheem.info, 609047@bugs.debian.org, pkg-common-lisp-devel@lists.alioth.debian.org
Subject: Re: Bug#609047: ITP: ccl - Clozure CL
Date: Sun, 02 Mar 2014 17:10:09 +0100
Hi:

We have been watching this ITP for some months but we have found that there is 
no advance. Is there any chance to this ITP could progress any time soon? We 
are trying to use CCL because of its multiplatform capabilities (now running 
even on Raspberry Pi [1]) so we are very insterested in this ITP.

Thanks in advance.

[1]http://www.raspihub.com/go/f5780dbf11dabc60771e67b357ae947bc6b3fd87f35d5f38e7d511ff88e08d0c
-- 
+----------
| Rafael Jesus Alcantara Perez.
| Email: mailto:ralcantara@dedaloingenieros.com 
mailto:rafael.alcantara@cpiia.org 
mailto:rafael.alcantara@ingenieroeninformatica.es
| Registered Linux User: #45989
| PGP: http://pgp.rediris.es:11371/pks/lookup?op=index&search=0x53F330AB
+---------------------
"For every complex problem there is a solution that is concise, clear, simple, 
and wrong."
(H. L. Mencken)




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#609047; Package wnpp. (Sun, 02 Mar 2014 17:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Sun, 02 Mar 2014 17:03:04 GMT) Full text and rfc822 format available.

Message #139 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: Rafael Jesús Alcántara Pérez <ralcantara@dedaloingenieros.com>
Cc: 609047@bugs.debian.org, pkg-common-lisp-devel@lists.alioth.debian.org
Subject: Re: Bug#609047: ITP: ccl - Clozure CL
Date: Sun, 2 Mar 2014 22:28:47 +0530 (IST)
[Message part 1 (text/plain, inline)]
On Sun, 2 Mar 2014, Rafael Jesús Alcántara Pérez wrote:

> Hi:
>
> We have been watching this ITP for some months but we have found that there is
> no advance. Is there any chance to this ITP could progress any time soon? We
> are trying to use CCL because of its multiplatform capabilities (now running
> even on Raspberry Pi [1]) so we are very insterested in this ITP.
>
> Thanks in advance.
>
> [1]http://www.raspihub.com/go/f5780dbf11dabc60771e67b357ae947bc6b3fd87f35d5f38e7d511ff88e08d0c

Hi Rafael,

I'm willing to work with you (time permitting) if you want to use the CCL 
Debian packaging. You don't have to wait till it gets into Debian 
(assuming that ever happens). As far as I know it should work, though it 
has only been lightly tested.

                                                   Regards, Faheem Mitha

> -- 
> +----------
> | Rafael Jesus Alcantara Perez.
> | Email: mailto:ralcantara@dedaloingenieros.com
> mailto:rafael.alcantara@cpiia.org
> mailto:rafael.alcantara@ingenieroeninformatica.es
> | Registered Linux User: #45989
> | PGP: http://pgp.rediris.es:11371/pks/lookup?op=index&search=0x53F330AB
> +---------------------
> "For every complex problem there is a solution that is concise, clear, simple,
> and wrong."
> (H. L. Mencken)

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Faheem Mitha <faheem@faheem.info>:
Bug#609047; Package wnpp. (Wed, 05 Mar 2014 20:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Rafael Jesús Alcántara Pérez <ralcantara@dedaloingenieros.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Faheem Mitha <faheem@faheem.info>. (Wed, 05 Mar 2014 20:51:05 GMT) Full text and rfc822 format available.

Message #144 received at 609047@bugs.debian.org (full text, mbox):

From: Rafael Jesús Alcántara Pérez <ralcantara@dedaloingenieros.com>
To: Faheem Mitha <faheem@faheem.info>
Cc: 609047@bugs.debian.org, pkg-common-lisp-devel@lists.alioth.debian.org
Subject: Re: Bug#609047: ITP: ccl - Clozure CL
Date: Wed, 05 Mar 2014 21:48:20 +0100
El Domingo, 2 de marzo de 2014 22:28:47 Faheem Mitha escribió:
> On Sun, 2 Mar 2014, Rafael Jesús Alcántara Pérez wrote:
> > Hi:
> > 
> > We have been watching this ITP for some months but we have found that
> > there is no advance. Is there any chance to this ITP could progress any
> > time soon? We are trying to use CCL because of its multiplatform
> > capabilities (now running even on Raspberry Pi [1]) so we are very
> > insterested in this ITP.
> > 
> > Thanks in advance.
> > 
> > [1]http://www.raspihub.com/go/f5780dbf11dabc60771e67b357ae947bc6b3fd87f35d
> > 5f38e7d511ff88e08d0c
> Hi Rafael,
> 
> I'm willing to work with you (time permitting) if you want to use the CCL
> Debian packaging. You don't have to wait till it gets into Debian
> (assuming that ever happens). As far as I know it should work, though it
> has only been lightly tested.
> 
Perfect, where should I begin?

Greets and thanks again. Rafael.
-- 
+----------
| Rafael Jesus Alcantara Perez.
| Email: mailto:ralcantara@dedaloingenieros.com 
mailto:rafael.alcantara@cpiia.org 
mailto:rafael.alcantara@ingenieroeninformatica.es
| Registered Linux User: #45989
| PGP: http://pgp.rediris.es:11371/pks/lookup?op=index&search=0x53F330AB
+---------------------
"For every complex problem there is a solution that is concise, clear, simple, 
and wrong."
(H. L. Mencken)




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#609047; Package wnpp. (Wed, 05 Mar 2014 22:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@faheem.info>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Wed, 05 Mar 2014 22:03:04 GMT) Full text and rfc822 format available.

Message #149 received at 609047@bugs.debian.org (full text, mbox):

From: Faheem Mitha <faheem@faheem.info>
To: Rafael Jesús Alcántara Pérez <ralcantara@dedaloingenieros.com>
Cc: 609047@bugs.debian.org, pkg-common-lisp-devel@lists.alioth.debian.org
Subject: Re: Bug#609047: ITP: ccl - Clozure CL
Date: Thu, 6 Mar 2014 03:28:53 +0530 (IST)
[Message part 1 (text/plain, inline)]
On Wed, 5 Mar 2014, Rafael Jesús Alcántara Pérez wrote:

> El Domingo, 2 de marzo de 2014 22:28:47 Faheem Mitha escribió:
>> On Sun, 2 Mar 2014, Rafael Jesús Alcántara Pérez wrote:
>>> Hi:
>>>
>>> We have been watching this ITP for some months but we have found that
>>> there is no advance. Is there any chance to this ITP could progress any
>>> time soon? We are trying to use CCL because of its multiplatform
>>> capabilities (now running even on Raspberry Pi [1]) so we are very
>>> insterested in this ITP.
>>>
>>> Thanks in advance.
>>>
>>> [1]http://www.raspihub.com/go/f5780dbf11dabc60771e67b357ae947bc6b3fd87f35d
>>> 5f38e7d511ff88e08d0c
>> Hi Rafael,
>>
>> I'm willing to work with you (time permitting) if you want to use the CCL
>> Debian packaging. You don't have to wait till it gets into Debian
>> (assuming that ever happens). As far as I know it should work, though it
>> has only been lightly tested.
>>
> Perfect, where should I begin?
>
> Greets and thanks again. Rafael.

Well, first do you just want binaries that work on your platform, or so 
you want to know how to build it yourself? Obviously, I would prefer the 
latter, because that way someone would have to look at my documentation 
and procedures, which could probably do with improvement. I think this is 
also preferable from your perspective for a package that isn't officially 
part of Debian.

If you did want the former, I could just dump some binary debs somewhere, 
but that won't help you if I disappear off the net tomorrow.

Do you have a group of people who are interested in using this? If so, can 
you give me a little more detail about them?

As a first step, clone the following Mercurial repositories.

https://bitbucket.org/faheem/ccl-debian
https://bitbucket.org/faheem/ccl-bootstrap-debian
https://bitbucket.org/faheem/ccl-ffigen-debian

Start by seeing if you can build and install the ccl-ffigen package. That 
is the easiest. If you have problems with it, let me know. And what 
platform/arch will you be building on?

                                                          Regards, Faheem

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Faheem Mitha <faheem@faheem.info>:
Bug#609047; Package wnpp. (Thu, 13 Mar 2014 08:06:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Rafael Jesús Alcántara Pérez <ralcantara@dedaloingenieros.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Faheem Mitha <faheem@faheem.info>. (Thu, 13 Mar 2014 08:06:05 GMT) Full text and rfc822 format available.

Message #154 received at 609047@bugs.debian.org (full text, mbox):

From: Rafael Jesús Alcántara Pérez <ralcantara@dedaloingenieros.com>
To: Faheem Mitha <faheem@faheem.info>
Cc: 609047@bugs.debian.org, pkg-common-lisp-devel@lists.alioth.debian.org
Subject: Re: Bug#609047: ITP: ccl - Clozure CL
Date: Thu, 13 Mar 2014 09:03:05 +0100
El Jueves, 6 de marzo de 2014 03:28:53 Faheem Mitha escribió:
> On Wed, 5 Mar 2014, Rafael Jesús Alcántara Pérez wrote:
> > El Domingo, 2 de marzo de 2014 22:28:47 Faheem Mitha escribió:
> >> On Sun, 2 Mar 2014, Rafael Jesús Alcántara Pérez wrote:
> >>> Hi:
> >>> 
> >>> We have been watching this ITP for some months but we have found that
> >>> there is no advance. Is there any chance to this ITP could progress any
> >>> time soon? We are trying to use CCL because of its multiplatform
> >>> capabilities (now running even on Raspberry Pi [1]) so we are very
> >>> insterested in this ITP.
> >>> 
> >>> Thanks in advance.
> >>> 
> >>> [1]http://www.raspihub.com/go/f5780dbf11dabc60771e67b357ae947bc6b3fd87f3
> >>> 5d
> >>> 5f38e7d511ff88e08d0c
> >> 
> >> Hi Rafael,
> >> 
> >> I'm willing to work with you (time permitting) if you want to use the CCL
> >> Debian packaging. You don't have to wait till it gets into Debian
> >> (assuming that ever happens). As far as I know it should work, though it
> >> has only been lightly tested.
> > 
> > Perfect, where should I begin?
> > 
> > Greets and thanks again. Rafael.
> 
> Well, first do you just want binaries that work on your platform, or so
> you want to know how to build it yourself? Obviously, I would prefer the
> latter, because that way someone would have to look at my documentation
> and procedures, which could probably do with improvement. I think this is
> also preferable from your perspective for a package that isn't officially
> part of Debian.
> 
Ok, I'll try to build it myself.

> If you did want the former, I could just dump some binary debs somewhere,
> but that won't help you if I disappear off the net tomorrow.
> 
> Do you have a group of people who are interested in using this? If so, can
> you give me a little more detail about them?
> 
I work for a small software development company and we are interested in 
developing using Common Lisp in small devices. To do so, we are exploring 
alternatives for SBCL and ECL.

> As a first step, clone the following Mercurial repositories.
> 
> https://bitbucket.org/faheem/ccl-debian
> https://bitbucket.org/faheem/ccl-bootstrap-debian
> https://bitbucket.org/faheem/ccl-ffigen-debian
> 
> Start by seeing if you can build and install the ccl-ffigen package. That
> is the easiest. If you have problems with it, let me know. And what
> platform/arch will you be building on?
> 
Ok thank you :) I'll try when I have some free time. We use a Debian/GNU 
Squeeze on amd64 for building the Debian packages.

Greets.
-- 
+----------
| Rafael Jesús Alcántara Pérez <ralcantara@dedaloingenieros.com>
| Director Técnico.
| Teléfono fijo: 952 602 959
| Fax: 952 602 959
| Dirección: C/ Afligidos 2, 3º Derecha, 29015 Málaga
| Dédalo Ingenieros, S.L.: http://www.dedaloingenieros.com/
| PGP: http://pgp.rediris.es:11371/pks/lookup?op=index&search=0x53F330AB
+---------------------
"For every complex problem there is a solution that is concise, clear,
simple, and wrong." (H. L. Mencken)



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 07:03:58 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.