On Thu, 11 Jun 2020 16:32:50 +0000 Matt Bagnara <bagnaram...@gmail.com> said:
Well then. this is not an easy fix. basically a very very very quick rundown of
the pipeline is something like this:
Unlike gtk/gnome apps that require you insert some "update caches" on all
package install/uninstalls, we do this at runtime. We have to because we have
enough problems getting people to package efl or e let alone forcing them to add
distribution-wide hooks to generate cache files for us.
So this is done by efreetd hanging around all day while you are logged in
setting up file/director monitors to monitor all the places desktop files and
icon files/themes might live. if these trigger to show a change, efreetd
re-runs the cache building tools it comes with in PREFIX/lib/efreetd/v-1.24/...
and when they complete then informs all efl clients (e, terminology, rage etc.)
that the efreet icon/app database changed so these apps then close and re-open
the cache files for their view on the world.
so this cache build step relies on various things like checking mtime to see if
it changed because the files or dirs that changed on disk should have changed
mtime (be newer) and cache building is dependent on these changing. it also
clashes with another api which is "get modified timestamp of file" where 0 is
actually an error code as no file is expected to ever be modified at time 0 as
no system efl can run on should have a filesystem that dates back that far... :)
the problem here is that mtime is being explicitly set to a problematic and
"unrealistic" value and thus is going to fall through all sorts of holes along
with the timestamp never changing as changes happen. the code was literally
designed that this is actually not going to actually happen.
so there isn't a quick and easy fix beyond "try touch files/dirs and update
their timstamps" right now.
i have some pending patch/diff i can share to efreet that might help you. it
might not. i'm currently testing it myself across multiple systems - but they
are all arch. i've expanded the timestamp to also check ctime, mtime, size of
file, file mode, uid, gid, block count, if a symlink, sha1 hash of the link
string. i';ve skipped comparing inode and device # as these may possibly be
dynamic in some cases like maybe sshfs or other remote or fuse mounts.
the point of checking just stat info is it's fast. slow would be to md5/sha1 the
content of files and do a full compare, but this is very expensive in
comparison to just a stat and kind of negates the whole point of having nay
"update this only if it changed" logic at all. nix makes this hard.
in fact i would push to doubt the idea of reproducible builds. so i notice
ctime is not 0. birth (extra non standard stat) is not 0. access time is not 0
but mtime is... so it's broken. good luck keeping all these 0 without making it
a read-only fs image like maybe a cram/crom/squashfs partition for example. but
even worse is... inode number there will keep changing and stat exposes the
inode number and it will vary based on fs used and nature of content at the time
the inode is allocated etc. ... so even if you manage to lock all of the
others down, inode will still vary. being selective about mtime being
reproducible but not absolutely everything else makes the idea imho bad... so
i'd push back a bit on this given that it breaks userspace apps and tools. not
to mention the utterly broken "birth date is newer than modified date" ... :)
if you;'re willing to try a patch i can share it with you to see if it helps,
but take back the above points etc. and info on how this breaks things. so you
install a new package in nix. if mtime doesn't change... how do we know our
caches are out of date? if you say "use ctime then" then i go "then your build
is not reproducible ... so why make us go change our code anyway for a goal you
cannot achieve?". :) just to let you see where i am coming from... :)
> Thank you for the diagnosis. I wouldn't have thought mtime would be a
> problem here but it is. Nix seems to be forcing a MTime of 0 indeed:
>
> nixos% stat /run/current-system/sw/share/icons/hicolor/32x32/apps/firefox.png
> File: /run/current-system/sw/share/icons/hicolor/32x32/apps/firefox.png
> ->
> /nix/store/m287km3ss1g1xy18qkalslzhcyiqp5i9-firefox-76.0.1/share/icons/hicolor/32x32/apps/firefox.png
> Size: 101 Blocks: 8 IO Block: 4096 symbolic link
> Device: 801h/2049d Inode: 1464801 Links: 1
> Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2020-06-09 21:23:40.732333491 +0000
> Modify: 1970-01-01 00:00:01.000000000 +0000
> Change: 2020-06-09 21:23:40.502342475 +0000
> Birth: 2020-06-09 21:23:38.716412197 +0000
>
> Reaching out to the NIX IRC to find out more info on this behaviour.
>
> On 11/06/2020, Carsten Haitzler <ras...@rasterman.com> wrote:
> > On Wed, 10 Jun 2020 18:20:58 +0000 Matt Bagnara <bagnaram...@gmail.com>
> > said:
> >
> >> On 10/06/2020, Carsten Haitzler <ras...@rasterman.com> wrote:
> >> > On Tue, 9 Jun 2020 22:22:07 +0000 Matt Bagnara <bagnaram...@gmail.com>
> >> > said:
> >> >
> >> >> On 09/06/2020, Carsten Haitzler <ras...@rasterman.com> wrote:
> >> >> > On Tue, 9 Jun 2020 18:11:11 +0000 Matt Bagnara
> >> >> > <bagnaram...@gmail.com>
> >> >> > said:
> >> >> >
> >> >> >> They are being set by the environment script
> >> >> >> /nix/store*-set-environment. The strange thing is that the icons
> >> >> >> will
> >> >> >
> >> >> > but does this set the environment before e runs?
> >> >> Yes, I did some digging, and it gets set single-time in /etc/profile
> >> >> when lightDM starts the shell initially for the enlightenment launch
> >> >> process.
> >> >> >
> >> >> >> display in the title-bar when launched. However, not in the menu.
> >> >> >> The
> >> >> >> icon theme is set to the default "Enlightenment-x" for
> >> >> >> applications.
> >> >> >>
> >> >> >> strings /proc/`pidof enlightenment`/environ | grep XDG_DATA
> >> >> >> XDG_DATA_DIRS=/home/mbagnara/.nix-profile/share:/etc/profiles/per-user/mbagnara/share:/nix/var/nix/profiles/default/share:/run/current-system/sw/share
> >> >> >
> >> >> > it's not set to
> >> >> > /nix/store/mip8jx89p9h8dixngwhhcwnhxvs5a0rv-enlightenment-0.24.1/share/enlightenment:/nix/store/mip8jx89p9h8dixngwhhcwnhxvs5a0rv-enlightenment-0.24.1/share:/home/mbagnara/.nix-profile/share:/etc/profiles/per-user/mbagnara/share:/nix/var/nix/profiles/default/share:/run/current-system/sw/share
> >> >> >
> >> >> > so not set to what you think it should be set to... nix with its
> >> >> > non-fhs
> >> >> > layout
> >> >> > will make this hard and you have to pay attention to these details
> >> >> > :)
> >> >>
> >> >> Indeed these environments are different, but that is because any
> >> >> shell that is started through E gets appended its path to
> >> >> XDG_DATA_DIRS. Looking at a generic shell, it is set to the previous
> >> >> value.
> >> >> XDG_DATA_DIRS=/home/mbagnara/.nix-profile/share:/etc/profiles/per-user/mbagnara/share:/nix/var/nix/profiles/default/share:/run/current-system/sw/share.
> >> >> There is something about this path scheme that E doesn't like. I
> >> >> wonder
> >> >> if
> >> >> it has anything to do with following symlinks.
> >> >
> >> > wel lit';s entirely missing the store/SOMELONGUUIDSTRING bit
> >> > entirely...
> >> >
> >> > enlightenment does indeed modify XDG_DATA_DIRS. specifically if it is
> >> > not
> >> > set
> >> > it sets it to:
> >> >
> >> > snprintf(buf, sizeof(buf),
> >> > "%s:%s/share:/usr/local/share:/usr/share",
> >> > e_prefix_data_get(), p);
> >> >
> >> > so that means whatever install prefix e is in + /share, then
> >> > /usr/local/share
> >> > and then /usr/share.
> >> >
> >> > if it is set e PREPENDS to the env var like:
> >> >
> >> > if (s)
> >> > {
> >> > Eina_Bool pfxdata, pfx;
> >> >
> >> > pfxdata = !_xdg_check_str(s, e_prefix_data_get());
> >> > snprintf(newpath, sizeof(newpath), "%s/share", p);
> >> > pfx = !_xdg_check_str(s, newpath);
> >> > if (pfxdata || pfx)
> >> > {
> >> > snprintf(buf, sizeof(buf), "%s%s%s%s%s",
> >> > pfxdata ? e_prefix_data_get() : "",
> >> > pfxdata ? ":" : "",
> >> > pfx ? newpath : "",
> >> > pfx ? ":" : "",
> >> > s);
> >> > e_util_env_set("XDG_DATA_DIRS", buf);
> >> > }
> >> > }
> >> >
> >> > so basically it's looking to see if e's prefix is already accounted for
> >> > in
> >> > the
> >> > env var, if it is NOT then it prepends PREFIX/share/enlightenment 9tyhis
> >> > is
> >> > actually pointless but won't hort except to cause a false hunt for
> >> > icons
> >> > there
> >> > and it'll go onto the next dir), then PREFIX/share, then what was in
> >> > the
> >> > env
> >> > var to begin with. it's basically ensuring that e's enlightenment-X
> >> > icon
> >> > theme
> >> > can be found (and then a bit in addition). so the env var you gave to
> >> > begin
> >> > with makes sense the "long id strings" are where e has figureout out
> >> > it's
> >> > installed
> >> > (nix/store/mip8jx89p9h8dixngwhhcwnhxvs5a0rv-enlightenment-0.24.1
> >> > is
> >> > the runtime detected prefix). everything after that is from your
> >> > environment
> >> > so /run/current-system/sw/share is there at the end and that is where
> >> > icons/hicolor is so ... it's found.
> >> >
> >> > so where are the firefox etc. icons? ar they in the data dirs search
> >> > path
> >> > at
> >> > all (remember these just indicate the share dirs - inside of that an
> >> > icons
> >> > dir
> >> > is expected then a dir for name of icon theme and so on)?
> >> > Enlightenment-X
> >> > doesnt ship with app icons as there really is a massive numbr to then
> >> > make
> >> > and
> >> > ship, so it'll be depending on the icons in XXX/icons/hilcolor or
> >> > XXX/share/pixmaps or in some icon theme you selected... ?
> >> find -L /run/current-system/sw/share/ -type f -iname "firefox*"
> >> /run/current-system/sw/share/icons/hicolor/32x32/apps/firefox.png
> >> /run/current-system/sw/share/icons/hicolor/128x128/apps/firefox.png
> >> /run/current-system/sw/share/icons/hicolor/48x48/apps/firefox.png
> >> /run/current-system/sw/share/icons/hicolor/16x16/apps/firefox.png
> >> /run/current-system/sw/share/icons/hicolor/64x64/apps/firefox.png
> >> /run/current-system/sw/share/icons/HighContrast/32x32/apps/firefox.png
> >> /run/current-system/sw/share/icons/HighContrast/256x256/apps/firefox.png
> >> /run/current-system/sw/share/icons/HighContrast/scalable/apps-extra/firefox-icon.svg
> >> /run/current-system/sw/share/icons/HighContrast/48x48/apps/firefox.png
> >> /run/current-system/sw/share/icons/HighContrast/24x24/apps/firefox.png
> >> /run/current-system/sw/share/icons/HighContrast/22x22/apps/firefox.png
> >> /run/current-system/sw/share/icons/HighContrast/16x16/apps/firefox.png
> >> /run/current-system/sw/share/applications/firefox.desktop
> >>
> >> According to this location the should be found under the
> >> /run/current-system/sw/share path of XDG_DATA_DIRS. This path contains
> >> multiple symlinks though:
> >> [mbagnara@nixos:~]$ ls -al
> >> /run/current-system/sw/share/icons/hicolor/32x32/apps/firefox.png
> >> lrwxrwxrwx 1 root root 101 Jan 1 1970
> >> /run/current-system/sw/share/icons/hicolor/32x32/apps/firefox.png ->
> >> /nix/store/m287km3ss1g1xy18qkalslzhcyiqp5i9-firefox-76.0.1/share/icons/hicolor/32x32/apps/firefox.png
> >>
> >> Thanks for sharing the code snippets though. Perhaps we need to look
> >> in the section that the directories are traversed.
> >
> > well icons are found from cache files in ~/.cache/efreet/ ... these files
> > are
> > generated but specifically for icons by efreet_icon_cache_create - a binary
> > efreetd launches hen one of the dirs it is monitoring changes (or when it
> > is
> > started up to check for changes while it was not running - so e.g. when you
> > log in as efreetd is spawned by the first efl apps to init efreet).
> >
> > the src is efreet_icon_cache_create.c in efl. i know if follows symlinks.
> > i've
> > checked. (threw in printfs and some symlinks in /usr/share/icons to point
> > to
> > somewhere else).
> >
> > i wonder... what is the stat info on your symlink? like:
> >
> > 9:48AM /usr/share/icons > stat xxx
> > device 66307
> > inode 19539578
> > mode 16877
> > nlink 21
> > uid 0
> > gid 0
> > rdev 0
> > size 4096
> > atime 1503760246
> > mtime 1591863653
> > ctime 1591863653
> > blksize 4096
> > blocks 8
> > link
> >
> > efreetd uses the timestamps to know if it changed since it last looked
> > (modified time (mtime) should be > mtime the last time it looked - it
> > stores
> > this in the cache to know). is nix perhaps doing something "crazy" like
> > enforcing an mtime of 0 or never changing it? (we just stat the file with
> > stat() so it'll follow the symlink). what is the stat info of the symlink
> > itself
> > (stat -L xxx)
> >
> > ?
> >
> >> >> >> On 09/06/2020, Carsten Haitzler <ras...@rasterman.com> wrote:
> >> >> >> > On Tue, 9 Jun 2020 01:16:19 +0000 Matt Bagnara
> >> >> >> > <bagnaram...@gmail.com>
> >> >> >> > said:
> >> >> >> >
> >> >> >> > did you choose an icon theme?
> >> >> >> > settings->look->application theme->icons
> >> >> >> > ?
> >> >> >> >
> >> >> >> > how do you set XDG_DATA_DIRS? like in ~/.xinitrc or ~/.xsession
> >> >> >> > before
> >> >> >> > e
> >> >> >> > runs?
> >> >> >> > have you checked:
> >> >> >> >
> >> >> >> > strings /proc/`pidof enlightenment`/environ | grep
> >> >> >> > XDG_DATA_DIRS
> >> >> >> > ?
> >> >> >> >
> >> >> >> >> Hi folks! I am a happy user of e24.1 I seem to have issues with
> >> >> >> >> application icons showing up in the menu and window titles.
> >> >> >> >> Specific
> >> >> >> >> applications like Firefox and emacs have missing icons, but
> >> >> >> >> icons
> >> >> >> >> that
> >> >> >> >> are part of the hicolor pack show up fine. I have made sure
> >> >> >> >> that
> >> >> >> >> my
> >> >> >> >> $XDG_DATA_DIRS points to a location containing my icons. In this
> >> >> >> >> case
> >> >> >> >> they are in /run/current-system/sw/share/icons/hicolor/ This
> >> >> >> >> directory is part of my search path
> >> >> >> >> $XDG_DATA_DIRS=/nix/store/mip8jx89p9h8dixngwhhcwnhxvs5a0rv-enlightenment-0.24.1/share/enlightenment:/nix/store/mip8jx89p9h8dixngwhhcwnhxvs5a0rv-enlightenment-0.24.1/share:/home/mbagnara/.nix-profile/share:/etc/profiles/per-user/mbagnara/share:/nix/var/nix/profiles/default/share:/run/current-system/sw/share.
> >> >> >> >> I have tried setting the path also in the Icons Search Path
> >> >> >> >> Settings
> >> >> >> >> under the enlightenment settings. I have restarted E and tried
> >> >> >> >> creating fresh users and I still cannot seem to display
> >> >> >> >> application
> >> >> >> >> icons.
> >> >> >> >>
> >> >> >> >> Many thanks!
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> _______________________________________________
> >> >> >> >> enlightenment-users mailing list
> >> >> >> >> enlightenment-users@lists.sourceforge.net
> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > ------------- Codito, ergo sum - "I code, therefore I am"
> >> >> >> > --------------
> >> >> >> > Carsten Haitzler - ras...@rasterman.com
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> > ------------- Codito, ergo sum - "I code, therefore I am"
> >> >> > --------------
> >> >> > Carsten Haitzler - ras...@rasterman.com
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >> > --
> >> > ------------- Codito, ergo sum - "I code, therefore I am"
> >> > --------------
> >> > Carsten Haitzler - ras...@rasterman.com
> >> >
> >> >
> >>
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > Carsten Haitzler - ras...@rasterman.com
> >
> >
>
>
> _______________________________________________
> enlightenment-users mailing list
> enlightenment-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
