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.
pgpDNCkkL4W8o.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
