Menu
▾
▴
zero-install-devel
|
From: Thomas L. <ta...@gm...> - 2014-01-06 16:46:43
|
Here's a second release candidate for 0install 2.6 (2.6-rc2): http://0install.net/tools/0install.xml 0install 2.6 completes the transition from Python to OCaml :-) There is no remaining Python code in 0install and, therefore, no need to have Python installed in order to build or run it. Notes: 0install now runs the unit-tests when you build it, and will abort if they fail. Please report any problems. You can remove "test" from the "all" target in ocaml/Makefile if it's a problem for you (also, the tests are only run if oUnit is installed). Changes since 2.6-rc1 - On non-Linux platforms, use Lwt_glib's lwt_into_glib mode. This requires a Git checkout of LWT, but that's better than the other option, which doesn't work at all. Note: if you don't build the GTK GUI, there's no problem (and therefore Windows is unaffected, as it never builds the GUI). - Fixed race when cancelling downloads. The main thread might set the progress report to "finished" and then the download thread gets some more data and sets it back to "in-progress" before the cancel takes effect. This meant that the GUI would continue showing the progress bar even after cancelling. - Don't strip the 0install binary. That prevents the GTK plugin from loading on OS X. Reported by Anders F Björklund. - Detect Python even if python-gobject is missing. Reported by Anders F Björklund. - Some internal code cleanups: there are .mli interfaces for more modules and the APIs have been cleaned up a bit (the biggest change is that XML elements are now immutable, and can therefore be safely shared). Changes since 2.5 New features: - Added "0install slave" subcommand. This makes it possible to control 0install using a JSON API. The "sample_client.py" file shows how to invoke 0install from Python. Currently, the only operation available is "select", which downloads feeds and does a solve, but more can be added - let me know what you need. Changes: - Migrated GTK GUI to OCaml. It mostly looks the same, but the "0desktop" box has changed to a more compact icon view display. Also, displaying the app list is now the default (and the 0desktop --manage option is gone). - The console progress display has changed slightly: it now shows the progress of one download at a time rather than all at once. The downloads still happen in parallel, though. - The install script now allows using $DESTDIR and installing to /usr/local (Anders F Bjorklund). - You can now do "0install store ..." instead of "0store ..." (which still works). If you do this, you get tab-completion too! Bug fixes: - Cope with dpkg-query returning a non-zero exit status. It returns 1 if the package isn't found. - Fixed cancelling of downloads. Throwing an exception back to ocurl's set_writefunction handler left the connection in a bad state. - Fixed Utils.slice when start and end are both given (Tim Cuthbertson) (this case was never used by the current code). - Fixed unit-tests when $TEMP is a symlink. Reported by Anders F Björklund. - Don't use the non-portable -D flag to install (Anders F Bjorklund). To make it work with BSD install(1) in addition to GNU install(1), make sure to use "install -d && install" rather than install -D. - Fixed installation error when share/0install.net doesn't exist. Reported by Alberto Colombo. - Don't warn about the default bin dir not being in PATH when destroying an app. Developer-visible changes: - Pick a random unused port for the test server during unit-testing. Avoids conflicts with other programs and makes it possible to run the tests in parallel. - If $ZEROINSTALL_CRASH_LOGS is set to a directory, record all log messages in memory. If 0install logs a warning or reports an error, dump the complete log to a timestamped file in this directory. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA |
|
From: Tim C. <ti...@gf...> - 2014-01-07 05:51:57
|
Sorry for not chiming in earlier with this (I've been rather busy), but I just tried it out on Fedora 20. Looks like the prebuilt binary is missing a dependency (or maybe it's a distro issue, I can't quite tell): $ 0install run --not-before=2.6-rc2 http://0install.net/tools/0install.xml /home/tim/.cache/ 0install.net/implementations/sha256new_7KPHCS36EE3TRNOUBLXLV3NXPOW3WITJJMJZ6A45XC2CYMSRGRNQ/files/0install: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory $ locate libcrypto /usr/lib/.libcrypto.so.1.0.1e.hmac /usr/lib/.libcrypto.so.10.hmac /usr/lib/libcrypto.so.1.0.1e /usr/lib/libcrypto.so.10 /usr/lib64/.libcrypto.so.1.0.1e.hmac /usr/lib64/.libcrypto.so.10.hmac /usr/lib64/libcrypto.so.1.0.1e /usr/lib64/libcrypto.so.10 /usr/lib64/libcryptopp.so.6 /usr/lib64/libcryptopp.so.6.0.0 $ ldd /home/tim/.cache/ 0install.net/implementations/sha256new_7KPHCS36EE3TRNOUBLXLV3NXPOW3WITJJMJZ6A45XC2CYMSRGRNQ/files/0install linux-vdso.so.1 => (0x00007fff08dfe000) libcrypto.so.1.0.0 => not found libssl.so.1.0.0 => not found libcurl.so.4 => /lib64/libcurl.so.4 (0x00007fa763a32000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007fa763706000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa7634e8000) libm.so.6 => /lib64/libm.so.6 (0x00007fa7631e1000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fa762fdd000) libc.so.6 => /lib64/libc.so.6 (0x00007fa762c1d000) libidn.so.11 => /lib64/libidn.so.11 (0x00007fa7629ea000) libssh2.so.1 => /lib64/libssh2.so.1 (0x00007fa7627c0000) libssl3.so => /lib64/libssl3.so (0x00007fa762581000) libsmime3.so => /lib64/libsmime3.so (0x00007fa762354000) libnss3.so => /lib64/libnss3.so (0x00007fa76200d000) libnssutil3.so => /lib64/libnssutil3.so (0x00007fa761de0000) libplds4.so => /lib64/libplds4.so (0x00007fa761bdc000) libplc4.so => /lib64/libplc4.so (0x00007fa7619d7000) libnspr4.so => /lib64/libnspr4.so (0x00007fa761798000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fa76154e000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fa76126e000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fa761038000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fa760e34000) liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007fa760c25000) libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007fa7609d2000) libz.so.1 => /lib64/libz.so.1 (0x00007fa7607bc000) /lib64/ld-linux-x86-64.so.2 (0x00007fa763cb6000) libssl.so.10 => /lib64/libssl.so.10 (0x00007fa76054f000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fa760168000) librt.so.1 => /lib64/librt.so.1 (0x00007fa75ff5f000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fa75fd51000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fa75fb4d000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fa75f932000) libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007fa75f715000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fa75f4f0000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fa75f2b9000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fa75f053000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fa75ee2d000) libfreebl3.so => /lib64/libfreebl3.so (0x00007fa75ebaf000) I just tried rc1 as well, with the same results. On Tue, Jan 7, 2014 at 3:46 AM, Thomas Leonard <ta...@gm...> wrote: > Here's a second release candidate for 0install 2.6 (2.6-rc2): > > http://0install.net/tools/0install.xml > > 0install 2.6 completes the transition from Python to OCaml :-) There > is no remaining Python code in 0install and, therefore, no need to > have Python installed in order to build or run it. > > Notes: > > 0install now runs the unit-tests when you build it, and will abort if > they fail. Please report any problems. You can remove "test" from the > "all" target in ocaml/Makefile if it's a problem for you (also, the > tests are only run if oUnit is installed). > > > Changes since 2.6-rc1 > > - On non-Linux platforms, use Lwt_glib's lwt_into_glib mode. This > requires a Git checkout of LWT, but that's better than the other > option, which doesn't work at all. Note: if you don't build the GTK > GUI, there's no problem (and therefore Windows is unaffected, as it > never builds the GUI). > > - Fixed race when cancelling downloads. The main thread might set the > progress report to "finished" and then the download thread gets some > more data and sets it back to "in-progress" before the cancel takes > effect. This meant that the GUI would continue showing the progress > bar even after cancelling. > > - Don't strip the 0install binary. That prevents the GTK plugin from > loading on OS X. Reported by Anders F Björklund. > > - Detect Python even if python-gobject is missing. Reported by Anders > F Björklund. > > - Some internal code cleanups: there are .mli interfaces for more > modules and the APIs have been cleaned up a bit (the biggest change is > that XML elements are now immutable, and can therefore be safely > shared). > > > Changes since 2.5 > > New features: > > - Added "0install slave" subcommand. This makes it possible to control > 0install using a JSON API. The "sample_client.py" file shows how to > invoke 0install from Python. Currently, the only operation available > is "select", which downloads feeds and does a solve, but more can be > added - let me know what you need. > > > Changes: > > - Migrated GTK GUI to OCaml. It mostly looks the same, but the > "0desktop" box has changed to a more compact icon view display. Also, > displaying the app list is now the default (and the 0desktop --manage > option is gone). > > - The console progress display has changed slightly: it now shows the > progress of one download at a time rather than all at once. The > downloads still happen in parallel, though. > > - The install script now allows using $DESTDIR and installing to > /usr/local (Anders F Bjorklund). > > - You can now do "0install store ..." instead of "0store ..." (which > still works). If you do this, you get tab-completion too! > > > Bug fixes: > > - Cope with dpkg-query returning a non-zero exit status. It returns 1 > if the package isn't found. > > - Fixed cancelling of downloads. Throwing an exception back to ocurl's > set_writefunction handler left the connection in a bad state. > > - Fixed Utils.slice when start and end are both given (Tim > Cuthbertson) (this case was never used by the current code). > > - Fixed unit-tests when $TEMP is a symlink. Reported by Anders F Björklund. > > - Don't use the non-portable -D flag to install (Anders F Bjorklund). > To make it work with BSD install(1) in addition to GNU install(1), > make sure to use "install -d && install" rather than install -D. > > - Fixed installation error when share/0install.net doesn't exist. > Reported by Alberto Colombo. > > - Don't warn about the default bin dir not being in PATH when destroying > an app. > > > Developer-visible changes: > > - Pick a random unused port for the test server during unit-testing. > Avoids conflicts with other programs and makes it possible to run the > tests in parallel. > > - If $ZEROINSTALL_CRASH_LOGS is set to a directory, record all log > messages in memory. If 0install logs a warning or reports an error, > dump the complete log to a timestamped file in this directory. > > > -- > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Zero-install-devel mailing list > Zer...@li... > https://lists.sourceforge.net/lists/listinfo/zero-install-devel > |
|
From: Anders F B. <af...@us...> - 2014-01-07 21:03:28
|
Tim Cuthbertson wrote: > Sorry for not chiming in earlier with this (I've been rather busy), but I just tried it out on Fedora 20. Looks like the prebuilt binary is missing a dependency (or maybe it's a distro issue, I can't quite tell): ... > error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory This has been broken/incompatible between Redhat and Debian, since about forever or so... Basically Fedora just makes something up at random: # For the curious: # 0.9.5a soversion = 0 # 0.9.6 soversion = 1 # 0.9.6a soversion = 2 # 0.9.6c soversion = 3 # 0.9.7a soversion = 4 # 0.9.7ef soversion = 5 # 0.9.8ab soversion = 6 # 0.9.8g soversion = 7 # 0.9.8jk + EAP-FAST soversion = 8 # 1.0.0 soversion = 10 %define soversion 10 And then renames the target in the Makefile to match: @@ -10,6 +10,7 @@ SHLIB_VERSION_HISTORY= SHLIB_MAJOR= SHLIB_MINOR= SHLIB_EXT= +SHLIB_SONAMEVER=10 PLATFORM=dist OPTIONS= CONFIGURE_ARGS= @@ -347,7 +347,7 @@ do_$(SHLIB_TARGET): libs="$(LIBKRB5) $$libs"; \ fi; \ $(CLEARENV) && $(MAKE) -f Makefile.shared -e $(BUILDENV) \ - LIBNAME=$$i LIBVERSION=$(SHLIB_MAJOR).$(SHLIB_MINOR) \ + LIBNAME=$$i LIBVERSION=$(SHLIB_SONAMEVER) \ LIBCOMPATVERSIONS=";$(SHLIB_VERSION_HISTORY)" \ LIBDEPS="$$libs $(EX_LIBS)" \ link_a.$(SHLIB_TARGET); \ Supposedly one could just provde some compatibility shim that tries to load either soname ? Or force the user to do some creative symlinking... Sadly, this seems to be the more popular "answer". --anders PS. Maybe not "forever", but surely "decade": http://www.openwall.com/lists/xvendor/2004/03/01/1 |
|
From: Anders F B. <af...@us...> - 2014-01-07 23:16:47
|
>> Looks like the prebuilt binary is missing a dependency (or maybe it's a distro issue, I can't quite tell): > ... >> error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory > > This has been broken/incompatible between Redhat and Debian, since about forever or so... > > Supposedly one could just provde some compatibility shim that tries to load either soname ? > > > Or force the user to do some creative symlinking... > > Sadly, this seems to be the more popular "answer". The symlink workaround doesn't work, since the library is indeed OpenSSL 1.0.1 only. So it is missing the OPENSSL_1.0.0 symbols anyway, even if the name is symlinked. Guess the only workaround is to actually install libssl.so.1.0.0/libcrypto.so.1.0.0 ? Perhaps this could be added to the feed, with a binary and package-dep on libssl1.0.0 BTW; It doesn't work on RHEL 6 either, this time because it requires glibc > 2.12... I suppose we need some updated RPMS, if this is supposed to build and install easier. --anders |
|
From: Thomas L. <ta...@gm...> - 2014-01-09 17:02:56
|
On 7 January 2014 23:16, Anders F Björklund <af...@us...> wrote: >>> Looks like the prebuilt binary is missing a dependency (or maybe it's a distro issue, I can't quite tell): >> ... >>> error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory >> >> This has been broken/incompatible between Redhat and Debian, since about forever or so... >> Basically Fedora just makes something up at random: Wow. That's crazy. Thanks for the explanation! >> Supposedly one could just provde some compatibility shim that tries to load either soname ? >> >> >> Or force the user to do some creative symlinking... >> >> Sadly, this seems to be the more popular "answer". > > > The symlink workaround doesn't work, since the library is indeed OpenSSL 1.0.1 only. > So it is missing the OPENSSL_1.0.0 symbols anyway, even if the name is symlinked. I've built new binaries (2.6-rc3) against upstream openssl and libcurl, so hopefully untainted by Debian or Fedora craziness. Anyway, the symbol versions seem to be gone :-) > Guess the only workaround is to actually install libssl.so.1.0.0/libcrypto.so.1.0.0 ? > Perhaps this could be added to the feed, with a binary and package-dep on libssl1.0.0 > > BTW; It doesn't work on RHEL 6 either, this time because it requires glibc > 2.12... > > I suppose we need some updated RPMS, if this is supposed to build and install easier. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA |
|
From: Anders F B. <af...@us...> - 2014-01-09 21:10:02
|
Thomas Leonard wrote: >> The symlink workaround doesn't work, since the library is indeed OpenSSL 1.0.1 only. >> So it is missing the OPENSSL_1.0.0 symbols anyway, even if the name is symlinked. > > I've built new binaries (2.6-rc3) against upstream openssl and > libcurl, so hopefully untainted by Debian or Fedora craziness. Anyway, > the symbol versions seem to be gone :-) Yes, this one works OK against the system libraries in Fedora! At least it didn't get any symbol issues when starting up. :-) >> Guess the only workaround is to actually install libssl.so.1.0.0/libcrypto.so.1.0.0 ? >> Perhaps this could be added to the feed, with a binary and package-dep on libssl1.0.0 This is still needed, since I needed symlinks from the system library (called "libssl.so.1.0.1e") to this "libssl.so.1.0.0"... Could you add them as a http://repo.roscidus.com/crypto/openssl ? I suppose it could use the system packages for Debian, but not RPM. >> BTW; It doesn't work on RHEL 6 either, this time because it requires glibc > 2.12... >> I suppose we need some updated RPMS, if this is supposed to build and install easier. Seems there's a couple of the dependencies that needs packaging for Fedora, but those should be straight-forward enough to do ? https://fedoraproject.org/wiki/Packaging:OCaml?rd=Packaging/OCaml Available ones are: http://pkgs.fedoraproject.org/cgit/?q=ocaml --anders |
|
From: Tim C. <ti...@gf...> - 2014-01-09 23:01:38
|
On Fri, Jan 10, 2014 at 4:02 AM, Thomas Leonard <ta...@gm...> wrote: > On 7 January 2014 23:16, Anders F Björklund <af...@us...> wrote: >>>> Looks like the prebuilt binary is missing a dependency (or maybe it's a distro issue, I can't quite tell): >>> ... >>>> error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory >>> >>> This has been broken/incompatible between Redhat and Debian, since about forever or so... >>> Basically Fedora just makes something up at random: > > Wow. That's crazy. Thanks for the explanation! > >>> Supposedly one could just provde some compatibility shim that tries to load either soname ? >>> >>> >>> Or force the user to do some creative symlinking... >>> >>> Sadly, this seems to be the more popular "answer". >> >> >> The symlink workaround doesn't work, since the library is indeed OpenSSL 1.0.1 only. >> So it is missing the OPENSSL_1.0.0 symbols anyway, even if the name is symlinked. > > I've built new binaries (2.6-rc3) against upstream openssl and > libcurl, so hopefully untainted by Debian or Fedora craziness. Anyway, > the symbol versions seem to be gone :-) Hmm, this still doesn't work for me: $ 0install run --not-before=2.6-rc3 http://0install.net/tools/0install.xml /home/tim/.cache/0install.net/implementations/sha256new_XBH32RLRWOXKRBDE7RA4L357CHREDW4FHU6BMZWB3F465S3RQQOA/files/0install: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory ldd still reports: libcrypto.so.1.0.0 => not found libssl.so.1.0.0 => not found If you've built against the upstream libssl, doesn't that mean you need to depend on upstream-named .so files as well? I still only have the fedora .so files, which are named crazily. Or does this still depend on the symlink workaround that Anders mentioned? That seems like more effort than an end user should be expected to do. Cheers, - Tim. |
|
From: Thomas L. <ta...@gm...> - 2014-01-10 10:13:19
|
On 9 January 2014 22:54, Tim Cuthbertson <ti...@gf...> wrote: > On Fri, Jan 10, 2014 at 4:02 AM, Thomas Leonard <ta...@gm...> wrote: >> On 7 January 2014 23:16, Anders F Björklund <af...@us...> wrote: >>>>> Looks like the prebuilt binary is missing a dependency (or maybe it's a distro issue, I can't quite tell): >>>> ... >>>>> error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory >>>> >>>> This has been broken/incompatible between Redhat and Debian, since about forever or so... >>>> Basically Fedora just makes something up at random: >> >> Wow. That's crazy. Thanks for the explanation! >> >>>> Supposedly one could just provde some compatibility shim that tries to load either soname ? >>>> >>>> >>>> Or force the user to do some creative symlinking... >>>> >>>> Sadly, this seems to be the more popular "answer". >>> >>> >>> The symlink workaround doesn't work, since the library is indeed OpenSSL 1.0.1 only. >>> So it is missing the OPENSSL_1.0.0 symbols anyway, even if the name is symlinked. >> >> I've built new binaries (2.6-rc3) against upstream openssl and >> libcurl, so hopefully untainted by Debian or Fedora craziness. Anyway, >> the symbol versions seem to be gone :-) > > Hmm, this still doesn't work for me: > > $ 0install run --not-before=2.6-rc3 http://0install.net/tools/0install.xml > /home/tim/.cache/0install.net/implementations/sha256new_XBH32RLRWOXKRBDE7RA4L357CHREDW4FHU6BMZWB3F465S3RQQOA/files/0install: > error while loading shared libraries: libcrypto.so.1.0.0: cannot open > shared object file: No such file or directory > > ldd still reports: > > libcrypto.so.1.0.0 => not found > libssl.so.1.0.0 => not found > > If you've built against the upstream libssl, doesn't that mean you > need to depend on upstream-named .so files as well? Yes. It's not a complete solution, but it does a) make it possible to run on Fedora (with the symlink hack) b) get rid of the warning on Arch Since nothing depends on the OCaml feed currently, I think we can still release this as 2.6. Distributions can include it and build their own binaries. Then we can try to figure out some dynamic linker tricks to make the binaries generic for 2.7 (or static link openssl, though I'd prefer to avoid that). > I still only have > the fedora .so files, which are named crazily. Or does this still > depend on the symlink workaround that Anders mentioned? That seems > like more effort than an end user should be expected to do. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA |
|
From: Anders F B. <af...@us...> - 2014-01-14 22:51:45
|
Thomas Leonard wrote: >>> I've built new binaries (2.6-rc3) against upstream openssl and >>> libcurl, so hopefully untainted by Debian or Fedora craziness. Anyway, >>> the symbol versions seem to be gone :-) >> >> Hmm, this still doesn't work for me: >> >> $ 0install run --not-before=2.6-rc3 http://0install.net/tools/0install.xml >> /home/tim/.cache/0install.net/implementations/sha256new_XBH32RLRWOXKRBDE7RA4L357CHREDW4FHU6BMZWB3F465S3RQQOA/files/0install: >> error while loading shared libraries: libcrypto.so.1.0.0: cannot open >> shared object file: No such file or directory >> >> ldd still reports: >> >> libcrypto.so.1.0.0 => not found >> libssl.so.1.0.0 => not found >> >> If you've built against the upstream libssl, doesn't that mean you >> need to depend on upstream-named .so files as well? > > Yes. It's not a complete solution, but it does > > a) make it possible to run on Fedora (with the symlink hack) > b) get rid of the warning on Arch > > Since nothing depends on the OCaml feed currently, I think we can > still release this as 2.6. Distributions can include it and build > their own binaries. Then we can try to figure out some dynamic linker > tricks to make the binaries generic for 2.7 (or static link openssl, > though I'd prefer to avoid that). I think there are some licensing issues when mixing GPL and OpenSSL, since the licenses aren't compatible - but there is an exception with the "system" openssl, which means the dynamically linked one. Including any funky naming schemes, like "1.1.0e" or "10" or so... So I think we need to build RPMS*, should also fix RHEL6's glibc-2.12 ? I uploaded a 2.6-rc3 binary for OS X ("darwin") now, as well as the two for GNU ("linux") already there. It requires glib/gtk+ and gnupg, but fortunately both openssl and libcurl are provided by the system. The rest can be added by just installing my PyGTK.pkg and GnuPG.pkg. Upgraded to OCaml 4.01.0 and OPAM 1.1.0 first, before building it... --anders * Both EPEL 6 and Fedora 20 are currently shipping 0install-2.3.3 as "zeroinstall-injector". We need a new .spec, for 0install-2.6! |
|
From: Thomas L. <ta...@gm...> - 2014-01-14 23:07:19
|
On 14 January 2014 22:51, Anders F Björklund <af...@us...> wrote: > Thomas Leonard wrote: > >>>> I've built new binaries (2.6-rc3) against upstream openssl and >>>> libcurl, so hopefully untainted by Debian or Fedora craziness. Anyway, >>>> the symbol versions seem to be gone :-) >>> >>> Hmm, this still doesn't work for me: >>> >>> $ 0install run --not-before=2.6-rc3 http://0install.net/tools/0install.xml >>> /home/tim/.cache/0install.net/implementations/sha256new_XBH32RLRWOXKRBDE7RA4L357CHREDW4FHU6BMZWB3F465S3RQQOA/files/0install: >>> error while loading shared libraries: libcrypto.so.1.0.0: cannot open >>> shared object file: No such file or directory >>> >>> ldd still reports: >>> >>> libcrypto.so.1.0.0 => not found >>> libssl.so.1.0.0 => not found >>> >>> If you've built against the upstream libssl, doesn't that mean you >>> need to depend on upstream-named .so files as well? >> >> Yes. It's not a complete solution, but it does >> >> a) make it possible to run on Fedora (with the symlink hack) >> b) get rid of the warning on Arch >> >> Since nothing depends on the OCaml feed currently, I think we can >> still release this as 2.6. Distributions can include it and build >> their own binaries. Then we can try to figure out some dynamic linker >> tricks to make the binaries generic for 2.7 (or static link openssl, >> though I'd prefer to avoid that). > > I think there are some licensing issues when mixing GPL and OpenSSL, > since the licenses aren't compatible - but there is an exception > with the "system" openssl, which means the dynamically linked one. > Including any funky naming schemes, like "1.1.0e" or "10" or so... > > So I think we need to build RPMS*, should also fix RHEL6's glibc-2.12 ? > > I uploaded a 2.6-rc3 binary for OS X ("darwin") now, as well as the > two for GNU ("linux") already there. It requires glib/gtk+ and gnupg, > but fortunately both openssl and libcurl are provided by the system. > The rest can be added by just installing my PyGTK.pkg and GnuPG.pkg. > > Upgraded to OCaml 4.01.0 and OPAM 1.1.0 first, before building it... > > --anders > > > * Both EPEL 6 and Fedora 20 are currently shipping 0install-2.3.3 > as "zeroinstall-injector". We need a new .spec, for 0install-2.6! Yeah, but let's wait a bit... I'm still finding bugs! Looks like OpenSUSE has an incompatible version of PackageKit... probably the others do too... -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA |
