Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On 30 September 2014 11:37, Doug Newgard wrote: > If you're entire system is that old, I'm sure EFL from 2.5 years ago will run > just fine as well. Slackware 14.1, released Nov 2013. This is not old unless you're accustomed to releasing a new version of your software every 2-3 weeks. Systemd flames aside, my initial post was to ask whether there was a deliberate dependency change or if it was unintended. Specifically, this line in efl/configure.ac created some uncertainty in my mind. EFL_DEPEND_PKG([EEZE], [UDEV], [libudev >= 148]) -Graham -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On 30 September 2014 09:03, Carsten Haitzler wrote: > On Tue, 30 Sep 2014 09:21:16 +1000 David Seikel said: > >> On Tue, 30 Sep 2014 09:15:53 +1000 David Seikel >> wrote: >> >> > On Tue, 30 Sep 2014 08:05:43 +0900 Carsten Haitzler (The Rasterman) >> > wrote: >> > >> > > On Tue, 30 Sep 2014 09:01:58 +1000 David Seikel >> > > said: >> > > >> > > > On Mon, 29 Sep 2014 10:24:53 -0500 Doug Newgard >> > > > wrote: >> > > > >> > > > > >> > > > > >> > > > > >> > > > > > Date: Tue, 30 Sep 2014 00:50:23 +0930 >> > > > > > From: graham.go...@gmail.com >> > > > > > To: enlightenment-devel@lists.sourceforge.net >> > > > > > Subject: Re: [E-devel] libeeze.so: undefined reference to >> > > > > > `udev_device_set_sysattr_value' >> > > > > > >> > > > > > On 30 September 2014 00:42, Doug Newgard >> > > > > > wrote: >> > > > > >> >> > > > > >> udev works fine without systemd. Those distros that are >> > > > > >> refusing to update past 184 are either ones that use ancient >> > > > > >> software anyway or they are just taking a very childish >> > > > > >> stance and refusing to even build it now. >> > > > > > >> > > > > > I think you'll find the version of udev I have (182) really >> > > > > > isn't that old. >> > > > > >> > > > > Two and a half years and over 30 releases ago is pretty out of >> > > > > date. >> > > > >> > > > We prefer the term "stable". :-P >> > > >> > > you and each of your whiskers? :) >> > >> > Me, and Doug, and people like Ubuntu that provide a "Long Term Stable" >> > distro, where it's supported for way more than two and a half years, >> > built on versions that had been stable for some time at the time of >> > release. It's quite popular, perhaps you have heard of it? B-) >> >> Er I meant Me and Graham. The quoting got a bit odd there. > > so your other whisker is called doug ... er graham? :) > Please don't shave. -- 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
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On 30 September 2014 00:42, Doug Newgard wrote: > > udev works fine without systemd. Those distros that are refusing to update > past 184 are either ones that use ancient software anyway or they are just > taking a very childish stance and refusing to even build it now. I think you'll find the version of udev I have (182) really isn't that old. -- 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
[E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
Hi, 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. Reverting commits f15f875fa90cd66955ad16095a49e630d80093b0 and 4483ef20d33e9207e8791baf8af10b12d37c7753 allowed me to build successfully. -Graham --- EASY_EFL 1.6.2 CMD: ./autogen.sh --prefix=/opt/efl --- autoreconf: Entering directory `.' autoreconf: running: autopoint --force autoreconf: running: aclocal --force -I m4 /usr/share/aclocal/imlib.m4:9: warning: underquoted definition of AM_PATH_IMLIB /usr/share/aclocal/imlib.m4:9: run info Automake 'Extending aclocal' /usr/share/aclocal/imlib.m4:9: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy --force libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' /usr/share/aclocal/imlib.m4:9: warning: underquoted definition of AM_PATH_IMLIB /usr/share/aclocal/imlib.m4:9: run info Automake 'Extending aclocal' /usr/share/aclocal/imlib.m4:9: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal autoreconf: running: /usr/bin/autoconf --force autoreconf: running: /usr/bin/autoheader --force autoreconf: running: automake --add-missing --copy --force-missing configure.ac:247: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and will soon be removed. configure.ac:247: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead, configure.ac:247: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your Makefile.am files. src/Makefile_Eolian_Helper.am:15: warning: '%'-style pattern rules are a GNU make extension src/Makefile.am:37: 'src/Makefile_Eolian.am' included from here src/Makefile_Eolian.am:69: 'src/Makefile_Eolian_Helper.am' included from here src/Makefile_Eolian_Helper.am:18: warning: '%'-style pattern rules are a GNU make extension src/Makefile.am:37: 'src/Makefile_Eolian.am' included from here src/Makefile_Eolian.am:69: 'src/Makefile_Eolian_Helper.am' included from here src/Makefile_Eolian_Helper.am:21: warning: '%'-style pattern rules are a GNU make extension src/Makefile.am:37: 'src/Makefile_Eolian.am' included from here src/Makefile_Eolian.am:69: 'src/Makefile_Eolian_Helper.am' included from here src/Makefile_Edje.am:265: warning: '%'-style pattern rules are a GNU make extension src/Makefile.am:66: 'src/Makefile_Edje.am' included from here src/Makefile_Eolian_Cxx_Helper.am:15: warning: '%'-style pattern rules are a GNU make extension src/Makefile.am:79: 'src/Makefile_Eolian_Cxx.am' included from here src/Makefile_Eolian_Cxx.am:95: 'src/Makefile_Eolian_Cxx_Helper.am' included from here src/Makefile_Elua_Helper.am:15: warning: '%'-style pattern rules are a GNU make extension src/Makefile.am:84: 'src/Makefile_Elua.am' included from here src/Makefile_Elua.am:31: 'src/Makefile_Elua_Helper.am' included from here src/Makefile_Eolian_Helper.am:15: warning: '%'-style pattern rules are a GNU make extension src/examples/eolian_cxx/Makefile.am:12: 'src/Makefile_Eolian_Helper.am' included from here src/Makefile_Eolian_Helper.am:18: warning: '%'-style pattern rules are a GNU make extension src/examples/eolian_cxx/Makefile.am:12: 'src/Makefile_Eolian_Helper.am' included from here src/Makefile_Eolian_Helper.am:21: warning: '%'-style pattern rules are a GNU make extension src/examples/eolian_cxx/Makefile.am:12: 'src/Makefile_Eolian_Helper.am' included from here src/Makefile_Eolian_Cxx_Helper.am:15: warning: '%'-style pattern rules are a GNU make extension src/examples/eolian_cxx/Makefile.am:13: 'src/Makefile_Eolian_Cxx_Helper.am' included from here src/examples/eolian_cxx/Makefile.am:131: warning: '%'-style pattern rules are a GNU make extension src/examples/eolian_cxx/Makefile.am:134: warning: '%'-style pattern rules are a GNU make extension src/examples/eolian_cxx/Makefile.am:137: warning: '%'-style pattern rules are a GNU make extension autoreconf: Leaving directory `.' configure: loading cache config.cache checking for gcc... (cached) gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... (cached) o checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts
Re: [E-devel] E17 in Twitter...
2009/5/14 Arlo White : > Yes there are > mailing lists, but the lists have a lot of garbage you need to dig through > to get at the interesting bits. Garbage like this entire thread? Isn't this a development mailing list? -Graham -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] cpu frequency not scaling with E17 + Ubuntu
2009/1/8 Gustavo Sverzut Barbieri : > > I really dislike such governor option for the same reason Matthew > Garrett: the faster you finish the task, the less power you use, less > time with hot cpu... even less time hd spinning (for io+cpu bound > tasks, like compile). That's entirely the point though. Scale up cpu freq when the system is under higher cpu load, scale it down when its not. -Graham -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EWL evas_fb_la_LIBADD patch
2008/12/24 Peter Wehrfritz : > Peter Wehrfritz schrieb: >> >> 4 pixels sound like inset or padding pixels. Since the size request >> happens before the realization some pixels for the inset will be added >> later, when the theme data is loaded. I think for the framebuffer, unlike to >> the x11 engine, the engine should take care of resizing evas and not the >> window. Unfortunately I have not much time before Christmas to look on it. >> Maybe I'll find the time after the holidays. In order that you report keeps >> in mind I put it into bugzilla: >> http://bugs.enlightenment.org/show_bug.cgi?id=553 >> > > I changed some days ago the inset and padding functions to keep the outer > size invariant, and not the inner size as it was before. This could fix your > problem as well. It is not a perfect solution for the fb engine because it > is still possible that a window grow to bigger size and set the view to a > bigger size then the maximum size allowed by the engine. > > Peter > This does indeed fix the bug. Thanks! -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl compile probem
2008/12/16 Matteo : > compiling with: > gcc my_widget.c 'ewl-config --cflags --libs' > > And the compiler doesn't find Ewl.h, there is something I still missing? ewl-config is probably an old script. Everything is using pkg-config these days. E.g. [...@rak ~]$ pkg-config --cflags --libs ewl -I/opt/e17/include/ewl -I/opt/e17/include -I/opt/e17/include/efreet -I/opt/e17/include/eina-0 -I/opt/e17/include/eina-0/eina -L/opt/e17/lib -lewl -ledje -lefreet -lemotion -lepsilon -lembryo -lecore_job -leet -lecore_file -lecore -lgnutls -lssl -lcrypto -ldl -lcurl -levas -leina -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EWL evas_fb_la_LIBADD patch
Peter Wehrfritz wrote: > Graham Gower schrieb: >> Peter Wehrfritz wrote: >>> I committed it without the @EVAS_LIBS@, because Vincent told me that >>> it is not needed. Can you check please if it works now? Since I don't >>> have ecore_fb installed, I cannot test it myself. >> >> Yes, this works fine. > > Nice :) >> >> One other issue which may require attention is >> ewl/src/engines/evas_fb/ewl_engine_evas_fb.c: ee_canvas_setup(), line 190 >> >> ewl_object_geometry_request(EWL_OBJECT(win), 0, 0, 240, 320); >> >> This hardcoded size 240x320 is a problem on our 480x272 framebuffer. It >> causes evas to try to access mmap()ed framebuffer memory outside the >> size that is actually mmap()ed. Hardcoding the geometry request to >> 480x272 >> made the problem go away. >> >> Perhaps this value can be obtained from the size of the framebuffer >> instead? I didn't see a 'struct fb_var_screeninfo' lying around, or I'd >> have used that and sent a patch. > > Indeed, hardcoding the value is very bad. As I said before I've never > used the evas_fb engine, so I have no experience with it. Maybe it is > possible to query the size with ecore_fb_size_get(). Cool, I tested this and it works for me (with ewl_simple_test). --- /home/ggower/ewl_engine_fb.c2008-12-15 09:06:40.0 +1030 +++ ewl/src/engines/evas_fb/ewl_engine_evas_fb.c2008-12-15 09:06:25.0 +1030 @@ -165,6 +165,7 @@ Evas_Engine_Info *info = NULL; Evas_Engine_Info_FB *fbinfo; Ewl_Object *o; +int w, h; DENTER_FUNCTION(DLEVEL_STABLE); DCHECK_PARAM_PTR(win); @@ -187,7 +188,9 @@ fbinfo->info.refresh = 0; fbinfo->info.rotation = 0; evas_engine_info_set(evas, (Evas_Engine_Info *)fbinfo); -ewl_object_geometry_request(EWL_OBJECT(win), 0, 0, 240, 320); + +ecore_fb_size_get(&w, &h); +ewl_object_geometry_request(EWL_OBJECT(win), 0, 0, w, h); o = EWL_OBJECT(win); evas_engine_info_set(evas, info); ewl_test, on the other hand, still tries to write past the end of the framebuffer (it did with a hardcoded value too). Something is adding 4 pixels to the x and y dimensions. Core was generated by `ewl_test'. Program terminated with signal 11, Segmentation fault. [New process 560] #0 evas_common_convert_rgba2_to_16bpp_rgb_565_dith (src=0x2cebe120, dst=, src_jump=, dst_jump=, w=484, h=276, dith_x=0, dith_y=0, pal=0x0) at evas_convert_rgb_16.c:111 111 evas_convert_rgb_16.c: No such file or directory. in evas_convert_rgb_16.c (gdb) bt #0 evas_common_convert_rgba2_to_16bpp_rgb_565_dith (src=0x2cebe120, dst=, src_jump=, dst_jump=, w=484, h=276, dith_x=0, dith_y=0, pal=0x0) at evas_convert_rgb_16.c:111 #1 0x2ccbfd08 in evas_fb_outbuf_fb_push_updated_region (buf=0x4aea00, update=0x4f1070, x=0, y=0, w=484, h=276) at evas_outbuf.c:319 #2 0x2ccbd8b4 in eng_output_redraws_next_update_push (data=0x4ae9e8, surface=0x4f1070, x=0, y=0, w=484, h=276) at evas_engine.c:223 #3 0x2abf9060 in evas_render_updates_internal (e=0x4a3bc0, make_updates=0 '\0', do_draw=1 '\001') at evas_render.c:522 #4 0x2bb06dcc in ee_canvas_render (embed=0x48a4f0) at ewl_engine_evas.c:140 #5 0x2b044fd8 in ewl_engine_canvas_render (embed=0x48a4f0) at ewl_engines.c:1043 #6 0x2b0b29b4 in ewl_idle_render (data=) at ewl_misc.c:541 #7 0x2ad309c0 in _ecore_idle_enterer_call () at ecore_idle_enterer.c:101 #8 0x2ad358b0 in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:653 #9 0x2ad35d78 in ecore_main_loop_begin () at ecore_main.c:88 #10 0x2b0b06b0 in ewl_main () at ewl_misc.c:416 #11 0x00402dfc in main (argc=1, argv=0x7fccfa94) at ewl_test.c:236 > > Another known issues with the fb engine is that it only supports one > window, so menu, popups and other windows most probably don't work. > There is already a bug report for that > http://bugs.enlightenment.org/show_bug.cgi?id=79. I must admit that I > haven't cared much about it yet, but it is on our TODO list :). Help is, > of course, appreciated :). Although popups would be very useful, multiple windows aren't really an issue for me at this point. Touchscreen input is far more important. I'll keep chipping away at things as time allows. > > Sorry for the delay > > Peter -Graham -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EWL evas_fb_la_LIBADD patch
Peter Wehrfritz wrote: > I committed it without the @EVAS_LIBS@, because Vincent told me that it > is not needed. Can you check please if it works now? Since I don't have > ecore_fb installed, I cannot test it myself. Yes, this works fine. One other issue which may require attention is ewl/src/engines/evas_fb/ewl_engine_evas_fb.c: ee_canvas_setup(), line 190 ewl_object_geometry_request(EWL_OBJECT(win), 0, 0, 240, 320); This hardcoded size 240x320 is a problem on our 480x272 framebuffer. It causes evas to try to access mmap()ed framebuffer memory outside the size that is actually mmap()ed. Hardcoding the geometry request to 480x272 made the problem go away. Perhaps this value can be obtained from the size of the framebuffer instead? I didn't see a 'struct fb_var_screeninfo' lying around, or I'd have used that and sent a patch. -Graham -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] EWL evas_fb_la_LIBADD patch
Hi, When EWL is configured with --enable-fb, the EWL engine evas_fb.so fails to be dlopen()able due to missing symbols. The missing symbols can be found in -lecore_fb. -Graham --- Makefile.am 2008-12-09 18:23:18.0 +1030 +++ ewl/src/engines/evas_fb/Makefile.am 2008-12-09 18:26:23.0 +1030 @@ -18,7 +18,7 @@ Ewl_Engine_Evas_Fb.h \ ewl_engine_evas_fb.c -evas_fb_la_LIBADD = $(top_builddir)/src/lib/libewl.la +evas_fb_la_LIBADD = $(top_builddir)/src/lib/libewl.la @ECORE_FB_LIBS@ @EVAS_LIBS@ evas_fb_la_LDFLAGS = -module -version-info @INTERFACE_VERSION@ evas_fb_la_DEPENDENCIES = -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
