Page MenuHomePhabricator

Peter2121 (Peter TKATCHENKO)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Monday

  • Clear sailing ahead.

User Details

User Since
Jan 6 2015, 5:06 AM (286 w, 3 d)
Availability
Available

Recent Activity

Thu, Jun 18

Peter2121 added a comment to T8758: Cannot build EFL with -Dlua-interpreter=lua.

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.

Thu, Jun 18, 4:24 AM
Peter2121 created T8758: Cannot build EFL with -Dlua-interpreter=lua.
Thu, Jun 18, 1:53 AM

May 28 2020

Peter2121 closed T8738: Cannot build Enlightenment as Resolved.

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

May 28 2020, 2:47 PM · E on FreeBSD
Peter2121 created T8738: Cannot build Enlightenment.
May 28 2020, 2:06 PM · E on FreeBSD

May 25 2020

Peter2121 triaged T8733: FreeBSD build failed as High priority.
May 25 2020, 12:40 AM · E on FreeBSD

May 17 2020

Peter2121 added a comment to T8716: Terminology 1.7.0 no input reaction to keystrokes.
May 17 2020, 8:26 AM · E on FreeBSD, Terminology

May 15 2020

Peter2121 added a comment to T8716: Terminology 1.7.0 no input reaction to keystrokes.

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

May 15 2020, 10:17 AM · E on FreeBSD, Terminology
Peter2121 created T8721: Additional link option needed.
May 15 2020, 9:56 AM · efl, E on FreeBSD
Peter2121 added a comment to T8716: Terminology 1.7.0 no input reaction to keystrokes.

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

May 15 2020, 9:51 AM · E on FreeBSD, Terminology
Peter2121 added a comment to T8716: Terminology 1.7.0 no input reaction to keystrokes.

It's just

May 15 2020, 4:44 AM · E on FreeBSD, Terminology

May 14 2020

Peter2121 added a comment to T8716: Terminology 1.7.0 no input reaction to keystrokes.

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

May 14 2020, 1:59 PM · E on FreeBSD, Terminology

May 11 2020

Peter2121 added a comment to T8695: Enlightenment SVG icon.

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.

May 11 2020, 12:01 AM

May 10 2020

Peter2121 reopened T8695: Enlightenment SVG icon as "Open".

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 10 2020, 1:22 PM

May 3 2020

Peter2121 created T8695: Enlightenment SVG icon.
May 3 2020, 5:14 AM

May 2 2020

Peter2121 created T8693: Cannot select text on multiple pages.
May 2 2020, 4:43 AM · Terminology

Apr 26 2020

Peter2121 created T8686: Cannot add Ctrl-Enter binding.
Apr 26 2020, 12:07 PM · Terminology

Apr 25 2020

Peter2121 updated subscribers of T8681: Drag-n-Drop does not work in EFM.
Apr 25 2020, 5:13 AM · E on FreeBSD, enlightenment-git
Peter2121 added a comment to T8681: Drag-n-Drop does not work in EFM.

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 25 2020, 5:12 AM · E on FreeBSD, enlightenment-git

Apr 24 2020

Peter2121 renamed T8681: Drag-n-Drop does not work in EFM from Drad-n-Drop does not work in EFM to Drag-n-Drop does not work in EFM.
Apr 24 2020, 6:57 AM · E on FreeBSD, enlightenment-git
Peter2121 triaged T8681: Drag-n-Drop does not work in EFM as High priority.
Apr 24 2020, 6:56 AM · E on FreeBSD, enlightenment-git
Peter2121 added a comment to T8679: Some apps have wrong position on startup.

...as about lock&remember - indeed, "current screen" option does the job, the window is correctly positioned on the second monitor.

Apr 24 2020, 6:52 AM · enlightenment-git
Peter2121 added a comment to T8679: Some apps have wrong position on startup.

Bug open on mozilla.org: https://bugzilla.mozilla.org/show_bug.cgi?id=1632808

Apr 24 2020, 5:26 AM · enlightenment-git
Peter2121 triaged T8680: Main menu partially hidden as Normal priority.
Apr 24 2020, 1:20 AM · enlightenment-git

Apr 23 2020

Peter2121 added a comment to T8679: Some apps have wrong position on startup.

OK, thanks, Raster, I see better the difference with another DEs now.

Apr 23 2020, 2:47 PM · enlightenment-git
Peter2121 added a comment to T8679: Some apps have wrong position on startup.

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

Apr 23 2020, 12:12 PM · enlightenment-git
Peter2121 reopened T8679: Some apps have wrong position on startup as "Open".

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.

Apr 23 2020, 11:34 AM · enlightenment-git
Peter2121 added a comment to T8679: Some apps have wrong position on startup.

