On 29/09/14 15:46, Chris Michael wrote: > On 09/29/2014 10:42 AM, Cedric BAIL wrote: >> On Mon, Sep 29, 2014 at 4:08 PM, Chris Michael <devilho...@comcast.net> >> wrote: >>> On 09/29/2014 10:03 AM, Cedric BAIL wrote: >>>> On Mon, Sep 29, 2014 at 3:23 PM, Chris Michael <devilho...@comcast.net> >>>> wrote: >>>>> On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: >>>>>> On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael >>>>>> <devilho...@comcast.net> >>>>>> said: >>>>>>> On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: >>>>>>>> On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL <cedric.b...@free.fr> >>>>>>>> said: >>>>>>>>> On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler >>>>>>>>> <ras...@rasterman.com> >>>>>>>>> wrote: >>>>>>>>>> On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL <cedric.b...@free.fr> >>>>>>>>>> said: >>>>>>>>>>> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi >>>>>>>>>>> <lucas.de.mar...@gmail.com> wrote: >>>>>>>>>>>> Em 28/09/2014 08:46, "Graham Gower" <graham.go...@gmail.com> >>>>>>>>>>>> escreveu: >>>>>>>>>>>>> >>>>>>>>>>>>> I've attempted to build using the easy_efl.sh script and received >>>>>>>>>>>>> the >>>>>>>>>>>>> build error referenced in the subject (full build log follows >>>>>>>>>>>>> message). >>>>>>>>>>>>> >>>>>>>>>>>>> Is there a particular version of udev that is required now, but >>>>>>>>>>>>> hasn't >>>>>>>>>>>>> been put in the autoconf goo? I have udev 182 on a linux distro >>>>>>>>>>>>> without systemd. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f >>>>>>>>>>>> >>>>>>>>>>>> libudev 199 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Question as always how many distribution ship this library and how >>>>>>>>>>> many don't. Should we make 199 mandatory or should we just disable >>>>>>>>>>> the >>>>>>>>>>> code that require 199 (I guess it is related to wayland). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> since systemd and udev merged... a lot seem to have stopped updating >>>>>>>>>> udev >>>>>>>>>> at all and may b e on a multi-year-old udev (eg 2011). so our >>>>>>>>>> choices >>>>>>>>>> are >>>>>>>>>> to force an upgrade or work on these distros, or we need a way to >>>>>>>>>> emulate >>>>>>>>>> this udev call inside eeze iof udev is older. that means someone has >>>>>>>>>> to >>>>>>>>>> do the emulation code work there. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Do we really need to ? We could just disable Wayland support if udev >>>>>>>>> is to old, as I think that is the only think that rely on it. The >>>>>>>>> question is more what about other system than Linux. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> that makes for a poor eeze api that may or may not work based on a >>>>>>>> hidden >>>>>>>> udev version at compile time of eeze. >>>>>>>> >>>>>>> >>>>>>> Well, perhaps for the moment we can detect the udev version and just >>>>>>> #ifdef the internal eeze code to skip that function call. Fixes the >>>>>>> build problem while Not breaking code for people that have a sane udev >>>>>>> version. Thoughts ?? >>>>>> >>>>>> but downside is we have an eeze fn that now is broken for some and not >>>>>> others... and then when some try wayland things mysteriously fail.. >>>>>> we'll >>>>>> hit >>>>>> this sooner or later in one form or another. best get it sorted now >>>>>> while >>>>>> fresh. >>>>> >>>>> Ok. Makes sense :) >>>>> >>>>> So...what is the general "agreed" plan for sorting this ?? I've seen a >>>>> couple of thoughts on this thread, but no clear plan/path. I don't mind >>>>> doing the legwork if we all can agree on a path.... >>>> >>>> I am voting to put a big eina log warning in that #if for people who >>>> have an old version and make sure that when Wayland fail to setup that >>>> warning is correctly displayed. After that it is not our duty anymore. >>> >>> Well, the wayland stuff won't fail without it. It's only used for setting >>> the output backlight brightness...so if anything, they won't have backlight >>> control, but that's about it. Everything else will be fine. >> >> Really, that's just it ? Then make it optional is a no brainer in my opinion. >> > > That is it :) We originally coded the backlight to work directly on the > backlight "fd" (raw read/write), however a certain german ;) did not > like that approach and opted for udev/eeze approach (which was fine in > it's own right)...but in order to set the backlight brightness via udev, > we needed that function. > > Ok, so if nobody has any objections ??? , I'll do some modifications > today and #ifdef out that function call with a udev version check.... > > For those that have ancient udev versions, they won't be able to set > backlight levels (when running in drm)...but that's all that will break.
Again, an horrible precedence and a passive aggressive way of saying "we no longer support all of you guys who haven't jumped on the systemd band-wagon". -- Tom. ------------------------------------------------------------------------------ Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
