On Sun, 8 Apr 2018 11:55:08 -0400 "William L. Thomson Jr." <wlt...@obsidian-studios.com> said:
> On Sun, 8 Apr 2018 13:52:26 +0900 > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > On Sat, 7 Apr 2018 12:52:15 -0400 "William L. Thomson Jr." > > <wlt...@obsidian-studios.com> said: > > > > > On Fri, 6 Apr 2018 14:49:52 -0700 > > > Ross Vandegrift <r...@kallisti.us> wrote: > > > > > > > Solution is to run WITH XDG_RUNTIME_DIR and HOME set to a temp > > > > dir: > > > > https://sources.debian.org/src/efl/1.20.7-4/debian/fake_home.sh/ > > > > > > HOME was already reset, it was just XDG_RUNTIME_DIR that was not > > > reset Its is not a widely used variable. Thus Gentoo sandbox does > > > not set by default like it does HOME and other stuff. > > > > > > This was the simple answer I was looking for though I had already > > > replied as such before this came across :) > > > > my very first answer explained why edje_cc does this then gave you an > > answer - fix your sandbox. > > It was the wrong answer, and way more explanation than needed. The > correct answer as stated by myself and other was to reset/override > XDG_RUNTIME_DIR. > > Nothing more need be stated, Short concise, reset/override that var. As > my follow up email stated. 2 sentences... > https://sourceforge.net/p/enlightenment/mailman/message/36286255/ mental note. never explain anything to you in future. :) you have no interest in why. next time i shall just say: "fix your sandbox to allow writing to that dir". as that is the correct answer generically for any environment with an XDG_RUNTIME_DIR set. > Explanation on edje_cc was not needed. Though I still stand by it > should use an embedded connection to efreetd vs a daemon/socket. I can > see why efreetd is a daemon for normal usage. Being a daemon for > edje_cc usage does not make sense. Unless using an exising efreetd > instance if already running. But starting one I think is bad. But that > is all moot. > > > you chose not to like the answer. it > > would have happily fixed the violations because the access to this > > dir is not an error or strange or unintended (which is why i > > explained why it happens). bu unsetting the env var you are just > > working around the problem, not fixing the root cause (the sandbox). > > I had the same issue in Travis with no sandbox. Thus your saying to fix > sandbox was not correct. The sandbox was not broken. If anything not > sanitizing all env variables, but that maybe intentional for other > reasons. i could explain why that is wrong... but see above. :) > Not replacing or overriding a single variable hardly qualifies for > sandbox being broken. A more accurate statement would be issues with > build environment variables. Since that is the case for both sandbox > and Travis environments. > > > imagine the day comes when XDG_RUNTIME_DIR is required and things > > will hard fail without because apps don't want a "accessible by other > > users" place for their sockets etc. and want it already secured. :) > > This was never about questioning that variable. The answer/solution > involved that variable only. > > The reason sandbox does not touch that by default. Is due to not many > applications using or relying on XDG_RUNTIME_DIR. That is just for > desktop stuff, and the Unix/Linux software world is much larger than > just desktop stuff. The vast majority of packages say in Gentoo would > never use XDG_RUNTIME_DIR. So having sandbox scrub that is pointless. > > Plus even if I "fixed" sandbox. It would not address the issues in > Travis. Which I ended up using /tmp as I had to many problems > in Travis otherwise. Which again did not involve any sandbox. > https://github.com/Obsidian-StudiosInc/entrance/commit/af884552f73006ed54b2dd09ceb429ba15d6252e > > -- > 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
