Your message dated Mon, 30 Jan 2017 22:21:40 +0000 with message-id <[email protected]> and subject line Bug#852259: fixed in newlisp 10.7.0-4 has caused the Debian Bug report #852259, regarding newlisp: Dynamic library loading is broken 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 [email protected] immediately.) -- 852259: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852259 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: newlisp Version: 10.7.0-3 Severity: serious I was originally interested in how to get the dependency on libmysqlclient18 (which will not be part of stretch) updated, but it turned out dynamic library loading in newlisp is broken. (set 'files '( "/usr/local/lib/libmysqlclient.so.20.0" ; OpenBSD 4.9 "/usr/lib/libmysqlclient.so" ; Linux, UNIX "/usr/lib/mysql/libmysqlclient.so" ; Linux Fedora "/usr/lib64/mysql/libmysqlclient.so" ; Linux Fedora CentOS 6.x "/usr/lib/x86_64-linux-gnu/libmysqlclient.so" ; Ubuntu 12.04 LTS "/usr/local/mysql/lib/libmysqlclient.so" ; Linux, UNIX "/usr/local/mysql/lib/libmysqlclient.dylib" ; MacOS X "/usr/lib/libmysqlclient.dylib" ; MacOS X )) This looks like a random collection of files that worked for random people, not like someone who knows what (s)he is doing and where the problems are. There are several things that wrong with this. One problem is that the libmysqlclient18 package does not ship the .so symlink. Another is trying to open libraries from /usr/local, whenever such libraries exist using them from a Debian package only causes problems. But the worst is that this cannot work properly with multiarch. On my multiarch enabled system I might be using either the i386 newlisp package or the amd64 newlisp package. I might have both the i386 and the amd64 version of the library to load installed. As long as newlisp searches in the same paths in both cases, it is guaranteed to not find the correct library in at least one case. Other libraries used by newlisp have exactly the same problem.
--- End Message ---
--- Begin Message ---Source: newlisp Source-Version: 10.7.0-4 We believe that the bug you reported is fixed in the latest version of newlisp, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [email protected], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Sergio Durigan Junior <[email protected]> (supplier of updated newlisp package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [email protected]) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Mon, 30 Jan 2017 16:59:36 -0500 Source: newlisp Binary: newlisp Architecture: source Version: 10.7.0-4 Distribution: unstable Urgency: medium Maintainer: Sergio Durigan Junior <[email protected]> Changed-By: Sergio Durigan Junior <[email protected]> Description: newlisp - LISP like, general purpose scripting language Closes: 852259 Changes: newlisp (10.7.0-4) unstable; urgency=medium . * Fix shared library loading for modules. Upstream uses a system for dlopen'ing shared libraries that is not very robust. They depend on libraries being installed on full paths, which can break things when you move from one system to another. Because of this, a fix had to be implemented downstream in order to use dlopen's functionality of automatically searching the system libraries when you pass just the file name to it. This also has the benefit of not trying to load libraries from /usr/local, which can be dangerous. (Closes: #852259) Checksums-Sha1: 6b1a8398fa0c1b4f52cb5614a6d4be89e9e75f58 1906 newlisp_10.7.0-4.dsc 296919b6ca52dc3b8d5cffa8a8e0e0d7b3f50b16 20456 newlisp_10.7.0-4.debian.tar.xz 50db125bba3c3feefd6f682b4fe566231104bef9 4800 newlisp_10.7.0-4_amd64.buildinfo Checksums-Sha256: 4e49f22ed57d82be0eac485af0c389e29aefbefcce0488efeaac23c7678804f6 1906 newlisp_10.7.0-4.dsc f94f60427404640b5560ce010e17ef0bc143ff136f2df6ae77effda248d9c3a2 20456 newlisp_10.7.0-4.debian.tar.xz 9657d86cb2cf24352bce027f4de7c7ca02ac8cf195dd4d79c47f5cf16528ac17 4800 newlisp_10.7.0-4_amd64.buildinfo Files: 604ef6c31615a1bc5f34dedabf9fe445 1906 lisp optional newlisp_10.7.0-4.dsc efd05cbe0ecf16d3ff9d373ef2b473bf 20456 lisp optional newlisp_10.7.0-4.debian.tar.xz ae420e15015214ab0a7ea4df540331fa 4800 lisp optional newlisp_10.7.0-4_amd64.buildinfo -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEI3pUsQKHKL8A7zH00Ot2KGX8XjYFAliPuRkACgkQ0Ot2KGX8 XjasQRAAqDSPWW37BI+y8G9zSYR3Kq1oDog7yf8zBZsfhs5nrKFCEbHCHjXWnd9G DZ2ClyRKXlTk+xLXfzRGyJjCPubs94OWOz+ahvpfiOmK+U/edkDz6xVw/G+51oJY xGBpulK5nRa6WBMlsOcxfGDbsdyoA832RHJ2LogZoCfbHhmIxyvyxdY+B8JLEWCI lBB89HmrRGHvNLb0qniqK/ZAYzzKvbYdVWkmxTFS+2KwjeRfM54jY7/k+JsCZuxz zNANkuVpDQzKSrc9DarqXRRP+DD8v4gmNZO5WxroT7v4fuxQDfu/thT+Ad2dXJRT 6Djcdop+eVrCUfhQNrvSYOz8oD5q7Xu3mGmjU90M4ErNhTGFvytmy64v9Iw9UJBv ovRPCb7TvVRc1adVl8F2fFXzkhMMY46KH8U5kkyaMjAsaIB3tEiWt6p9ZsxIdmlS fWuOtE+p6+DF5oRPAGEp4dN/W6MFGDF6czhZLLC6fWFBWwabPDpHiqUKIcYrepjd fncrsvFaL4wKTgCPBV/uEz6CYXcegHugcC7qODNV9npHgEY8K8BqLTUJvORaFmWe TnDJLA5b/vztSYJoPyDBve3dqruGo7cK4u6jkHrDDvCv40NBYPeoXS9QX7HsgYAu cxci6bKT0IqoQUDc2YEuD2G8z9RQYhROQ40xEjnm4J9kgsijZNA= =SEAz -----END PGP SIGNATURE-----
--- End Message ---
