* 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.
Hi Darren, I think http://ccl.clozure.com/ provides more information. Drop c-l-c integration. http://article.gmane.org/gmane.linux.debian.alioth.common-lisp/2493 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
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
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
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:
Send a mail to the bug report explaining that you'll take over and set
yourself as the owner of the bug.
It needs to be done once you have a package ready on mentors.debian.net
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?
CCL?
Regards
Christoph
Hi Christoph, Thank you for your response. Feedback from members of Debian's Common Lisp team is always helpful. Ok, I'll do that. Done. Ok. I should be able to upload to mentors soon. 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. 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. 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
Hi again
Faheem Mitha <faheem@faheem.info> writes:
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.
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
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
Yes, I've done that. The README.source is now quite extensive. See https://bitbucket.org/faheem/ccl-debian/src/tip/README.source 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
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,
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
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
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.
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
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. 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. 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
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.
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?
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?
Any version of CCL that I package for Debian will be the release. So I
guess this is not an issue.
Regards, Faheem
No problem. 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. 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. Of course. 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? 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. 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
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.
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.
Great, thanks.
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.
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.
Ok, but I'll need instructions on how to do this.
Regards, Faheem
Dear Faheem,
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.
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.
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.
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).
I don't have a strong opinion.
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é
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
Hi: Is there any advance on this ITP? Greets. Rafael J. Alcántara Pérez.
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
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
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
El Domingo, 2 de marzo de 2014 22:28:47 Faheem Mitha escribió: 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
El Jueves, 6 de marzo de 2014 03:28:53 Faheem Mitha escribió: Ok, I'll try to build it myself. 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. 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.
Hi, just as a general note, I would be interested in seeing CCL being available through Debian directly as well. My intent is to set up servers for remote development and testing of common lisp libraries and applications, for which having a direct package would make things a lot more comfortable. Sincerely, Nicolas Hafner
Dear Customer, This is to confirm that one or more of your parcels has been shipped. You can review complete details of your order in the find attached. Thanks and best regards, Barry Hogan, Support Agent.
Dear Customer, We could not deliver your item. You can review complete details of your order in the find attached. Regards, Don Snyder, Sr. Support Manager.
Dear Customer, We could not deliver your item. Please, open email attachment to print shipment label. Sincerely, Harvey Odonnell, Sr. Station Agent.
Dear Customer, This is to confirm that one or more of your parcels has been shipped. Shipment Label is attached to email. Thanks and best regards, Albert Silva, Sr. Operation Manager.
Dear Customer, This is to confirm that one or more of your parcels has been shipped. Please, open email attachment to print shipment label. Yours faithfully, Martin Reilly, Support Manager.
Dear Customer, Courier was unable to deliver the parcel to you. Shipment Label is attached to email. Thanks and best regards, Tim Key, Sr. Delivery Agent.
Hi all, FYI there's a working Debian package for Clozure CL here: http://mr.gy/blog/clozure-cl-deb.html Regards Vincent
Dear Customer, We have received documents / clarifications required for shipment processing and Bill of Entry is being filed for shipment. Shipment is expected to be cleared from Customs within 2 working days subject to no further queries from Customs. Kindly find attached to details to Track your shipment: Best Regards, DHL EXPRESS PVT. LTD.
Attached is the signed Agreement Form for your review Please acknowledge rcvd from your end. Regards. Accounting ManagerJafftech. Org 22nd Floor, China Merchants Tower, Shun Tak Centre, 168-200 Connaught Road, Central, Hong Kong Tel: 852-2837333452 Fax: 852-28288768
Please find attached Invoice Instruction going forward when submitting your invoice for payment. Please acknowledge from your end. Kind regards Kishore Samaroo Purchasing Eagle Ship Management LLC 300 First Stamford Place 5th Floor Stamford, CT 06902 D: +1 203 276 8172 T: +1 203 276 8100 M: +1 203 705 9177 F: + 1 203 276 8199
Please find attached Invoice Instruction going forward when sending your invoice for payment Please acknowledge from your end. Kind regards Kishore Samaroo Purchasing Eagle Ship Management LLC 300 First Stamford Place 5th Floor Stamford, CT 06902 T: +1 203 276 8100 D: +1 203 276 8172
I’ve recently tried to reevaluate the situation regarding CCL in Debian. In short, the answer is unfortunately that it’s not yet possible to package CCL, but there is however the hope that the situation will improve at some point. What prevents CCL from being packaged Debian is the ffigen tool, which is required at build time to generate various FFI bindings. The latest functional version of this tool (ffigen4) is essentially a patch over GCC 4. The ftpmasters refused to have this in the archive (see above). There is however an ongoing effort to rewrite ffigen, see: https://github.com/Clozure/ccl/issues/13 The rewrite is essentially a small executable depending on libclang, and is now dubbed ffigen5. I’ve tried it, and even though it is able to parse many C headers, it still fails at some. So it’s not yet ready for use. But hopefully it will be at some point, which should clear the way for CCL in Debian.
Hi, Please quote the best air freight charges (door to door) to UK . Attached tentative packing list for your reference . NOTE: Please do not arrange until the job is given to you . Thank you . Best Regards, Katherine Sim Associated Enterprises (S) Pte Ltd Tel : +65-6455 0555
Please find attached New Import Job Order and Surrendered BL. Kindly assist to monitor port net for vessel ETA. Pending: NOA, Import Permit & Container Release _ _ _**Important Notes**: For all TT remittances and bank transfers, the full invoice amount must be received by GKE Metal Logistics Pte Ltd (payee) and all bank charges are for the account of the remitter (payer). Payer's must instruct their bank to pay the full invoice amount, net of all bank charges._ Thank you & Best Regards, ** Kindly send/copy to: metalops@gkeml.com for all email correspondences ** Lydia Hor GKE Metal Logistics Pte Ltd (UEN : 198401245D) Tel: +65 6266 0921 (Ext: 206) Fax: +65 6266 0922 Hp :9616 2367 1 North Bridge Road, High Street Centre #20-10, Singapore 179094 Website: www.gkeml.com [1] Links: ------ [1] http://www.gkeml.com/
Upstream here. I’ve recently released CCL 1.13 (https://github.com/Clozure/ccl/releases/tag/v1.13). In this release, Linux headers are processed with the new ffigen5 tool (https://github.com/Clozure/ccl-ffigen). I’d be happy to show anyone interested how to use the tool and generate the interface databases. In short, look at ccl:x86-headers64;libc;C;translate.sh for how to invoke the ffigen5 tool. That will produce a bunch of .ffi files. To generate the .cdb files used by CCL’s ffi, start CCL, and then do: (require 'parse-ffi) (ccl::parse-standard-ffi-files :libc) Here, :libc indicates that the .ffi files to process are in x86-headers64/libc/C. If you said :elf, that would mean to look for .ffi files in x86-headers64/elf/C. As I say, if there’s anything I can do to help get CCL packaged, please get in touch.