I don't think this is valid now. dragonfly dropped pulseaudio support.
@ProhtMeyhet Still valid? If not can you close this?
Jun 15 2020
Jun 12 2020
Thank you @stefan_schmidt please go ahead and push this way thank you for your time and checking out :-)
@cederom if you want proper credit for this patch I would need a git format patch.
May 29 2020
Back port this?
This is fixed by
May 28 2020
Seems to be fixed by Raster's commit: 2bd98e830f51fa985cbc3a0ab2db4e759ec75354
May 27 2020
mhm, give me time until tomorrow. I think eina should drag in -lm for everyone that uses it. as eina includes math.h. Will check and investigate tomorrow.
diff --git a/src/lib/eo/meson.build b/src/lib/eo/meson.build index 9cd3377..3a4e1e9 100644 --- a/src/lib/eo/meson.build +++ b/src/lib/eo/meson.build @@ -2,6 +2,10 @@ eo_deps =  eo_pub_deps = [eina] eo_ext_deps = [valgrind, dl, execinfo]
May 25 2020
fixed it... use current sched when SCHED_BATCH and IDLE not available.
I think, it is safe to
May 17 2020
May 15 2020
Thank you @Peter2121.. I had to modify one header that was linux specific in order to make VNC server work:
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?
I can confirm that this is the EFL build time configuration issue. Older EFL build works fine with Terminology 1.7.0. I will looks into that epoll stuff in a free moment. Thank you!! :-)
epoll-shim is required by other packages and cannot be removed from the system. If presence of that package impacts Terminology then terminology build scripts need fix.
May 14 2020
Thank you for your feedback that it works for you, this is valuable input.
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.
Your terminology 1.6.0 is probably linked with an other version of efl, one that was compiled when epoll-shim wasn't installed.
You cannot build a port package with all this other software installed.
Did you build EFL with those flags?
The problem with Terminology 1.7.0 is not fixed, exactly the same setup and 1.6.0 works fine, I cannot remove libepoll-shim from system because other applications depend on it. Will report a working solution if I find one. Thanks for your quick response :-)
meson build -Dsystemd=false -Deeze=false
Well, it looks like I am updating the port, because no one did that so far ;-)
Please advise the FreeBSD port maintainers not to build with wayland support . It does not work, it merely builds.
Follow that guide - remove the libepoll-shim package as suggested by @arrowdodger
These goes the port updates tickets and whole ports sources / patches are there too:
That sounds about right @arrowdodger
@cederom Are you building in unclean environment? It might be that build system picks stuff from libepoll-shim FreeBSD package.
I'm runnning E 24.0 and EFL 1.24 and Terminology 1.7.0 on FreeBSD 12.1 and OpenBSD 6.7-beta
Hey @netstar :-) Which version of Terminology on which E and EFL?
I'm running terminology fine here on OpenBSD and FreeBSD.
Can you show the build options for EFL? There should be no reference to epoll
There are some changes in src/bin/termpty.c but I don't see why it should fail.
Sure thing, I am porting EFL+E to FreeBSD so no problem with building and patching :-)
Would it be possible for you to compile terminology 1.6.0 with the same efl version?
Hello @billiob and thank you for quick response :-)
If you create a new terminal from the menu, is it better?
What if you focus/unfocus the window?
EFL builds fine now with new Wayland, thank you! Need to tune some stuff on Enlightenment side to make it work with Wayland. Will send updates when ready! :-)
May 13 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
Apr 21 2020
@netstar Ahh ok :) I just wanted to double check that there was nothing you needed me to do for this ticket. Thanks for the patch btw :) Yes, in the future if there is anything that the *bsd* people require from me, please let me know.
None any more.
@netstar Just to clarify ... what work is needed here from me ??
@cederom I see Zero good reason to use obsolete wl code .. In fact, I highly discourage it's usage, so much to the point that I deprecated those libraries a while ago ;) In theory, it may be possible to use obsolete in order to run E-WL ... but I cannot speak for it's actual usefulness. YMMV of course, but as I am sitting here writing this, I cannot help but shake my head and scream NO! Don't do it....
Just to be clear - EFL builds fine with wl-obsolete enabled.. but the new Enlightenment requires wl2 (ecore_wl2 that is provided with wl build switch) - I have question is there any reason to use wl-obsolete and would that allow running Enlightenment on Wayland? I did not manage to do it and this is why I am focusing on wl / ecore_wl2 at the moment :-)
Regarding there "linuxism" includes and DMA stuff there is Greg V that knows the stuff and below is his response. On the other hand @netstar I simply commented out the includes and code with linux stuff and EFL build successfully. That may indicate we are one step from running WL2 on FreeBSD :-)
@cederom on Linux there are guides in the "docs" section on enlightenment.org. As far as FreeBSD is concerned, it might be some time yet.
meson -Deeze=false -Dv4l2=false -Dfb=false -Ddrm=false -Dwl=true -Dsystemd=false build
Thank you :-) Is there any reference / wiki on how to run E on Wayland? This seems a hot topic right now :-)
@cederom Well, the work on ecore_wl2 porting would be good for EFL wayland Client apps (ie: running Terminology in Weston, etc). The work of fixing eeze to use DEVD would be needed for running the Enlightenment Wayland compositor.
That is soo cool @devilhorns thank you for your feedback and support! I may take this part with support from the FreeBSD team.. in my free time.. which is a bit short until 202008.. but the new version is already working on my machine using X11 so step by step we can do that :-)
@cederom I'm glad to see people are porting to *bsd. With regard to eeze using udev (and thus not portable), if someone would like to submit patches to make eeze use whatever *bsd uses for devices, then that would be great !! In all honesty, the *bsd port should not really use deprecated ecore_wl, ecore_drm libraries. Those are terribly old, have a few flaws, are unmaintained, and have since been replaced w/ ecore_wl2 & ecore_drm2. Also, if someone would like to provide patches for ecore_wl2 to support *bsd, please don't hesitate to submit them.
Hello and thank you for quick response :-)
Can you please specify your build arguments to build EFL with wayland support on FreeBSD?
Apr 20 2020
Can you be more specific about what is causing the building to fail ? I don't have access to FreeBSD, so any extra info you can provide to help isolate where exactly the build is breaking would be a great help !!
Hello @Peter2121 and thank you for the hint! I also observed this efreetd problem and I am more than happy that it is resolved by now :-)
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 19 2020
I am working on EFL (1.20.7 ->1.23.3) and Enlightenment (0.22.4 -> 0.23.1) upgrade on FreeBSD. Problem is fixed in new release. Things are almost ready and will show up soon :-)
Apr 17 2020
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.
@Peter2121 src/bin/efreet/efreet_cache.c _cb_server_del() sets up a timer to run in 0.5 sec to then run _cb_server_reconnect() which calls _ipc_launch() which launches the new efreetd. so there is already a 0.5 sec delay there... but actually only if it has tried to launch in the last 0.5 sec..
That is weird.
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.
I use FreeBSD E for my main workstation. I haven't seen an efreetd.core file for a LONG time.
Apr 1 2020
Mar 31 2020
I'm using Debian and X and Simotek's Ice theme.
Mar 24 2020
i can't explain why. i can't reproduce. i am just saying the issue i see is not related to efl. it's universal.
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 ;)
yes. host run e too, but the pointer inside vbox is emulated by vbox. it's drawn/rendered internally - you can tell because the pointer gets clipped by the framebuffer boundaries inside vbox and doesn't overlay the window/fb bounds. so host poointer and host wm doesn't matter... but the fact i see pointer problems/bugs in vbox with fbsd makes me think there is some issue there that is fbsd related here in x and/or vbox drivers in fbsd. ...
raster, do you start VirtualBox using Enlightenment on host? If yes - what pointer do you use in E? Maybe there are two effects together...
well i still am as above. in vbox + x11 + fbsd there is a definite bug in xorg or vbox where the pointer is offset but it applies to all pointers, not just e. i otherwise don't see the bug. 2 themes (default or the new flat one i am working on). i can't go fix something i can't see and investigate...