Another application: RazorSQL (GUI Java-based).

Apr 23 2020, 1:09 AM · enlightenment-git
Peter2121 triaged T8679: Some apps have wrong position on startup as Normal priority.
Apr 23 2020, 1:04 AM · enlightenment-git

Apr 20 2020

Peter2121 triaged T8667: Double click in EFL file selector as Normal priority.
Apr 20 2020, 8:16 AM
Peter2121 closed T8490: efreetd: FreeBSD segfault. as Resolved.

I consider it solved now.

Apr 20 2020, 12:38 AM · E on FreeBSD, efl (efl-1.24)
Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

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

Apr 20 2020, 12:37 AM · E on FreeBSD, efl (efl-1.24)
Peter2121 added a comment to T7803: E 0.22.4 all X UI hangs on FreeBSD.

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

Apr 20 2020, 12:35 AM · E on FreeBSD, enlightenment20, enlightenment-git

Apr 9 2020

Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

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.

Apr 9 2020, 1:03 PM · E on FreeBSD, efl (efl-1.24)

Apr 4 2020

Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

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
Apr 4 2020, 1:43 PM · E on FreeBSD, efl (efl-1.24)
Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

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 4 2020, 1:32 PM · E on FreeBSD, efl (efl-1.24)

Apr 2 2020

Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

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.

Apr 2 2020, 12:17 PM · E on FreeBSD, efl (efl-1.24)

Mar 24 2020

Peter2121 added a comment to T8622: Mouse pointer shifted ~10px.

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

Mar 24 2020, 5:35 AM · E on FreeBSD, enlightenment-git
Peter2121 added a comment to T8622: Mouse pointer shifted ~10px.

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 24 2020, 3:23 AM · E on FreeBSD, enlightenment-git

Mar 23 2020

Peter2121 added a comment to T8622: Mouse pointer shifted ~10px.

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 23 2020, 10:22 AM · E on FreeBSD, enlightenment-git

Mar 11 2020

Peter2121 added a comment to T8622: Mouse pointer shifted ~10px.

...and the shot of GIMP:

Mar 11 2020, 1:44 AM · E on FreeBSD, enlightenment-git

Mar 10 2020

Peter2121 added a comment to T8622: Mouse pointer shifted ~10px.

So, finally it builds correctly with:
cc x.c -o x pkg-config --cflags --libs elementary

Mar 10 2020, 12:46 PM · E on FreeBSD, enlightenment-git
Peter2121 added a comment to T8622: Mouse pointer shifted ~10px.

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.

Mar 10 2020, 12:35 PM · E on FreeBSD, enlightenment-git
Peter2121 added a comment to T8622: Mouse pointer shifted ~10px.

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 10 2020, 4:33 AM · E on FreeBSD, enlightenment-git

Mar 9 2020

Peter2121 added a comment to T8622: Mouse pointer shifted ~10px.

Ah, sorry, another PC with the same config (FreeBSD 11.3, OpenGL, Nvidia)

Mar 9 2020, 12:50 PM · E on FreeBSD, enlightenment-git
Peter2121 added a comment to T8622: Mouse pointer shifted ~10px.

...and I can reproduce this problem on another post with the same configuration.

Mar 9 2020, 9:25 AM · E on FreeBSD, enlightenment-git
Peter2121 added a comment to T8622: Mouse pointer shifted ~10px.

If it helps - I'm using OpenGL acceleration with NVIDIA driver.

Mar 9 2020, 9:23 AM · E on FreeBSD, enlightenment-git
Peter2121 added a comment to T8622: Mouse pointer shifted ~10px.

I am not sure that it is really FreBSD specific, but I cannot test on Linux now.

Mar 9 2020, 8:19 AM · E on FreeBSD, enlightenment-git
Peter2121 added a comment to T8622: Mouse pointer shifted ~10px.

Exact, FreeBSD 11.3 and X11

Mar 9 2020, 8:09 AM · E on FreeBSD, enlightenment-git
Peter2121 triaged T8622: Mouse pointer shifted ~10px as High priority.
Mar 9 2020, 6:49 AM · E on FreeBSD, enlightenment-git

Feb 16 2020

Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

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 16 2020, 9:52 AM · E on FreeBSD, efl (efl-1.24)

Feb 14 2020

Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

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

Feb 14 2020, 6:22 AM · E on FreeBSD, efl (efl-1.24)
Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

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

Feb 14 2020, 2:27 AM · E on FreeBSD, efl (efl-1.24)

Feb 13 2020

Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

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
Feb 13 2020, 6:29 AM · E on FreeBSD, efl (efl-1.24)
Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

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:

