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 :)

netstar, do you think it is still 'no way to fix'?

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.

Seems to be fixed by Raster's commit: 2bd98e830f51fa985cbc3a0ab2db4e759ec75354

@cederom,
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.

@cederom,
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?

It's just

@cederom,
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.

raster,
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.

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

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?

...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

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.

Another application: RazorSQL (GUI Java-based).

I consider it solved now.

It is OK for me now (after 9fd9a3b120fe).

cederom,
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

Hmm...
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.

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).

netstar,
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.

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...

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.

...and the shot of GIMP:

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.

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

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.

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:
https://gavv.github.io/articles/unix-socket-reuse/
A workaround proposed on Stackoverflow:
https://stackoverflow.com/questions/7405932/how-to-know-whether-any-process-is-bound-to-a-unix-domain-socket

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

/var/run/user/1001/.ecore/efreetd/0

Enlightenment started using startx uses it too (at least, it tries), but after a manual restart of E I see another efreetd process, using

/tmp/xdg-g5E9qA/.ecore/efreetd/0

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

/tmp/xdg-g5E9qA/.ecore/efreetd/0

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.
Backtrace:

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?

Valgrind works better on another PC, log attached.

One more backtrace of efreetd crashed:

Some changes here:

1. I removed --warn-unresolved-symbols from my LDFLAGS
2. I rebuilt all from Git with debug CFLAGS
3. I removed additional search icon dirs from E config

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:

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:

With the new revision I cannot reproduce the crash. Starting ephoto does not produce several instances of efreetd.
BUT!
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:

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:

Fixed in Meson, tested OK. Hope the new version of Meson will be released soon.

Probably fixed in Meson's master: https://github.com/mesonbuild/meson/pull/4410
I need some time to test it...

OK, I've got it.
There is a hack in the ports system, it redirects *.pc from lib to libdata during stage (and install).
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067
So, probably, we only need to put some info into the docs about the behavior change from autotools to meson.

In T8360#146698, @lauromoura wrote:

I'm not a FreeBSD user but how does other meson-based projects deal with pkg-config? Through USES = meson when porting?

Isn't it a case of patching Free BSD's own Uses/meson.mk to point to the correct directory? (The best reference I could find for it was this patch adding it https://reviews.freebsd.org/D10409)

In T8360#146695, @netstar wrote:

Hi Peter no issue with Efl on freebsd or openbsd here. I think the pc issue is best fixed by the packager or port maintainer. You could help them with that????

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

In T8360#146629, @bu5hm4n wrote:

This was always the case, also in autotools. And is also the case for linux. Our installation and build guide also states that you should use PKG_CONFIG_PATH=/usr/local/lib/pkgconfig.

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

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.

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:

bu5hm4n,
Libinotify is present in FreeBSD as port:
FreshPorts
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.

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:
https://github.com/gerbera/gerbera/commit/3cec05f3b615b768f4dc0caff7defa549b489e23

There is a thread in FreeBSD forum about porting polybar, they had libinotify problems too...
https://forums.freebsd.org/threads/polybar-i-want-to-give-it-a-try.62494/

If I remove libinotify I get another error:

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.

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.

Nothing changed adding the header.

Nothing changed adding the unistd.h header.
Anyway, there is no

environ

variable declared in system's unistd.h.
I cannot find any header with such declaration.

I confirm that this commit solved the problem.
Thanks a lot, raster!