- User Since
- Jan 6 2015, 5:06 AM (314 w, 5 d)
Tue, Dec 22
Dec 16 2020
When do you plan to push the patches to master and would they get to a next release and when is the next release planned?
I prefer that netstar test it and pushed himself. It seems that he changed my patches. Anyway, before push it should be tested :)
Jul 15 2020
netstar, do you think it is still 'no way to fix'?
Jun 18 2020
It seems that it works correctly with Lua 5.1.
If is is broken 'by design' - it would be nice to check Lua version during meson configure state and stop building with unsupported version of Lua.
May 28 2020
Seems to be fixed by Raster's commit: 2bd98e830f51fa985cbc3a0ab2db4e759ec75354
May 25 2020
May 17 2020
May 15 2020
It seems that has_header meson function is not recursive.
I could reproduce your problem creating symlinks of epoll.h in /usr/local/include/sys or in /usr/include/sys
I don't know why do you have such links (or strange CFLAGS=I/usr/local/include/libepoll-shim) but anyway it is not a standard situation. So I think that libepoll-shim package installed would not prevent correct building of EFL without epoll.
I cannot reproduce your problem on my test PC under FreeBSD 12.1.
I have libepoll-shim package installed, but during the configuration of EFL meson does not detect sys/epoll.h header. I have it installed in /usr/local/include/libepoll-shim/sys/epoll.h and I have CFLAGS=-I/usr/local/include exported, but meson does not detect it. Don't you have a symlink of this file in /usr/include for any reason?
May 14 2020
Try to build EFL and Terminology in jail with the strict minimum of other software installed. Terminology and Enlightenment from Git work fine here with EFL 1.24 on FreeBSD 11.3.
May 11 2020
If you check the code from my initial message here, you'll see that LightDM completely ignores desktop file, using his own special names for DE icon files. One more Ubuntism here. I think that you can just add a symlink.
May 10 2020
Just checked it on fresh installation - no icon is shown. The icon name is not correct.
The icon name must be enlightenment_badge-symbolic.svg and NOT just enlightenment.svg
May 3 2020
May 2 2020
Apr 26 2020
Apr 25 2020
It seems that this is a problem of profile.
I removed ~/e. and ~/.elementary directories and started E 'from scratch' - DnD was working correctly after this. When I put back my profiles - it does not work anymore.
It is NOT a problem of theme - reverting to the default one does not solve the problem.
My profiles are complex (mostly .e). How can I debug it? What profile parameters could affect the DnD behavior?
Apr 24 2020
...as about lock&remember - indeed, "current screen" option does the job, the window is correctly positioned on the second monitor.
Bug open on mozilla.org: https://bugzilla.mozilla.org/show_bug.cgi?id=1632808
Apr 23 2020
OK, thanks, Raster, I see better the difference with another DEs now.
...and even if Firefox does something wrong - it is one of the most used applications on *nix, if it has problems under E only - this situation does not improve the image of Enlightenment in 'average' user's eyes ;)
OK, let's try to position it by E. I start another app on the second plan to use as a reference point, then I start Cliqz.
Then I tell to E to remember the position of the window
Then I restart Cliqz - it is shifted exactly the same way as before, when I did not try to remember the position
Then I try to lock the position from moving on it's own
Hmm... It starts on the first monitor (laptop internal), but I locked it on the second one (HDMI connected)!
Then I close my session and reboot to LXDE to test there... Everything works as expected without any tweaks on LXDE side! The window is correctly placed on the second monitor exactly at the same place as it was closed!
I have no XFCE installed on this PC, but I used it a lot on another PC and I've never had such problem there.
If I am wrong in my parameters of remember/lock - feel free to close this task again, but I'm almost sure that the information received by Cliqz from E is not 100% correct.
Another application: RazorSQL (GUI Java-based).
Apr 20 2020
I consider it solved now.
It is OK for me now (after 9fd9a3b120fe).
I think it would be better to skip EFL 1.23 and E 0.22 and wait for (soon) release of EFL 1.24 (beta now) and E 0.24 as there is a huge problem solved in EFL 1.24 https://phab.enlightenment.org/T8490
Apr 9 2020
After this patch, once killed it does not come back.
If I try to restart it manually from command line - it silently dies after ~20 seconds.
Apr 4 2020
If I have efreetd in a frozen state with two zombie children - the following procedure unlocks the situation and brings everything into the correct state :
- chmod -x /usr/local/bin/efreetd
- kill -9 <pid of efreetd>
- chmod +x /usr/local/bin/efreetd
- Ctrl-Alt-End to restart Enlightenment
I can reproduce the mentioned behaviour (efreetd frozen after killing it) on last Git versions of Enlightenment and Efl on another PC (FreeBSD 12.1). I suppose that adding a small delay before restarting efreetd can fix it, but I cannot find a place in Efl code where I can try to add such delay for testing. I can easily reproduce the problem, so if someone propose a patch - I can test it.
I think that this is the same problem that was the reason of crashing of efreetd earlier (fixed by Raster).
Apr 2 2020
After two fixes of Raster the situation is definitely improved.
The last time I tested it on my PC where the problem was evident, I could see some problems though. Mainly, efreetd frozen with two child processes in zombie state after 'kill -9 efreetd'. It seems that if efreetd is killed, it is restarted by E too fast to be able correctly open the socket. The problem was not 100% reproducible, killing the frozen process several times I could get efreetd correctly working.
Hope to have some time this weekend to re-test it in depth and to try some tweaks. Sorry, too much work last weeks - no time for EFL.
Mar 24 2020
How can you explain the images I've sent in this ticket? The shift is present in your test EFL app but not present in GIMP. Maybe, indeed, your test is not relevant because of a problem in VBox X driver. But the problem is constantly present for me on three PC with different versions of X drivers. And the problem is neither present in QT apps, nor in GTK+ apps (nor in FLTK apps, nor in FOX apps, nor in pure X apps, ...) I don't think that all GUI toolkits fixed in their libs a known bug in FreeBSD X server ;)
raster, do you start VirtualBox using Enlightenment on host? If yes - what pointer do you use in E? Maybe there are two effects together...
Mar 23 2020
I did not check since 11/03 as nobody indicated any commit, related to this problem.
During my tests I checked with two themes - the default one and my theme, based on the default (buttons on left side of windows and some small tweaks). I did not see any difference between the two themes.
Mar 11 2020
...and the shot of GIMP:
Mar 10 2020
So, finally it builds correctly with:
cc x.c -o x pkg-config --cflags --libs elementary
I would like to see the detailed instructions about building the test tool.
After manually adding ALL include dirs of EFL as -I flags, the compiler is OK, but the linker cannot find some references:
elm_policy_set, elm_win_util_standard_add, elm_win_autodel_set, evas_object_evas_get, evas_object_rectangle_add, evas_object_color_set, evas_object_size_hint_min_set, elm_win_resize_object_add, evas_object_event_callback_add etc...
The flag -L/usr/local/lib is present, the libs are installed in /usr/local/lib/ecore, /usr/local/lib/edje, etc.
Once again, raster, I have NO problems in non-EFL apps.
It's OK for me in GIMP, no problems at all.
If I choose 'Application' options in 'Mouse Settings' of E - I have no problems in X11 neither.
I'll test your tool this evening.
Mar 9 2020
Ah, sorry, another PC with the same config (FreeBSD 11.3, OpenGL, Nvidia)
...and I can reproduce this problem on another post with the same configuration.
If it helps - I'm using OpenGL acceleration with NVIDIA driver.
I am not sure that it is really FreBSD specific, but I cannot test on Linux now.
Exact, FreeBSD 11.3 and X11
Feb 16 2020
I've just tested the last versions of EFL and E from git.
Everything works fine till I kill -9 efreetd process (I think that this situation is rather simple to reproduce). Then I have efreetd restarted, but in a strange state, not responding, and two zombie processes (update cache and desktop). Repeating multiple kill -9, finally I get a working efreetd, restarting E reconnects it to efreetd.
Feb 14 2020
I've just tested the new version on my test laptop. The situation is definitely better!! :)
I have only one instance of efreetd running, E communicates correctly with this instance, the cache is correctly updated. Restart of E does not change this situation - everything continues to work correctly.
BUT!! There is still one problem. If I kill efreetd process - it is restarted automatically, but then sometimes (not always!) it freezes, producing two or three zombies. If I kill it again - a new efreetd is started, but then it crashes (or exits) immediately and there is no new instances created. If I restart E or start another EFL app now - everything comes back to the correct situation. It seems that killing efreetd (or crashing it) leaves the socket in place, so new instance has troubles to bind to it.
The thing I don't understand - if the socket is not deleted and not unlinked - how can the situation come back to the normal state?? As I understand, with the current logic, a killed (or crashed) efreetd will prevent another instances to work...
As about deleting working socket - I cannot produce any strange effects with my test program. If I delete a working socket - the server and the client continue working as they worked before deletion, a new instance of server creates a new socket, a new instance of client correctly communicates with the new server (so I can have two pairs client-server working correctly using the same socket name, but different FDs).
I could reproduce blocking access with my test program, but not in 100% of cases.
The key point - unlink active socket and rebind it. Sometimes the old server and the client connected to the old server continue working correctly, sometimes, stopping the second server blocks the communications with the first one.
Anyway, it seems that incorrect unlink is the root of the problem as multiple servers on the same socket is definitely not a good configuration. I see the conditional unlink in _efl_net_server_unix_bind of efl_net_server_unix, but I don't understand how and where pd->unlink_before_bind is set (it seems that _efl_net_server_unix_unlink_before_bind_set is used for it, but I don't see it used in EFL/E code).
There is a good article on the subject:
A workaround proposed on Stackoverflow:
Feb 13 2020
It seems that on manual restart of Enlightenment (Ctrl-Alt-End), EFL does not read correctly XDG_RUNTIME_DIR.
The variable is set in .zshrc, manually started efreetd uses
Enlightenment started using startx uses it too (at least, it tries), but after a manual restart of E I see another efreetd process, using
and in the same time the first efreetd process becomes frozen, the BT is the last I've posted (efl_net_accept4).
According to sockstat, Enlightenment is connected to
So, the new version does not crash anymore, it freezes.
Started from command-line, after some time running efreetd does not respond on Ctrl-C neither SIGTERM.
Feb 12 2020
well i put in a "don't crash" workaround to the crash above...
Thanks! I don't see any patch attached, is it in master?
Feb 11 2020
Valgrind works better on another PC, log attached.
One more backtrace of efreetd crashed:
Feb 6 2020
Some changes here:
- I removed --warn-unresolved-symbols from my LDFLAGS
- I rebuilt all from Git with debug CFLAGS
- I removed additional search icon dirs from E config
Dec 26 2019
Another interesting log records from /tmp/efreetd_host-peter.bimp.local_xxxxxx.log:
BTW, on a PC where I have the problem, /tmp is filled by efreetd_host-peter.bimp.local_djTpjB.log with the following content repeating continuously:
Dec 23 2019
Dec 7 2019
Status of sockets, having only one instance of efreetd started (PID 10298):
% sockstat -u | grep efreet peter efreetd 10298 26 stream -> /var/run/dbus/system_bus_socket peter efreetd 10298 29 stream /tmp/xdg-9U9z02/.ecore/efreetd/0 peter efreetd 10298 995 stream/tmp/xdg-9U9z02/.ecore/efreetd/0 peter enlightenm 9403 35 stream -> /tmp/xdg-9U9z02/.ecore/efreetd/0
Is it normal that there are two lines for the same PID of efreetd (10298) and the same socket (/tmp/...) with different FDs - 29 and 995?
Sure, we are going the good direction, thank you :)
If I kill ALL efreetd processes and start ephoto - I finish with one or two efreetd processes, consuming 100% of CPU.
The console log:
If I attach a debugger - I see the same backtrace that I've mentioned in the previous post.
With the new revision I cannot reproduce the crash. Starting ephoto does not produce several instances of efreetd.
If I manually start many efreetd instances (just 'efreetd' in terminology, without arguments) - at one moment I see multiple instances started, consuming 100% of CPU:
9512 peter 92 20 42024 31416 T 0.0 0.4 0:51.17 /usr/local/bin/efreetd 9590 peter 120 19 42024 32584 R 99.9 0.4 7:49.05 /usr/local/bin/efreetd 9607 peter 120 19 42024 32584 R 96.9 0.4 7:48.64 /usr/local/bin/efreetd 9624 peter 52 19 42024 32568 S 0.0 0.4 0:00.68 /usr/local/bin/efreetd
The processes don't respond on SIGTERM.
If I attach a debugger - I see the following backtrace:
(lldb) bt * thread #1, name = 'efreetd' * frame #0: 0x00000008005c805a libc.so.7`_select + 10 frame #1: 0x00000008003f6522 libthr.so.3`___lldb_unnamed_symbol44$$libthr.so.3 + 66 frame #2: 0x000000080033126a libecore.so.1`_ecore_main_select(obj=0x00004000000002fe, pd=0x00000008016130b0, timeout=<unavailable>) at ecore_main.c:1859 frame #3: 0x000000080032ffa1 libecore.so.1`_ecore_main_loop_iterate_internal(obj=0x00004000000002fe, pd=0x00000008016130b0, once_only=0) at ecore_main.c:2461 frame #4: 0x000000080033012d libecore.so.1`_ecore_main_loop_begin(obj=0x00004000000002fe, pd=0x00000008016130b0) at ecore_main.c:1200 frame #5: 0x00000008003356b6 libecore.so.1`_efl_loop_begin(obj=0x00004000000002fe, pd=0x00000008016130b0) at efl_loop.c:57 frame #6: 0x0000000800335136 libecore.so.1`efl_loop_begin(obj=0x00004000000002fe) at efl_loop.eo.c:28 frame #7: 0x0000000800330223 libecore.so.1`ecore_main_loop_begin at ecore_main.c:1285 frame #8: 0x000000000020449c efreetd`main(argc=<unavailable>, argv=<unavailable>) at efreetd.c:82 frame #9: 0x000000000020411b efreetd`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76
Nothing is shown in command line.
The cache is still not updated, Enlightenment shows an error on start: 'Efreetd cannot be connected to'. The socket '=0' is present in /tmp/xdg-9U9z02/.ecore/efreetd
When I start ephoto from terminology I see the following output in console:
There are no previews in ephoto.
Dec 6 2019
It's definitely a step ahead, I don't see multiple instances of efreetd started.
But the problem of SIGSEGV is still here.
To produce it:
- start E (startup error - cannot connect to efreetd)
- only one instance of efreetd is present
- start ephoto - still one instance of efreetd is present
- start efreetd from command line - it exits immediately
- start efreetd several times from command line - it exits after a 1-2 sec delay
- the only started efreetd process is consuming 100% of CPU
- start efreetd several times from command line - one of them is crashed with the same error as before, the same coredump, zeros in 'value'.
I could catch the same crash:
Nov 8 2019
Fixed in Meson, tested OK. Hope the new version of Meson will be released soon.
Nov 5 2019
Probably fixed in Meson's master: https://github.com/mesonbuild/meson/pull/4410
I need some time to test it...
Oct 31 2019
OK, I've got it.
There is a hack in the ports system, it redirects *.pc from lib to libdata during stage (and install).
So, probably, we only need to put some info into the docs about the behavior change from autotools to meson.
Right now, after install, EFL libs are not available for building software under FreeBSD. Even Enlightenment does not build. I think it is very bad. Asking a user who wants to build Enlightenment to add a custom path for pkg config is a bad idea. It is a regression passing to meson build from autotools. If it can be solved on EFL level - IMHO it should be solved. If you consider that it should be fixed on meson level - try to ask it to meson devs.
Anyway, it must be patched in FreeBSD port, if not - EFL 1.23 will not be accepted in ports tree. The standard path for *.pc files in FreeBSD - /usr/local/libdata/pkgconfig
Oct 11 2019
Aug 7 2019
Me too, sometimes I have problems with window switcher. It does not show the list, but only the next window icon & name. But I don't need to restart the session, the next invoking the switcher is normally correct.
And UI does not hang for me with the last versions of E/EFL.
I don't see the segmentation fault closing emixer on my laptop.
FreeBSD 11.2-RELEASE-p9 Enlightenment 0.23.0.alpha EFL 1.22.2
Apr 15 2019
cederom, you should begin with full uninstall E and EFL, port version of EFL is really outdated. Then you should download the last versions from enlightenment.org (or checkout from Enlightenment git) and build both EFL and E from sources.
I'm on git versions (dated some months ago) on FreeBSD 11.2. It's stable, I'm using it every day ~12hrs by day without freezes. I tested everything on FreeBSD 12 too without problems.
I did not (yet) tested the last released version of EFL.
You can ask for help in maillist if you have problems with build.
Mar 3 2019
OK, with if sys_linux == true it works better ;)
I could build EFL, Enlightenment and Terminology, everything works fine on FreeBSD 12.
So, I took my test PC (FreeBSD 12) , I've uninstaled all EFL stuff, I've cloned EFL repo and I've patched src/lib/ecore_file/meson.build like in Diff 19894.
Then I've declared the following environment variables:
Libinotify is present in FreeBSD as port:
You can see the limitations of this library in pkg-message section of this page. This library is used for 50+ ports and they manage to use it correctly. I referenced two projects that added support of FreeBSD's inotify without hacks: polybar, gerbera It does not seem to me that they needed to work hard to add this support ;) Anyway, if EFL cannot use it correctly under FreeBSD - we need a meson option to disable it without removing headers.
Make sure you remove any package that is including inotify headers because the EFL build will see these headers and assume we can use inotify but we cannot use it on FreeBSD. If you have inotify.h in /usr/local/include or elsewhere, remove it, or the package that is pulling in this bogus header.
Mar 2 2019
Sorry, netstar, the problem explained in this post is still present, building with your options.
Errors about inotify_* changed to warnings (will it run correctly after build?)
...and a commit to add FreeBSD libinotify support to gerbera:
There is a thread in FreeBSD forum about porting polybar, they had libinotify problems too...
If I remove libinotify I get another error:
Mar 1 2019
FAILED: src/bin/efreet/efreet_desktop_cache_create cc -o src/bin/efreet/efreet_desktop_cache_create 'src/bin/efreet/d57513e@@efreet_desktop_cache_create@exe/efreet_desktop_cache_create.c.o' -Wl,--as-nee ed -Wl,-O1 -O2 -ffast-math -march=native -g -ggdb3 -Wl,--start-group src/lib/efreet/libefreet.so.1.22.0 src/lib/eina/libeina.so.1.22.0 src/lib/eo/libeo. o.1.22.0 src/lib/efl/libefl.so.1.22.0 src/lib/ecore/libecore.so.1.22.0 src/lib/eet/libeet.so.1.22.0 src/lib/emile/libemile.so.1.22.0 src/lib/ecore_file/ ibecore_file.so.1.22.0 -ldl /usr/local/lib/libunwind-generic.so /usr/local/lib/libunwind.so -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -Wl,--end- roup -pthread '-Wl,-rpath,$ORIGIN/../../lib/efreet:$ORIGIN/../../lib/eina:$ORIGIN/../../lib/eo:$ORIGIN/../../lib/efl:$ORIGIN/../../lib/eet:$ORIGIN/../.. lib/emile:$ORIGIN/../../static_libs/lz4:$ORIGIN/../../lib/ecore:$ORIGIN/../../static_libs/buildsystem:$ORIGIN/../../lib/ecore_con:$ORIGIN/../../lib/eldb s:$ORIGIN/../../static_libs/http-parser:$ORIGIN/../../lib/ecore_file:$ORIGIN/../../lib/ecore_ipc' -Wl,-rpath-link,/usr/home/peter/Programming/Prog-EFL/t st-efl/efl/build/src/lib/efreet:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/eina:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/b ild/src/lib/eo:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/efl:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/eet:/ sr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/emile:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/static_libs/lz4:/usr/hom /peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/ecore:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/static_libs/buildsystem:/usr/ho e/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/ecore_con:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/eldbus:/usr/home/peter Programming/Prog-EFL/test-efl/efl/build/src/static_libs/http-parser:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/ecore_file:/usr/home peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/ecore_ipc src/lib/ecore_file/libecore_file.so.1.22.0: undefined reference to `inotify_add_watch' src/lib/ecore_file/libecore_file.so.1.22.0: undefined reference to `inotify_init' src/lib/ecore_file/libecore_file.so.1.22.0: undefined reference to `inotify_rm_watch' cc: error: linker command failed with exit code 1 (use -v to see invocation)
Do you have libinotify installed?
config command was:
meson setup --wipe build -Decore-imf-loaders-disabler=xim,scim,ibus -Db_lundef=false \ -Dxinput22=true -Dbuffer=false -Dfb=false -Ddrm=false \ -Dtslib=false -Dharfbuzz=true -Dwl=false -Dnetwork-backend=connman \ -Devas-loaders-disabler= -Dbindings=cxx,luajit -Dbuild-examples=false \ -Dsystemd=false -Deeze=false
I used the following command to configure the build:
Sorry, the workaround does not work.
I deleted build directory and reconfigured meson with the proposed option.
The build still fails.
[453/3977] Linking target src/lib/ecore/libecore.so.1.22.0.
Feb 28 2019
vtorri, I don't think it's related as in the bug they discuss a runtime problem, but we have a build time problem. I've just declared the variable as 'extern' and the build passed, E works correctly with the compiled version of EFL (I'm using it since 2 days). BUT, I don't know if somewhere this function was used, so MAYBE we are concerned by 220103 bug too.
Feb 27 2019
Nothing changed adding the header.
Nothing changed adding the unistd.h header.
Anyway, there is no
variable declared in system's unistd.h.
I cannot find any header with such declaration.