September 2008 - cl-debian@common-lisp.net

[cl-debian] Accepted cl-geodesics 20010214-9 (source all)
by Luca Capello 17 Sep '08

17 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.8 Date: Wed, 17 Sep 2008 23:32:50 +0200 Source: cl-geodesics Binary: cl-geodesics Architecture: source all Version: 20010214-9 Distribution: unstable Urgency: low Maintainer: Debian Common Lisp Team <pkg-common-lisp-devel(a)lists.alioth.debian.org> Changed-By: Luca Capello <luca(a)pca.it> Description: cl-geodesics - Geodesic equations in Common Lisp Closes: 469896 494404 Changes: cl-geodesics (20010214-9) unstable; urgency=low . * debian/control: + fix FTBFS, change Architecture: from 'any' to 'all', thanks to Sebastian Bober <sbober(a)servercare.de> (Closes: #469896). + add myself to Uploaders:. + add Vcs-Browser field. + Build-Depends: on quilt. + Build-Depends-Indep: on dh-lisp. . * debian/gd-static-equal.asd: new file. * debian/gd-static-unequal.asd: new file. * debian/gd-cosmological.asd: new file. . * debian/geodesics.asd: + remove extra parenthesis for the :gd-static-unequal ASDF system. + move :infix dependency to each ASDF subsystem, thanks to Peter De Wachter <pdewacht(a)gmail.com> (Closes: #494404). + split subsystems into single ASDF systems, but keep this one for backward compatibility, thanks to Peter De Watcher <pdewacht(a)gmail.com>. . * debian/patches/series: new file. * debian/patches/01_prepend-integrate-system-in-utilities.lisp.diff: + properly call integrate: functions, thanks to Peter De Wachter <pdewacht(a)gmail.com>. * debian/patches/02_define-package-in-utilities.lisp.diff: + add in-package definition, thanks to Peter De Wachter <pdewacht(a)gmail.com>. . * debian/postinst: - remove, dh-lisp will generate it. . * debian/prerm: - remove, dh-lisp will generate it. . * debian/rules: + adapt to quilt. + add dh_lisp call to binary-indep target. - remove unnecessary dh_link call in install target. Checksums-Sha1: 072cb3b2a303e984f7a24dfddb8ed401ca11a5b2 1428 cl-geodesics_20010214-9.dsc 283803ed5ed193af6817b431634e049c084bce53 2897 cl-geodesics_20010214-9.diff.gz 7a731679eedd87f0d453079688b8e69db8edc5ba 8690 cl-geodesics_20010214-9_all.deb Checksums-Sha256: 1e72c68b8c2431d6b235e3758e39477ccc15612ead7a3f95c9f1f406d64c2bd2 1428 cl-geodesics_20010214-9.dsc bb119a4efcd7ef6eb0382846a2ddc376e10545c673e584e06b0f880d53451c54 2897 cl-geodesics_20010214-9.diff.gz 9a54f612d2206f66ab3d59ddc644ed4909519f558a50fc14d06b2be40d706f64 8690 cl-geodesics_20010214-9_all.deb Files: 34e4210836c24a1d8b36431f142f6abe 1428 contrib/devel optional cl-geodesics_20010214-9.dsc c4982cbadc3d5e3f97d4c6556ac0ad53 2897 contrib/devel optional cl-geodesics_20010214-9.diff.gz 2b71a7e9510ca4d633c7c3e823008dff 8690 contrib/devel optional cl-geodesics_20010214-9_all.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iJwEAQECAAYFAkjReKkACgkQZwOMsWhEDTOvOgP/S9gwKxPdGg5jmvjsO+5D71p7 izkYuTM6BLI3mzkKm1+UPl2FmNV88LBQjaHv/7vDMga3Aj96toj3Fa6f0ZELCllI PLQfwicaKdLStJzDF8Mm5WtIA1AzfoYpAUqLH1JS2kmaPa2Wh5XnZBaa8QIWx77G UELNbamV/n91j+tjcBI= =ksjE -----END PGP SIGNATURE----- Accepted: cl-geodesics_20010214-9.diff.gz to pool/contrib/c/cl-geodesics/cl-geodesics_20010214-9.diff.gz cl-geodesics_20010214-9.dsc to pool/contrib/c/cl-geodesics/cl-geodesics_20010214-9.dsc cl-geodesics_20010214-9_all.deb to pool/contrib/c/cl-geodesics/cl-geodesics_20010214-9_all.deb

1 0

[cl-debian] Bug#494404: tagging 494404
by kurt＠roeckx.be 16 Sep '08

16 Sep '08

# Automatically generated email from bts, devscripts version 2.10.35 # 20010214-9 seems to fix it, but that doesn't seem to be uploaded. Maybe you wanted to tag it pending instead? tags 494404 - fixed

1 0

[cl-debian] gcl 2.6.7-45 MIGRATED to testing
by Debian testing watch 13 Sep '08

13 Sep '08

FYI: The status of the gcl source package in Debian's testing distribution has changed. Previous version: 2.6.7-44 Current version: 2.6.7-45 -- This email is automatically generated; the Debian Release Team <debian-release(a)lists.debian.org> is responsible. See http://release.debian.org/testing-watch/ for more information.

1 0

[cl-debian] Bug#495756: marked as done (ecl has rpath to insecure location (/tmp/buildd/ecl-0.9j-20080306/build/))
by owner＠bugs.debian.org 10 Sep '08

10 Sep '08

Your message dated Wed, 10 Sep 2008 01:17:05 +0000 with message-id <E1KdEKP-0000yi-8d(a)ries.debian.org> and subject line Bug#495756: fixed in ecl 0.9j-20080306-5 has caused the Debian Bug report #495756, regarding ecl has rpath to insecure location (/tmp/buildd/ecl-0.9j-20080306/build/) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner(a)bugs.debian.org immediately.) -- 495756: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495756 Debian Bug Tracking System Contact owner(a)bugs.debian.org with problems

1 0

[cl-debian] Accepted ecl 0.9j-20080306-5 (source all amd64)
by Luca Capello 10 Sep '08

10 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.8 Date: Tue, 09 Sep 2008 21:54:43 +0200 Source: ecl Binary: ecl ecl-doc Architecture: source all amd64 Version: 0.9j-20080306-5 Distribution: unstable Urgency: low Maintainer: Debian Common Lisp Team <pkg-common-lisp-devel(a)lists.alioth.debian.org> Changed-By: Luca Capello <luca(a)pca.it> Description: ecl - Embeddable Common-Lisp: has an interpreter and can compile to C ecl-doc - documentation for Embeddable Common-Lisp Closes: 495756 Changes: ecl (0.9j-20080306-5) unstable; urgency=low . * debian/control: + Build-Depends: on chrpath to remove unnecessary rpath headers from binaries in /usr/lib/ecl/, thanks to Bill Allombert <bill.allombert(a)math.u-bordeaux1.fr> (Closes: #495756). + Depends: on gcc, it's required at installation and everytime you want to produce a loadable object file. . * debian/rules: + add chrpath call to 'install' target. Checksums-Sha1: d592bea4c6c43cc5a70205514e14da0ea8c69e3f 1573 ecl_0.9j-20080306-5.dsc b8e07c40d5d68549c38ca8c5fa07bbf276f4e8df 154308 ecl_0.9j-20080306-5.diff.gz 6cbeb068f1f3030e10e4d25aba35af4c0304ca6a 65118 ecl-doc_0.9j-20080306-5_all.deb a3f0013787a3444a7ae145e92a1dcd1bfe526f5f 1586750 ecl_0.9j-20080306-5_amd64.deb Checksums-Sha256: 71997860b4d69db18b669151423bf589896fee2572e45a946850bddf292950be 1573 ecl_0.9j-20080306-5.dsc 2124f8fbba3e4604d06d7c2b28dc8ea7109441fde48cb55368b4f13bb6a86e57 154308 ecl_0.9j-20080306-5.diff.gz 38c57bf8625019d6d6cfaddb3ff08f29e995ea380a82549cac2347f3592f1ffc 65118 ecl-doc_0.9j-20080306-5_all.deb bdb37b2b93a109db37b3ec44a1fe62b3c6d9e0986acca6b2494dcc86b9156a74 1586750 ecl_0.9j-20080306-5_amd64.deb Files: ebcee6b3afbf68aded6bd8a0966018e3 1573 devel optional ecl_0.9j-20080306-5.dsc 0e6066196d95a74605611ad5c2dfcbe2 154308 devel optional ecl_0.9j-20080306-5.diff.gz fd17aeaf7aff07e2539d8c4671accd76 65118 doc optional ecl-doc_0.9j-20080306-5_all.deb 78f1af52e573fcb5b9901c6804b99c66 1586750 devel optional ecl_0.9j-20080306-5_amd64.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iJwEAQECAAYFAkjG9HoACgkQZwOMsWhEDTOpNQP/ZBCtCEOCwD0/W3uPXZtBDcdl DAJHiG/6XJhjFTWst50nCSPTcDdBk/WG+aY8C0tl3kSFerN6Bl2PclHmLHafQwpf mvBj1pl73UQu7GEiwmqOONHEQ9qgbgifyxQOP0hRjuSh4yxKUb8BXUY6pGhhX5qy c1NTbFI/Z6xbr8s6Cfc= =mrs8 -----END PGP SIGNATURE----- Accepted: ecl-doc_0.9j-20080306-5_all.deb to pool/main/e/ecl/ecl-doc_0.9j-20080306-5_all.deb ecl_0.9j-20080306-5.diff.gz to pool/main/e/ecl/ecl_0.9j-20080306-5.diff.gz ecl_0.9j-20080306-5.dsc to pool/main/e/ecl/ecl_0.9j-20080306-5.dsc ecl_0.9j-20080306-5_amd64.deb to pool/main/e/ecl/ecl_0.9j-20080306-5_amd64.deb

1 0

[cl-debian] Bug#486376: [Ecls-list] Bug#486376: Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME
by Luca Capello 09 Sep '08

09 Sep '08

Hi Juanjo! On Wed, 10 Sep 2008 00:10:10 +0200, Juan Jose Garcia-Ripoll wrote: > On Tue, Sep 9, 2008 at 11:15 PM, Luca Capello <luca(a)pca.it> wrote: > I'll play the Devil's advocate here, sorry: does this mean that 0.1.0 > will be SONAME-compatible with 0.1.1? > > The SONAME only uses the first two numbers. [...] > Also, what is definitely true is that two libraries with different > major (i.e. first) or minor (i.e. second) release numbers are not > guaranteed to be binary compatible. Noted, thanks. > Is a new release planned soon or should I package today's CVS snapshot > to close this bug? > > One or two weeks. Depends on another bug being closed and also how > life develops. OK, I'll ask the Debian Release Team about uploading a new upstream version at this time frame and then react accordingly. > CLISP provides a similar situation, but we (i.e. Debian) decided to ship > only one version. What's your advice here? > > I do not think it is politically correct to ask the maintainer of one > implementation how the packaging of a different one should go, so > please excuse if I do not answer that question. I understand your point, but I think I wasn't enough clear: my question was/is not about how Debian should package CLISP, but what you prefer for ECL. Let's try again with different (and maybe clearer) words. I prefer to keep the ECL situation as it is now: Debian ships only one version, which is the latest release [1]. This means less work for the Debian maintainers (ATM mostly me) and also a more closer tracking of upstream development. The disadvantage is for anyone depending on ECL, who needs to "port" her/his applications to the new upstream release. Is it OK for you or have you other suggestions? I still think that splitting the main binary package into ecl and libecl can improve the situation WRT dependencies, but this is another matter. Thx, bye, Gismo / Luca Footnotes: [1] considering the Debian policies, i.e. if Debian's freezing for a new stable release, no new upstream versions are allowed in testing

1 0

[cl-debian] Processed: Re: [Ecls-list] Bug#486376: Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME
by owner＠bugs.debian.org 09 Sep '08

09 Sep '08

Processing commands for control(a)bugs.debian.org: > tags 486376 + fixed-upstream Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME Tags were: upstream help Tags added: fixed-upstream > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)

1 0

[cl-debian] Bug#486376: [Ecls-list] Bug#486376: Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME
by Luca Capello 09 Sep '08

09 Sep '08

Hi Juanjo! Why didn't I wait for ten more minutes before sending my previous mail? I'd have seen you already fixed it, thank you! On Tue, 09 Sep 2008 21:55:30 +0200, Juan Jose Garcia-Ripoll wrote: > On Tue, Sep 9, 2008 at 9:40 PM, Luca Capello <luca(a)pca.it> wrote: > > Thank you. If I could say more, I really prefer full dates (YYYYMMDD), > but this is not the scope of this bug report. > > That is too large and the shorter version can be directly used in > sonames Good point. > However, if my words above are correct, I can split ecl_1-1 into two > packages, libecl [2] and ecl [3], the latter depending on the former. This > means that if the standalone program I wrote works just with the shared > library, I don't need to install the other internal libraries and the > compiler. > > This is true. > > Could this improve the situation? > > As I said, the problems are not on our side, so I presume this > question goes to the bug originator :-) Thus me, also one of the Debian maintainers, read below ;-) > As mentioned in the previous email / bug answer, this change has been > committed to ECL already. On Tue, 09 Sep 2008 21:38:13 +0200, Juan Jose Garcia-Ripoll wrote: > Last change in CVS ( 2008/09/09 ) > > - We switch to an Ubuntu-like versioning system, based on $(year).$(month).x > where "x" is 0 for a release or any higher number for a patched version. I'll play the Devil's advocate here, sorry: does this mean that 0.1.0 will be SONAME-compatible with 0.1.1? > - In Unix-type systems, ECL now installs with a "soname" and using versioned > directory names, such as /usr/lib/ecl-8.9.0, /usr/lib/libecl.so.8.9, etc Is a new release planned soon or should I package today's CVS snapshot to close this bug? This change not only fixes this problem, but it also lets different ECL versions be installed simultaneously. CLISP provides a similar situation, but we (i.e. Debian) decided to ship only one version. What's your advice here? I'd prefer keeping the situation as it is and consistent with CLISP: Debian ships one version, whenever it's possible the latest release. > This should be more than enough. Again, thank you not only for the fix, but mainly for the time you spent discussing it, I really appreciate. Thx, bye, Gismo / Luca

1 0

[cl-debian] Bug#486376: [Ecls-list] Bug#486376: Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME
by Luca Capello 09 Sep '08

09 Sep '08

Hi Juanjo! On Sun, 07 Sep 2008 18:51:30 +0200, Juan Jose Garcia-Ripoll wrote: > Well, for one I do not believe in LSB. At least I do not believe > people are going to include ECL in the list of required software by > the LSB committee, and that implies no program can expect it is going > to have the right version of the ECL runtime waiting for them in the > host machine. It does not matter whether the SONAMEs are right or not. I used LSB as an example, here: I don't think that ECL will be part of LSB, but this is an effort to uniform GNU/Linux distributions. That's why I don't like Debian packages deviating from upstream without a consensus. > Now, given that everybody asks me to maintain SONAMEs and not only > that, but to add the proper flags for the linker, and since you must > have guessed I am a lazy guy and I do not believe I will be able to > maintain by myself binary compatibility among releases, I just > announce that the SONAMEs will end up being dates: (format nil "~D.~D" > (- year 2000) month) of the code I produce (*). Thank you. If I could say more, I really prefer full dates (YYYYMMDD), but this is not the scope of this bug report. > But let me remark that in this "bug" report we have not yet talked > about the compiled files that ECL ships with. [...] > That means not only the library file will have to be versioned, but > the library directory in which ECL is installed as well. Have you > thought about this? I didn't think about it before your mail because I don't see the problem, really, please read below. > So, again, ECL is closer to SBCL or python (**) that what you may > think in that it is a runtime. It is true that programs may embed its > library, and it is true that the software installs libecl.so in the > /usr/lib directory, but this was not always the case and I only > changed it because I was asked to remove all uses of --rpath from my > code. Iif I understand correctly, we can have standalone programs [1] that need just /usr/lib/libecl.so and others that need more than that, i.e. all the other compiled files ECL ships in /usr/lib/ecl/ (these are internal libraries, not shared ones). With the actual situation, one cannot discriminate the dependencies between the two cases (since the library is shipped together with the compiler) and thus people should always depend on the full ecl_1-1 package. However, if my words above are correct, I can split ecl_1-1 into two packages, libecl [2] and ecl [3], the latter depending on the former. This means that if the standalone program I wrote works just with the shared library, I don't need to install the other internal libraries and the compiler. Could this improve the situation? I'd really like to have this bug fixed in lenny [4], but I don't guarantee anything :-D > (*) Actually, given that people have also complained about my > versioning scheme, I may just as well do that for real version > numbers. Fully ACK, please do it! Thx, bye, Gismo / Luca Footnotes: [1] New manual: "1.6.3. Example of standalone program" [2] actually, I still need to document myself about binary package names for shared libraries, thus the name could finally be libecl$SONAME [3] FWIW, the next ECL Debian package will depends on GCC: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=yes&bug=495351#25 [4] http://lists.debian.org/debian-devel-announce/2008/09/msg00000.html

1 0

[cl-debian] Bug#486376: [Ecls-list] Bug#486376: Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME
by Luca Capello 06 Sep '08

06 Sep '08

Hi Juanjo! On Wed, 03 Sep 2008 17:41:25 +0200, Juan Jose Garcia-Ripoll wrote: > On Wed, Sep 3, 2008 at 4:12 PM, Luca Capello <luca(a)pca.it> wrote: >>> That is not something ECL has to provide. It is more a configuration >>> option that operating systems may provide. >> >> Sorry, I'm not a skilled programmed, but I don't understand why this is >> not ECL task: ECL provides the libecl.so library, so who else should >> provide its SONAME? > > The SONAME is a basically a linker option and can be passed to ECL as > a configuration flag during the build process. It is not our task as > developers of ECL to impose a certain numbering scheme or link flags > on the main source distribution, but rather the package maintainer to > set it based on their own criteria or distribution standards. Well, I really think SONAME's decision belongs to developers, not to package maintainers. Let's say that Debian uses a SONAME of 0.1 while Ubuntu 0.2 [1]: then every effort done with the LSB [2] is lost. I consider this as the last solution and if I'm really forced to implement it, the ECL SONAME in Debian will reflect the upstream version. > At least this is how I have seen that done for other packages, > including Debian's ones (http://packages.debian.org/etch/libgc1c2) and > that is what I meant by the text above. The libgc1c2 package in etch already uses upstream SONAME [3]: --8<---------------cut here---------------start------------->8--- libgc (1:6.2+6.3alpha1-1) unstable; urgency=low * New upstream release (closes: #197031) * Switch to using upstream's autoconf (and therefore upstream's sonames, so rename packages to match the sonames) (closes: #178869) * Relibtoolize. -- Ryan Murray <rmurray(a)debian.org> Mon, 11 Aug 2003 15:57:57 -0700 --8<---------------cut here---------------end--------------->8--- Thx, bye, Gismo / Luca Footnotes: [1] and yes, I compared Debian and Ubuntu *in purpose*, since while the latter syncs with Debian before every freeze, in some areas they diverge quite a lot [2] http://www.linuxfoundation.org/en/LSB [3] http://packages.debian.org/changelogs/pool/main/libg/libgc/libgc_6.8-1/chan…

1 0