dbus, file integration, session integrations, process execution
Sep 3 2019
Jun 3 2019
It's been a year and this still works great.
Apr 10 2019
Jan 28 2019
Support for elogind has been upstreamed for a while now
Jan 23 2019
Jan 22 2019
for now, i can't even compile the EFL on Windows, so...
So...is this getting reviewed or ?
This is unfixable if it's still happening. It's a deadlock caused by gst trying to do an x11 connection in a thread while the main thread is waiting on the connection to succeed. The solution is to not use gstreamer in the compositor process.
Jan 15 2019
What's going on with this?
Jan 14 2019
Can you post a bit more info so I can look into it?
No - it is only worked arround.
@bu5hm4n is this resolved now?
Jan 11 2019
Dec 20 2018
Dec 7 2018
Dec 4 2018
Soooo, more information on this one:
Nov 19 2018
Sep 23 2018
Thank you for respond. The LFS-based linux distribution we developed is Milis Linux (https://milislinux.org). I'm only packager. We do not use the systemd package in our distribution. We use sysvinit instead. Do we need to write a service file for this problem? If the service file is required and it will solve the problem, I will forward it to my other developer friends.
Sep 22 2018
I am using LFS based linux distribution.
Aug 26 2018
Aug 22 2018
Mhh.. it works for me. I've made a patch. Hopefully it will solve the problem.
That's what I tried when I first discovered it and I'm getting constant crashes. I suppose it's possible that it could somehow be local, but I did a clean reinstall...
Mhh,.. I'm actually not quite sure why just changing the initialization value in the constructor from -1 to 0 is not the way to go.
Aug 21 2018
Okay, like an idiot I believed the comment that I found. @jayji adding that extra call (and removing the wrong comment) does resolve it. If you submit a patch for this I'll review.
Although now that I'm testing a patch to do this, I'm getting an immediate crash on init?
No, this should be done in the constructor, which does the initialization to -1 instead of 0.
Oh wait... ecore code seems wrong
Well, it seems that
Aug 18 2018
It crashed again this night... but there is too much eo stuff... What I can see is that the data field of Efl_Loop_Message is NULL (that's the final NULL ptr)
Aug 17 2018
It is pretty hard to reproduce, as it usually happens over night (but not regularly). I'll investigate the next core dump.
Aug 13 2018
Removing release tag since this is likely a local issue.
Aug 12 2018
Working fine from my citest branch. If it doesn't work off master I'm not interested.
It would be interesting to know where/when/how this event is getting added.
Aug 11 2018
Actually, on EFL commit c57b3912a5f65632e17b023d9c12ae6e1fcc819a, I still have this problem.
Aug 9 2018
Aug 3 2018
This seems to have been fixed :)