Feb 13 2020, 2:08 AM · E on FreeBSD, efl (efl-1.24)

Feb 12 2020

Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

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 12 2020, 2:02 AM · E on FreeBSD, efl (efl-1.24)

Feb 11 2020

Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

Valgrind works better on another PC, log attached.

Feb 11 2020, 8:04 AM · E on FreeBSD, efl (efl-1.24)
Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

One more backtrace of efreetd crashed:

Feb 11 2020, 1:04 AM · E on FreeBSD, efl (efl-1.24)

Feb 6 2020

Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

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
Feb 6 2020, 5:40 AM · E on FreeBSD, efl (efl-1.24)

Dec 26 2019

Peter2121 added a comment to D10825: eo: do not free these values here.

Another interesting log records from /tmp/efreetd_host-peter.bimp.local_xxxxxx.log:

Dec 26 2019, 6:43 AM · DO NOT MERGE, efl
Peter2121 added a comment to D10825: eo: do not free these values here.

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 26 2019, 6:38 AM · DO NOT MERGE, efl

Dec 23 2019

Peter2121 created T8543: Cannot build EFL after FreeBSD upgrade.
Dec 23 2019, 2:05 PM · E on FreeBSD

Dec 7 2019

Peter2121 added a comment to D10825: eo: do not free these values here.

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?

Dec 7 2019, 8:43 AM · DO NOT MERGE, efl
Peter2121 added a comment to D10825: eo: do not free these values here.

Sure, we are going the good direction, thank you :)

Dec 7 2019, 7:39 AM · DO NOT MERGE, efl
Peter2121 added a comment to D10825: eo: do not free these values here.

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.

Dec 7 2019, 6:42 AM · DO NOT MERGE, efl
Peter2121 requested changes to D10825: eo: do not free these values here.

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:


There are no previews in ephoto.

Dec 7 2019, 6:32 AM · DO NOT MERGE, efl

Dec 6 2019

Peter2121 requested changes to D10825: eo: do not free these values here.

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'.
Dec 6 2019, 12:38 PM · DO NOT MERGE, efl
Peter2121 added a comment to T8490: efreetd: FreeBSD segfault..

I could catch the same crash:

Dec 6 2019, 8:58 AM · E on FreeBSD, efl (efl-1.24)

Nov 8 2019

Peter2121 closed T8360: Error building EFL applications on FreeBSD with default settings as Resolved.

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

Nov 8 2019, 2:28 PM · E on FreeBSD

Nov 5 2019

Peter2121 added a comment to T8360: Error building EFL applications on FreeBSD with default settings.

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

Nov 5 2019, 10:28 AM · E on FreeBSD

Oct 31 2019

Peter2121 added a comment to T8360: Error building EFL applications on FreeBSD with default settings.

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.

Oct 31 2019, 2:51 PM · E on FreeBSD
Peter2121 added a comment to T8360: Error building EFL applications on FreeBSD with default settings.

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)

Oct 31 2019, 2:12 PM · E on FreeBSD
Peter2121 added a comment to T8360: Error building EFL applications on FreeBSD with default settings.

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

Oct 31 2019, 1:06 PM · E on FreeBSD
Peter2121 added a comment to T8360: Error building EFL applications on FreeBSD with default settings.

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 31 2019, 7:19 AM · E on FreeBSD
Peter2121 added a comment to T8360: Error building EFL applications on FreeBSD with default settings.

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.

Oct 31 2019, 6:07 AM · E on FreeBSD

Oct 11 2019

Peter2121 created T8360: Error building EFL applications on FreeBSD with default settings.
Oct 11 2019, 2:03 PM · E on FreeBSD

Aug 7 2019

Peter2121 added a comment to T7803: E 0.22.4 all X UI hangs on FreeBSD.

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.

Aug 7 2019, 4:42 AM · E on FreeBSD, enlightenment20, enlightenment-git
Peter2121 added a comment to T8116: emixer - empty display, crashes on close.

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

Aug 7 2019, 1:42 AM · enlightenment-git, E on FreeBSD

Apr 15 2019

Peter2121 added a comment to T7803: E 0.22.4 all X UI hangs on FreeBSD.

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.

Apr 15 2019, 7:46 AM · E on FreeBSD, enlightenment20, enlightenment-git

Mar 3 2019

Peter2121 added a comment to T7710: Impossible to build EFL on FreeBSD.

OK, with if sys_linux == true it works better ;)
I could build EFL, Enlightenment and Terminology, everything works fine on FreeBSD 12.

Mar 3 2019, 1:27 PM · efl (efl-1.22)
Peter2121 added a comment to T7710: Impossible to build EFL on FreeBSD.

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:

Mar 3 2019, 11:50 AM · efl (efl-1.22)
Peter2121 added a comment to T7710: Impossible to build EFL on FreeBSD.

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.

Mar 3 2019, 7:14 AM · efl (efl-1.22)
Peter2121 added a comment to T7710: Impossible to build EFL on FreeBSD.

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 3 2019, 5:06 AM · efl (efl-1.22)

Mar 2 2019

Peter2121 reopened T7710: Impossible to build EFL on FreeBSD as "Open".

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

Mar 2 2019, 2:27 PM · efl (efl-1.22)
Peter2121 added a comment to T7710: Impossible to build EFL on FreeBSD.

...and a commit to add FreeBSD libinotify support to gerbera:
https://github.com/gerbera/gerbera/commit/3cec05f3b615b768f4dc0caff7defa549b489e23

Mar 2 2019, 5:16 AM · efl (efl-1.22)
Peter2121 added a comment to T7710: Impossible to build EFL on FreeBSD.

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/

Mar 2 2019, 5:12 AM · efl (efl-1.22)
Peter2121 added a comment to T7710: Impossible to build EFL on FreeBSD.

If I remove libinotify I get another error:

Mar 2 2019, 4:49 AM · efl (efl-1.22)

Mar 1 2019

Peter2121 added a comment to T7710: Impossible to build EFL on FreeBSD.
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
Mar 1 2019, 12:47 PM · efl (efl-1.22)
Peter2121 added a comment to T7710: Impossible to build EFL on FreeBSD.

I used the following command to configure the build:

Mar 1 2019, 9:05 AM · efl (efl-1.22)
Peter2121 added a comment to T7710: Impossible to build EFL on FreeBSD.

Sorry, the workaround does not work.
I deleted build directory and reconfigured meson with the proposed option.
The build still fails.

Mar 1 2019, 9:04 AM · efl (efl-1.22)
Peter2121 added a comment to T7710: Impossible to build EFL on FreeBSD.
[453/3977] Linking target src/lib/ecore/libecore.so.1.22.0.
Mar 1 2019, 7:02 AM · efl (efl-1.22)

Feb 28 2019

Peter2121 added a comment to T7710: Impossible to build EFL on FreeBSD.

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 28 2019, 10:44 AM · efl (efl-1.22)

Feb 27 2019

Peter2121 added a comment to T7710: Impossible to build EFL on FreeBSD.

Nothing changed adding the header.

Feb 27 2019, 1:06 PM · efl (efl-1.22)
Peter2121 requested changes to D8038: efl_core_proc_env: add header that defined environ.

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.

Feb 27 2019, 12:59 PM · efl

Feb 26 2019

Peter2121 triaged T7710: Impossible to build EFL on FreeBSD as High priority.
Feb 26 2019, 12:56 PM · efl (efl-1.22)

Nov 22 2018

Peter2121 added a comment to T6415: Enlightenment sometimes loses focus.

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

Nov 22 2018, 12:41 AM · enlightenment-git

Nov 13 2018

Peter2121 added a comment to T6415: Enlightenment sometimes loses focus.

I mentioned one interesting thing more.
When I switch to another task, in case of a lost mouse click - not only keyboard works correctly in the active window, but mouse scroll works correctly too. Only mouse clicks (left and right buttons, additional buttons too) are lost for the first click. So, for example, if I switch to another window using mouse and WinList - I cannot use WinList again immediately, the first click of additional button is lost, WinList does not get active.

Nov 13 2018, 10:19 AM · enlightenment-git

Nov 11 2018

Peter2121 added a comment to T6415: Enlightenment sometimes loses focus.

raster,
Sure, the click to dismiss winlist must be lost, I don't count it. I perfectly understand that it is used like 'escape' key. I mean the next click is lost.

Nov 11 2018, 4:39 AM · enlightenment-git
Peter2121 added a comment to T6415: Enlightenment sometimes loses focus.

I've just used 'git clone' command to clone the repository.
I think I'm on 'master' as I see your last modif in src/modules/winlist/e_mod_main.c:
static Eina_Bool _e_mod_action_winlist_wheel_cb(...

Nov 11 2018, 3:28 AM · enlightenment-git

Nov 10 2018

Peter2121 reopened T6415: Enlightenment sometimes loses focus as "Open".
Nov 10 2018, 10:50 AM · enlightenment-git
Peter2121 added a comment to T6415: Enlightenment sometimes loses focus.

Sorry, raster, the problem is still present with the GIT version with your modifs.
Only the first time switching windows with mouse and WinList the focus is not lost. Then it is always lost till I use once Alt-Tab. Then it is not lost once etc.

Nov 10 2018, 10:50 AM · enlightenment-git