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

> 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

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. 

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

William L. Thomson Jr.

Attachment: 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

Reply via email to