Re: [E-devel] Terminology 1.3.2
Boris Faure wrote: [...] > Due to issues with enlightenment.org infrastructure, I am hosting the > tarball and will also do that on the next releases. > It can be found at https://fau.re/terminology/terminology-1.3.2.tar.xz [...] Hello, could you please update the index page / make it non-static? | ametzler@argenau:~$ w3m -dump 'https://fau.re/terminology/' | • terminology-1.3.1.tar.xz | • terminology-1.3.1.tar.xz.sha256sum | • terminology-1.3.0.tar.xz | • terminology-1.3.0.tar.xz.sha256sum TIA, cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is luajit/lua-old a hard dependency of EFL 1.20.6?
On 2017-12-17 Carsten Haitzler <ras...@rasterman.com> wrote: > On Sat, 16 Dec 2017 14:08:11 +0100 Andreas Metzler <ametz...@bebt.de> said: >> (sid):/tmp/EFL/efl-1.20.6$ ./configure --help | grep -i lua >> --enable-lua-oldEnable interpreted Lua support (5.1 or 5.2). >> --enable-elua enable ELUA support. [default=enabled] >> --with-elua=PATHspecify a specific path to elua [default=elua] >> --with-bin-elua=PATHspecify a specific path to elua [default=elua] >> seemed to /suggest/ to me that EFL could be built without lua support. >> However even with > it cannot. choices are luajit or "old regular lua". and even then old regular > lua is basically being deprecated. Hello, Thanks for the explanation. > the new luajit release in beta has arm64 > support now, so ... it's pretty much time to move on. [...] luajit generally has support for arm64 but EFL breaks with "bad light userdata pointer" (T6156), so as a workaround we have switched to lua-old on Debian/arm64. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Is luajit/lua-old a hard dependency of EFL 1.20.6?
Hello, this (sid):/tmp/EFL/efl-1.20.6$ ./configure --help | grep -i lua --enable-lua-oldEnable interpreted Lua support (5.1 or 5.2). --enable-elua enable ELUA support. [default=enabled] --with-elua=PATHspecify a specific path to elua [default=elua] --with-bin-elua=PATHspecify a specific path to elua [default=elua] seemed to /suggest/ to me that EFL could be built without lua support. However even with --disable-elua --without-bin-elua --disable-lua-old ./configure fails with configure: error: pkg-config missing luajit >= 2.0.0 due to this line in configure.ac: if test "${want_lua_old}" = "yes"; then EFL_CHECK_LUA_OLD([EVAS]) else EFL_DEPEND_PKG([EVAS], [LUAJIT], [luajit >= 2.0.0]) fi Is lua (i.e. either luajit or lua-old) a hard dependency of efl or is this simply an overstrict dependency in ./configure? thanks, cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/enlightenment] enlightenment-0.21 06/26: 10_typo_restore_LDFLAGS.diff: Fix typo in configure.ac (upstream), causing empty LDFLAGS.
discomfitor pushed a commit to branch enlightenment-0.21. http://git.enlightenment.org/core/enlightenment.git/commit/?id=b6852b2120a9552d5d038c7d426d2e99d1c317dd commit b6852b2120a9552d5d038c7d426d2e99d1c317dd Author: Andreas Metzler <ametz...@bebt.de> Date: Thu Dec 22 10:17:48 2016 -0500 10_typo_restore_LDFLAGS.diff: Fix typo in configure.ac (upstream), causing empty LDFLAGS. Summary: typo spotted while packaging E 0.21.5 for Debian experimental Reviewers: zmike! Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D4507 --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 2e9588d..e3b8808 100644 --- a/configure.ac +++ b/configure.ac @@ -1041,7 +1041,7 @@ case "$host_os" in AC_MSG_RESULT(yes)], AC_MSG_RESULT(no)) CFLAGS="$OLDCFLAGS" -LDFLAGS="$OLDLFDLAGS" +LDFLAGS="$OLDLDFLAGS" fi ;; esac --
[EGIT] [core/enlightenment] master 01/01: 10_typo_restore_LDFLAGS.diff: Fix typo in configure.ac (upstream), causing empty LDFLAGS.
discomfitor pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=8efbeb7acf9a029f4dad559ff4bedd5a586ed813 commit 8efbeb7acf9a029f4dad559ff4bedd5a586ed813 Author: Andreas Metzler <ametz...@bebt.de> Date: Thu Dec 22 10:17:48 2016 -0500 10_typo_restore_LDFLAGS.diff: Fix typo in configure.ac (upstream), causing empty LDFLAGS. Summary: typo spotted while packaging E 0.21.5 for Debian experimental Reviewers: zmike! Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D4507 --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index bb30fed..5253f34 100644 --- a/configure.ac +++ b/configure.ac @@ -1068,7 +1068,7 @@ case "$host_os" in AC_MSG_RESULT(yes)], AC_MSG_RESULT(no)) CFLAGS="$OLDCFLAGS" -LDFLAGS="$OLDLFDLAGS" +LDFLAGS="$OLDLDFLAGS" fi ;; esac --
Re: [E-devel] EFL sonames
Carsten Haitzler (The Rasterman)wrote: [...] >> > (unless of course you rely on api documented >> > to be unstable - eg like eo. that we document to be experimental >> > and we do break it). >> Which means that we should not ship the eo API in Debian. > you have no choice. efl depends on it. eg elementary cannot be > compiled without eo api's exposed from efl. WE keep elm in sync with > efl, so it will work. just to begin. Hello, I see, I thought we could use --with-api=legacy but it is a noop now. > secondly you cannot "access" eo > api unless you define a special #define in your app before including > efl headers. without it the eo api is ifdef'ed out (hidden). so > anyone using it is making a very explicit choice to use it. you need > to read documentation to figure out how to turn it on, and this will > tell you that it is unstable. :) >> However afaict e.g. elementary only provides an eo API since 1.13 and is >> required by E. > it's earlier than that. :) see above. Could you doublecheck whether this roughly sums up the facts? There is a) a stable api (legacy) and b) the new api (eo), which is not yet stable. Most/all official "e" packages (e.g. elementary or enlightenment) nowadays use the latter and you develop/test them in sync, i.e. the 1.16 libraries and Enlightenment 0.19 are working correctly together. However there is no guarantee that e.g. Enlightenment 0.19 built against efl 1.15 continues to work without a rebuild after ugrading efl to 1.16. Third party packages are supposed to continue using the legacy API. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- Presto, an open source distributed SQL query engine for big data, initially developed by Facebook, enables you to easily query your data on Hadoop in a more interactive manner. Teradata is also now providing full enterprise support for Presto. Download a free open source copy now. http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL sonames
On 2015-11-07 Carsten Haitzler <ras...@rasterman.com> wrote: > On Sat, 7 Nov 2015 08:18:55 +0100 Andreas Metzler <ametz...@bebt.de> said: [...] >> Jumping in, let me outline the question a little bit more extensively: >> Let's assume I found that there is ABI breakage when upgrading >> libfoo from efl 1.8 to libfoo from efl 1.15 while both releases of >> libfoo shared the same soname. i.e. a binary built against >> libfoo-efl1.8 will stop working correctly when libfoo is upgraded to >> libfoo-efl1.15. If I reported a bug about this issue would you >> consider it to be release-critical and would you resolve it by either >> fixing the ABI breakage or bumping the soname? > how does THAT mean there is an ABI break? it could simply be that > there was reliance on undefined behavior that has now changed, or > the app was LUCKY to not trigger a bug before and now it does. just > because something used to work and now doesn't does NOT mean there > is an ABI break. you don't know until you dig in and find out. Hello, yes, you are right. I was trying to ask about a "real" ABI break, i.e. public interfaces breaking and requiring a rebuild (or even source changes) in reverse dependencies. >> (Obviously this implies that I generally would not usually find such >> issues, since making sure that ABI breakage is avoided would be part >> of the release process.) > we actually run ABI reports every release (these check structures, > actual function call signatures, symbols etc.). we don't break our > ABI according to this Ok, that is great, thanks. > (unless of course you rely on api documented > to be unstable - eg like eo. that we document to be experimental > and we do break it). Which means that we should not ship the eo API in Debian. However afaict e.g. elementary only provides an eo API since 1.13 and is required by E. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: ecore con: Fix GnuTLS build error.
tasn pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=ecfcb59c44a9bc7dd2ce95493806f6ac107c0d46 commit ecfcb59c44a9bc7dd2ce95493806f6ac107c0d46 Author: Andreas Metzler ametz...@debian.org Date: Wed Dec 3 12:07:40 2014 + ecore con: Fix GnuTLS build error. By making the respective changes on the GnuTLS side for upstream commits d9b5f192d4883193f79cd3e43ed1da52521825dc and d72f809fb874c8f14b1461949802905d41d648a1 which only take care of OpenSSL. @fix --- src/lib/ecore_con/ecore_con_ssl.c | 78 +++ 1 file changed, 46 insertions(+), 32 deletions(-) diff --git a/src/lib/ecore_con/ecore_con_ssl.c b/src/lib/ecore_con/ecore_con_ssl.c index bf63469..d31b44e 100644 --- a/src/lib/ecore_con/ecore_con_ssl.c +++ b/src/lib/ecore_con/ecore_con_ssl.c @@ -885,9 +885,10 @@ _ecore_con_ssl_shutdown_gnutls(void) } static Ecore_Con_Ssl_Error -_ecore_con_ssl_server_prepare_gnutls(Ecore_Con_Server *svr, +_ecore_con_ssl_server_prepare_gnutls(Ecore_Con_Server *obj, int ssl_type) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); int ret; if (ssl_type ECORE_CON_USE_SSL2) @@ -938,13 +939,14 @@ _ecore_con_ssl_server_prepare_gnutls(Ecore_Con_Server *svr, error: _gnutls_print_errors(svr, ECORE_CON_EVENT_SERVER_ERROR, ret); - _ecore_con_ssl_server_shutdown_gnutls(svr); + _ecore_con_ssl_server_shutdown_gnutls(obj); return ECORE_CON_SSL_ERROR_SERVER_INIT_FAILED; } static Ecore_Con_Ssl_Error -_ecore_con_ssl_server_init_gnutls(Ecore_Con_Server *svr) +_ecore_con_ssl_server_init_gnutls(Ecore_Con_Server *obj) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); const gnutls_datum_t *cert_list; unsigned int iter, cert_list_size; gnutls_x509_crt_t cert = NULL; @@ -1073,14 +1075,15 @@ error: } if (cert) gnutls_x509_crt_deinit(cert); - _ecore_con_ssl_server_shutdown_gnutls(svr); + _ecore_con_ssl_server_shutdown_gnutls(obj); return ECORE_CON_SSL_ERROR_SERVER_INIT_FAILED; } static Eina_Bool -_ecore_con_ssl_server_cafile_add_gnutls(Ecore_Con_Server *svr, +_ecore_con_ssl_server_cafile_add_gnutls(Ecore_Con_Server *obj, const char *ca_file) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); struct stat st; Eina_Iterator *it; const char *file; @@ -1113,9 +1116,10 @@ error: } static Eina_Bool -_ecore_con_ssl_server_crl_add_gnutls(Ecore_Con_Server *svr, +_ecore_con_ssl_server_crl_add_gnutls(Ecore_Con_Server *obj, const char *crl_file) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); SSL_ERROR_CHECK_GOTO_ERROR(gnutls_certificate_set_x509_crl_file(svr-cert, crl_file, GNUTLS_X509_FMT_PEM) 1); @@ -1126,9 +1130,10 @@ error: } static Eina_Bool -_ecore_con_ssl_server_privkey_add_gnutls(Ecore_Con_Server *svr, +_ecore_con_ssl_server_privkey_add_gnutls(Ecore_Con_Server *obj, const char *key_file) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); SSL_ERROR_CHECK_GOTO_ERROR(gnutls_certificate_set_x509_key_file(svr-cert, svr-cert_file, key_file, GNUTLS_X509_FMT_PEM)); @@ -1139,9 +1144,10 @@ error: } static Eina_Bool -_ecore_con_ssl_server_cert_add_gnutls(Ecore_Con_Server *svr, +_ecore_con_ssl_server_cert_add_gnutls(Ecore_Con_Server *obj, const char *cert_file) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); if (!(svr-cert_file = strdup(cert_file))) return EINA_FALSE; @@ -1149,8 +1155,9 @@ _ecore_con_ssl_server_cert_add_gnutls(Ecore_Con_Server *svr, } static Ecore_Con_Ssl_Error -_ecore_con_ssl_server_shutdown_gnutls(Ecore_Con_Server *svr) +_ecore_con_ssl_server_shutdown_gnutls(Ecore_Con_Server *obj) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); if (svr-session) { gnutls_bye(svr-session, GNUTLS_SHUT_RDWR); @@ -1195,16 +1202,17 @@ _ecore_con_ssl_server_shutdown_gnutls(Ecore_Con_Server *svr) } static int -_ecore_con_ssl_server_read_gnutls(Ecore_Con_Server *svr, +_ecore_con_ssl_server_read_gnutls(Ecore_Con_Server *obj, unsigned char *buf, int size) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); int num; if (svr-ssl_state == ECORE_CON_SSL_STATE_HANDSHAKING) { DBG(Continuing gnutls handshake); -if (!_ecore_con_ssl_server_init_gnutls(svr)) +if (!_ecore_con_ssl_server_init_gnutls(obj
[EGIT] [core/efl] efl-1.12 01/01: ecore con: Fix GnuTLS build error.
tasn pushed a commit to branch efl-1.12. http://git.enlightenment.org/core/efl.git/commit/?id=3f73ae7660328de24fa3422ec378a76af8edc764 commit 3f73ae7660328de24fa3422ec378a76af8edc764 Author: Andreas Metzler ametz...@debian.org Date: Wed Dec 3 12:07:40 2014 + ecore con: Fix GnuTLS build error. By making the respective changes on the GnuTLS side for upstream commits d9b5f192d4883193f79cd3e43ed1da52521825dc and d72f809fb874c8f14b1461949802905d41d648a1 which only take care of OpenSSL. @fix --- src/lib/ecore_con/ecore_con_ssl.c | 78 +++ 1 file changed, 46 insertions(+), 32 deletions(-) diff --git a/src/lib/ecore_con/ecore_con_ssl.c b/src/lib/ecore_con/ecore_con_ssl.c index bf63469..d31b44e 100644 --- a/src/lib/ecore_con/ecore_con_ssl.c +++ b/src/lib/ecore_con/ecore_con_ssl.c @@ -885,9 +885,10 @@ _ecore_con_ssl_shutdown_gnutls(void) } static Ecore_Con_Ssl_Error -_ecore_con_ssl_server_prepare_gnutls(Ecore_Con_Server *svr, +_ecore_con_ssl_server_prepare_gnutls(Ecore_Con_Server *obj, int ssl_type) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); int ret; if (ssl_type ECORE_CON_USE_SSL2) @@ -938,13 +939,14 @@ _ecore_con_ssl_server_prepare_gnutls(Ecore_Con_Server *svr, error: _gnutls_print_errors(svr, ECORE_CON_EVENT_SERVER_ERROR, ret); - _ecore_con_ssl_server_shutdown_gnutls(svr); + _ecore_con_ssl_server_shutdown_gnutls(obj); return ECORE_CON_SSL_ERROR_SERVER_INIT_FAILED; } static Ecore_Con_Ssl_Error -_ecore_con_ssl_server_init_gnutls(Ecore_Con_Server *svr) +_ecore_con_ssl_server_init_gnutls(Ecore_Con_Server *obj) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); const gnutls_datum_t *cert_list; unsigned int iter, cert_list_size; gnutls_x509_crt_t cert = NULL; @@ -1073,14 +1075,15 @@ error: } if (cert) gnutls_x509_crt_deinit(cert); - _ecore_con_ssl_server_shutdown_gnutls(svr); + _ecore_con_ssl_server_shutdown_gnutls(obj); return ECORE_CON_SSL_ERROR_SERVER_INIT_FAILED; } static Eina_Bool -_ecore_con_ssl_server_cafile_add_gnutls(Ecore_Con_Server *svr, +_ecore_con_ssl_server_cafile_add_gnutls(Ecore_Con_Server *obj, const char *ca_file) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); struct stat st; Eina_Iterator *it; const char *file; @@ -1113,9 +1116,10 @@ error: } static Eina_Bool -_ecore_con_ssl_server_crl_add_gnutls(Ecore_Con_Server *svr, +_ecore_con_ssl_server_crl_add_gnutls(Ecore_Con_Server *obj, const char *crl_file) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); SSL_ERROR_CHECK_GOTO_ERROR(gnutls_certificate_set_x509_crl_file(svr-cert, crl_file, GNUTLS_X509_FMT_PEM) 1); @@ -1126,9 +1130,10 @@ error: } static Eina_Bool -_ecore_con_ssl_server_privkey_add_gnutls(Ecore_Con_Server *svr, +_ecore_con_ssl_server_privkey_add_gnutls(Ecore_Con_Server *obj, const char *key_file) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); SSL_ERROR_CHECK_GOTO_ERROR(gnutls_certificate_set_x509_key_file(svr-cert, svr-cert_file, key_file, GNUTLS_X509_FMT_PEM)); @@ -1139,9 +1144,10 @@ error: } static Eina_Bool -_ecore_con_ssl_server_cert_add_gnutls(Ecore_Con_Server *svr, +_ecore_con_ssl_server_cert_add_gnutls(Ecore_Con_Server *obj, const char *cert_file) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); if (!(svr-cert_file = strdup(cert_file))) return EINA_FALSE; @@ -1149,8 +1155,9 @@ _ecore_con_ssl_server_cert_add_gnutls(Ecore_Con_Server *svr, } static Ecore_Con_Ssl_Error -_ecore_con_ssl_server_shutdown_gnutls(Ecore_Con_Server *svr) +_ecore_con_ssl_server_shutdown_gnutls(Ecore_Con_Server *obj) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); if (svr-session) { gnutls_bye(svr-session, GNUTLS_SHUT_RDWR); @@ -1195,16 +1202,17 @@ _ecore_con_ssl_server_shutdown_gnutls(Ecore_Con_Server *svr) } static int -_ecore_con_ssl_server_read_gnutls(Ecore_Con_Server *svr, +_ecore_con_ssl_server_read_gnutls(Ecore_Con_Server *obj, unsigned char *buf, int size) { + Ecore_Con_Server_Data *svr = eo_data_scope_get(obj, ECORE_CON_SERVER_CLASS); int num; if (svr-ssl_state == ECORE_CON_SSL_STATE_HANDSHAKING) { DBG(Continuing gnutls handshake); -if (!_ecore_con_ssl_server_init_gnutls(svr)) +if (!_ecore_con_ssl_server_init_gnutls(obj