On Fri, 6 Apr 2018 14:37:47 -0400 "William L. Thomson Jr." <wlt...@obsidian-studios.com> said:
this is going around in circles. see ross's email. also read the page below: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html > On Sat, 7 Apr 2018 02:14:02 +0900 > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > On Fri, 6 Apr 2018 11:28:58 -0400 "William L. Thomson Jr." > > <wlt...@obsidian-studios.com> said: > > > > > Why does edje_cc need this? It seems to work with it failing. Which > > > makes me think it is not necessary. If it was necessary, edje_cc > > > would fail to generate the edj. > > > > edje (the lib) init efreet. it uses efreet to find cache directories. > > What does edje_cc need to cache as part of its making edj files? It > seems that cache is not needed or used. Since the failure does not > prevent creation of the resulting edj file. > > If it needs that, edje_cc should fail to make the edj file right? Or > handled different as to not generate an error when such occurs for > edje_cc use as its non-fatal. > > > > Why does edje_cc need to connect to an external efreetd process? > > > Maybe it should use more embedded use of efreet and not rely on > > > socket connection for a single process using efreet. Not running > > > anything, building stuff.... No multiple process, no need for > > > efreetd beyond edje_cc. > > > > > > > so - fix your sandbox to not disallow this. > > > > > > Gentoo sandbox does not allow, nothing specific to my environment. > > > > then gentoo's sandbox is broken. > > Hardly the case. > > > as i explained. the runtime dir is > > used for sockets, tmp and other runtime files as libraries or > > processes need them (if set). it's a standard that is well > > documented. as we re-use our libraries in build tools they will > > inherit the same requirements. > > I will try setting XDG_RUNTIME_DIR to a path within the sandbox. > > > of course something is running. edje_cc is running. for a short time, > > but it is. the more complex the code becomes, the more it starts > > having sockets and daemons etc. to share resources or multiplex > > access to a single resource etc. > > Why does edje_cc need a socket connection to daemon efreetd rather than > say use embedded usage. Single process vs two talking to each other. > > > > "All packages must build correctly when sandbox is active. " > > > https://devmanual.gentoo.org/general-concepts/sandbox/ > > > > it's wrong then. :) xdg runtime dir is set and then access to it is > > denied. > > Then I need to override, as I see others doing > https://github.com/gentoo/gentoo/blob/master/eclass/xdg-utils.eclass#L54 > > > yup. the sandbox env does. :) simple: access to xdg runtime dir is a > > necessity for efl libs (if set as an env var - if the env var wasn't > > set we'd use /tmp as a fallback... since your build env sets it... > > it's saying "use this place for runtime sockets/data etc." but then > > it's going "well i told you to use that dir... but no. i'll not allow > > it". > > The build env is inheriting it from parent. Not sure exactly what is > setting that in Gentoo sandbox or Travis Ubuntu vm. That maybe > something that should be overridden/reset by default in Gentoo sandbox > env. It is for some usage per Gentoo's xdg-utils.eclass. Likely just > not needed wide enough to be in sandbox by default. > > Maybe /tmp should be used as a fallback to when directory creation > fails. Not just when XDG_RUNTIME_DIR is unset. That would fix the issue > in another way, and would prevent failure. > > > so... guess why i say the build env is broken? :) don;t set the env > > var (XDG_RUNTIME_DIR), or allow access to where the env var points to > > to use for runtime files. either way... > > Or the correct easier way without all the fuss/blame. Reset/override > the variable, and point to a location within the sandbox that is > writable. > > Though I still think a fallback of using /tmp if writing to > XDG_RUNTIME_DIR fails can't hurt. If that is actually needed at all. > Which I still question, since it fails, yet succeeds. > > > the build env is broken. if we forced use of /tmp instead then > > others would be right in saying "you don't respect xdg runtime dir > > env vars". > > The XDG_RUNTIME_DIR may not always be correct. Like in Travis case. I > assume the travis user is UID 2000. Entrance is running as root, the > client will fork a process as a user, but otherwise the client runs as > root. But its carrying over the XDG_RUNTIME_DIR from the parent env from > sudo. So not replaced by one from root. > https://travis-ci.org/Obsidian-StudiosInc/entrance/jobs/362959773#L1203 > > Same deal there, need to reset/re-export XDG_RUNTIME_DIR for root, or > have sudo reset the env for root. > > No need for all the complexities. Just need a reply of saying set > XDG_RUNTIME_DIR to something that is writable, or correct in Travis > case. > > -- > William L. Thomson Jr. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
