Package Details: enlightenment-git 0.25.99.24774.gc8b1077de-1

Git Clone URL: https://aur.archlinux.org/enlightenment-git.git (read-only, click to copy)
Package Base: enlightenment-git
Description: Enlightenment window manager - Development version
Upstream URL: http://www.enlightenment.org
Licenses: BSD
Conflicts: enlightenment
Provides: enlightenment, notification-daemon
Submitter: Scimmia
Maintainer: raster
Last Packager: raster
Votes: 63
Popularity: 0.000000
First Submitted: 2014-01-08 21:25 (UTC)
Last Updated: 2022-06-13 11:52 (UTC)

Dependencies (28)

Required by (36)

Sources (1)

Latest Comments

1 2 3 4 5 6 .. 17 Next › Last »

raster commented on 2021-05-18 15:56 (UTC)

i know. i don't know why.. it doesn't affect the results though. it doesn't happen with a normal build (outside of makepkg) so some cflag/link flag that pacman is enforcing causes this - or it's strip.

laurent_waro commented on 2021-05-18 15:45 (UTC)

I've got this message when I do an update : readelf: Warning: There is a hole [0xccca5 - 0xcccc7] in .debug_loc section. A lot of this message.

Past install didn't show these messages.

Note that this message appears when I update enlightenment-git and elf-git and terminology-git too.

raster commented on 2021-04-04 09:48 (UTC)

fyoi - this is not the place to discuss upstream bugs really... packaging issues - yes, maybe bringing attention to some arch specific issue, but upstream bug reporting infra (phabricator, email, irc) is the place to be. :)

that aside, seek times or filesystem could impact that too. what is running at the time (before the dialog appears)? efreetd? any other efreet processes? is it that the initial setup of file monitors fails because too many fd's are used and opens begin to fail? have you tried increasing the maximum fd limit for your user? did efreetd_*_cache_create (3 different utilities efreetd spawns on startup to do the scan + update of the cache) crash? i don't know... so much information missing and this forum is going to be slow in finding it. :)

maderios commented on 2021-04-04 09:12 (UTC)

Slow disk? (average) hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 9064 MB in 1.99 seconds = 4546.39 MB/sec Timing buffered disk reads: 330 MB in 3.02 seconds = 109.42 MB/sec

raster commented on 2021-04-03 20:48 (UTC)

is efreetd running? is it busy? this message happen because e doesn't get an update event within its timeout expires. so either things are being super-slow or efreetd keeps crashing and never sends the event etc. - the fact after a restart it's ok tells me this may be due to a slow disk and a lot of file to scan and it just is taking a while...

maderios commented on 2021-04-03 13:40 (UTC)

@laurent_waro Same for me. This is an old issue. https://phab.enlightenment.org/T7045

laurent_waro commented on 2021-04-03 13:26 (UTC)

I've got this message from E : "Efreet did not update cache. Please check your efreet setup. Is effretd running". The directory .cache/efreet is owned by me and is writable.Any ideas to help me to find the origin of this warning? Thanks for the update of E, top!

EndlessEden commented on 2020-10-21 13:36 (UTC)

Request: please add network-manager-applet to optional dependencies, for NetworkManager Support. (NetworkManager is alot more fleshed out than connman)

raster commented on 2020-05-15 23:26 (UTC)

aaah thanks. change of default cflags.... so it was a cflags thing - just a change in compiler cflags built in... got it. fixed upstream in git

andre.vmatos commented on 2020-05-15 16:48 (UTC)

Looks like it's caused by gcc10 defaulting to -fno-common, which fails with the multiple definitions error on linking instead of merging them. I managed to get this package compiled under gcc10 by adding -fcommon to $CFLAGS to revert to the previous behavior