Re: [E-devel] Patch for engage on x86_64
seems to me that this is not a patch against a clean CVS co - I cannot
see what is new / changed / old
Didier Casse wrote:
Dear developers,
Please take a look at the patches and commit
if possible, Thanks.
cheers,
Didier
-- Forwarded message --
From: John Ellson [EMAIL PROTECTED]
Date: May 30, 2005 10:41 PM
Subject: Re: Request for review: Enlightenment DR17 + EFL
To: Didier Casse [EMAIL PROTECTED], Discussion related to Fedora
Extras [EMAIL PROTECTED]
Didier Casse wrote:
Hi all,
I would like to have a review on the Enlightenment DR17 package
+ the accompanying Enlightenment Foundation Library packages (EFL).
Engage fails to rpmbuild on x86_64
Ok the spec patch if for me to apply. Please look at the second one. ;-)
Architure dependency in engage.spec:
--- engage.spec.old 2005-05-29 05:32:34.0 -0400
+++ engage.spec 2005-05-30 10:35:01.0 -0400
@@ -44,7 +44,7 @@
%defattr(-,root,root)
%{_bindir}/engage
%{_libdir}/engage*
-%{_libdir}/enlightenment/modules_extra/engage/linux-gnu-i686/*
+%{_libdir}/enlightenment/modules_extra/engage/
%{_datadir}/engage*
%doc AUTHORS ChangeLog COPYING README
Improper setting of $libdir in configure.in:
--- engage-0.0.9/configure.in.old 2005-05-30 10:19:31.0 -0400
+++ engage-0.0.9/configure.in 2005-05-30 10:20:57.0 -0400
@@ -39,6 +39,7 @@
fi
fi
+if test x{libdir} = xNONE; then
if test x${exec_prefix} = xNONE; then
if test x${prefix} = xNONE; then
libdir=${ac_default_prefix}/lib;
@@ -52,6 +53,7 @@
libdir=${prefix}/lib;
fi
fi
+fi
dnl Set PACKAGE_DATA_DIR in config.h.
if test x${datadir} = 'x${prefix}/share'; then
---
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=fad-ysdn-ostg-q22005
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
---
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Patches for entrance on x86_64
On 5/31/05, John Ellson [EMAIL PROTECTED] wrote: Corey Donohoe wrote: I guess I sorta see why this was working for me, I'm on gentoo not fedora. nemesis% ls -l /usr/X11R6/ | grep lib lrwxrwxrwx1 rootroot5 Mar 29 14:49 lib - lib64 drwxr-xr-x7 rootroot 4096 May 7 02:44 lib32 drwxr-xr-x 83 rootroot49152 May 30 13:22 lib64 drwxr-xr-x6 rootroot 4096 May 14 09:30 libexec Didier's patches for the daemon/Makefile.am work for you too John ? Sorry for the confusion - the patches came from me originally. Yeah the patches are John Ellson's patches. ;-) I'm sorry if i didn't make that clear. -- -- With kind regards, Didier. Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl_embed mysterious black border
On Fri, 27 May 2005 16:35:16 +0100 Simon Poole [EMAIL PROTECTED] babbled: I would love to do that, but unfortunately on the platform I'm using (200MHz ARM-based EP9312) Evas is too slow to run full-screen. With a 640x480 screen there is a noticeable swipe on each full-screen update. With a 1280x1024 screen it is even worse. Our app involves frequent full-screen updates, so that's kind of fatal. I prerender/dither all images to 16bpp and do a hardware flip to put them on-screen. hmm i see. interesting as i have really not observed these before - then again the 200mhz arm box i have done evas stuff on is 320x240 so there is much less screen to update :) i guess one problem is that it can only update at best at bus write bandwidth. that is made worse by the fact it saves memory copies by doing a convert from 32bpp to screen depth (likely 16bpp) while copying the updates to the screen - it saves bandwidth and is an actual speedup, but it exposes this step to you if it happens to be slow enough to notice such an update.. in order to do such hardware flips i'd have to introduce full double buffering concepts in evas (as evas inherently is single-buffered in that it only maintains current and previous states. double buffering would mean we maintain cur, prev and prev2). i'd need to add to the engines an api for the engine to tell evas how many states to keep i guess. :) However, Evas is more than capable of animating smaller UI elements and I think it's immensely suitable for that job. well it likely can do the whole job :) but just its fb output interface is a bit simple. i've never focused on it a lot. i always kind of thought if your system is that limted that you can WATCH an update even with evas's code (which is quite optimised in sheer ability to get pixels rendered to the screen of that level of complexity) then maybe the hw needs some acceleration help :) I'm currently relying on the fact that when Evas repaints, it only ever touches tiles with Evas_Objects in (apart from blanking the whole screen when it is initially created). Is that a reasonable assumption? When definitely not. for example the opengl engine actually does a bounding box re-render... as gl SUCKS at handling updating lots of smaller update rects. gl can invariably re-render a single rect or the whole screen faster than it can render 5x 20x20 rects - as opposed to a single 1600x1200 rect region :) it's definitely not something i'd rely on :) as i was saying above. i think the solution would be to add infrastructure to handle another stored state, engines saying how many states to use, virtualize the state pipeline/copy system (even remove copy by just using a state ref table per object and just change the table pointers to point to cur, prev and prev2, prev3 etc. states), then have the engine render offscreen as it does currently and on a flush, do a hw flip. in fact dont even wait to flip.. fork off a child that waits till vblank to flip (unless the hw can flip screens without having to wait till vblank to do it - and the flip only takes effect next screen scan). also make the same changes i made to the x11 engine - to sync all rgba buf - screen copies/updates to happen at the same time so u dont see each region updating.. then again with double buffering it wouldn't matter :) we need to work in single buffering as not everything CAN double buffer... nor do u always want it :) but this is the "correct solution" i would say - it would 1. give you a high quality RGBA output engine so you don't ever have to care again what the output is - just feed it 32bit ARGB data and that's the last you care :) you know that whatever the target display, it will do its best to get it there looking decent. anyway - we could work together on this. IF you are willing to do this (it's up to you). to save me a bit of researching - i could do with: 1. detect if fb can/has double buffering ability code. 2. code to actually do the flip. 3. code to know if the flip happens instantly or is deferred till the next frame update. 4. code to do a BLOCKING flip (or be able to query until vblank time to do flip then), 5. code to know just where the backbuffer lives in video ram (and make sure its mapped in as well as the front buffer). the rest is as described above. my app takes over, I hide all Evas objects before accessing the framebuffer directly. Then when I show the Evas objects again, I expect to still see my own stuff around the outside. I'm happy to tweak the dialogs to 8-pixel boundaries! beware - that isn't a guaranteed. it used to be 16x16 pixel tiles. i found 8x8 just as easy on the cpu but a bit more accurate in limiting overdraw :) but ii guess this is the fastest solution... BUT its not
Re: [E-devel] Always click to focus + double click to raise.
On Mon, 30 May 2005 23:55:36 +0500 Boldin Pavel [EMAIL PROTECTED] babbled: Hi all! Raise by double click does not work with "Always click to focus" switched on. It is seems to don't work by reason of ecore_x_event_grab. there was never a raise by double click as such - any click would have raised. but i did notice problems with click to focus... and i do think i fixed them- then again i can't remember now - i dont use click to focus and thus dont pay much attention to it. is everything up to date? that includes ecore, edje, evas etc.? -- Boldin Pavel aka davinchi. mail-to: ldavinchi /at\ inbox _dot_ ru ZU - Zagovor Unixoidov. SSAU 303. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Memory module - new version
On Wed, 25 May 2005 02:24:57 +0200 Val__ry Febvre [EMAIL PROTECTED] babbled: Hello, Here is a new version of the memory/swap monitor module. About this version: * /proc/meminfo parsing function was rewritten to support all formats (kernel versions before and after 2.5.?) * a new theme which is well-matched with the e17 default theme. Thx to Robert Rothermel. i HATE to say this... good work on doing a module... but you need help with the gfx department :) don't take offense - please... but... it needs work on the gfx side :( -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EDJE ERROR: programs recursing up to recursion limit of 64. Disable SAVE!!!!
On Fri, 27 May 2005 00:12:55 +0200 "Eduard Feicho" [EMAIL PROTECTED] babbled: It seems as if Edje_load or something similar put one List too much into the Edje. That of course might be becaue of some portability issue concerning my NetBSD. I will try to find out what it is, but help is appreciated. It would be nice if you could give comments like where I can find the place where the init.edj is loaded, so that I can take a look why after is not NULL. I will search for it in the meantime. Or maybe you have a different opinion on what the reason for this behaviour could be. cvs update edje in about 12hrs from now. it SHOULd be fixed. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EWL: Segfault in ecore_config_system_init: SOLVED
On Tue, 24 May 2005 11:22:28 +0100 Simon Poole [EMAIL PROTECTED]
babbled:
Simon Poole wrote:
open("/usr/lib", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=696, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
pivot_root(umovestr: Input/output error
0x3, "") = 936
pivot_root(umovestr: Input/output error
0x3, "\u\u7") = 0
close(3)= 0
I've found why the segfault is happening. I had failed to copy the
ecore_config_ipc_ecore.so library onto my target hardware.
It looks like any kind of failure in _ecore_config_ipc_init would cause
the same segfault. Being completely unfamiliar with the ipc stuff, I've
no idea whether this is a problem or not.
In case anyone is interested, the missing library made
_ecore_config_ipc_init("_system") return NULL, which caused
_ecore_config_system_init_no_load() to return ECORE_CONFIG_ERR_FAIL half
way through (before calling ecore_config_bundle_new()).
So __ecore_config_bundle_local never gets initialised, resulting in a
segfault in _ecore_config_system_load:
snprintf(buf, PATH_MAX, "%s/.e/config.eet", p);
if (ecore_config_file_load(buf) != 0) {
/* even if this file (system.eet) dosen't exist we can
* continue without it as it isn't striclty necessary.
*/
ecore_config_file_load(PACKAGE_DATA_DIR "/system.eet");
}
sys = __ecore_config_bundle_local-data;
^
|
here
aah - hopefully andy will be fixing up ecore_config really soon... :) he was
talking about it day before yesterday on IRC. (IRC - yes that secret place where
all the real development chat happens :) )
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多 [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
---
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2: less restrictions for put_back_data
On Sun, 29 May 2005 13:53:28 +0200 Tilman Sauerbeck [EMAIL PROTECTED] babbled: Hi, I have stumbled across a problem in Imlib2 wrt language bindings. imlib_image_put_back_data() assumes that the data pointer it has been given points is the same that was returned by imlib_image_get_data(). When you're not using Imlib2's C interface, but some language binding, this restriction can be hard to meet. I suggest to apply the attached patch, which will memcpy() the data if the pointer passed isn't the original pointer. Is this okay to commit? hmm - as i said on irc... (just tidying off mail loos ends) somehow to me this smells of a ruby/binding issue not something to be put into imlib2's api as a workaround.. ? :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_config command line tool
On Wed, 25 May 2005 12:47:57 +0100 Simon Poole [EMAIL PROTECTED]
babbled:
Okay Raster, I took the bait..
Here's a simple command-line tool ('econfig') to read and write settings
to an Ecore_config file. The name was chosen to avoid confusion with
the altogether different 'ecore-config'.
one request - can you call it ecore_config? :) i just like namespacing all the
binaries as well as libs and everything else :)
Provided as a patch against ecore-0.9.9.007, but should apply cleanly
against CVS HEAD. Given my inexperience with ecore_config, someone
should cast an eye over it before committing.
Example usage:
To set EWL apps to always render to the framebuffer for the current user:
# mkdir $HOME/.e
# econfig $HOME/.e/config.eet set /ewl/evas/render_method str "fb"
Just type 'econfig' for usage information
One thing -- I've not been diligent about free()ing stuff as it's a fire
and forget command-line tool so that kind of thing is done for you by
the Linux kernel on exit. Does that create portability problems wrt
other OSes?
nah - i dont think efl is really ever destined for os's that dont free up for
you on exit... :) i've gotten lazy over the years and just ASSUME it will be
done for me now :)
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多 [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
---
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Czech localization
On Thu, 26 May 2005 05:54:36 +0200 Martin Sekera [EMAIL PROTECTED] babbled: Hi, I'm sending a czech .po for current E17 CVS, fully translated... in cvs! :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EWL: how to set render_method?
On Wed, 25 May 2005 10:15:06 +0100 Simon Poole [EMAIL PROTECTED] babbled: Carsten Haitzler (The Rasterman) wrote: hmm - i'm not sure about ewl - that's nathan and atmos's big baby - i personally think it'd be good for ewl to provide an explicit api... you could also use the ewl_embed that means you create the evas yourself with ecore_evas and then just tell ewl to use it. then you will have full control. I'm always in favour of explicit APIs! When documentation is thin or interfaces are in flux, then looking at a simple C header can speed up the learning curve no end. This has been really handy when learning to use Ecore and Evas. true - that's how i learn just about everything i find :) i read the .h first - when baffled. look for example. resort to actual docs as a last resort... :) That said, I'm impressed how easy it has been to get started with EWL (once I got through my initial fumbling!). Congratulations guys! thanks :) but there is much room for improvement yet... MUCH! Also, what is the file format for ecore_config databases? The EFL cookbook says it is EDB, but ecore_config looks for EETs. In fact, by my reading of the code, the following should work to create a config.eet file: yeah. it's wrong. i moved it to eet to make it more efficient for config file size etc. # echo -en "str\0fb\0" ewl/evas/render_method # eet -c config.eet ewl no no :) eet is just a test/debug tool. not intended for creating/editing eet's. eet's are really only editable via the api in c. u'd make a tool to do it. you could only create eet's via ecore_config's api. the api will define what defaults are and so ecore_config will end up writing that out. it'd be possible to make a quick tool to generate/modify these files though using the api's :) Shall I take the bait? (ponders...) moot point by now :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] DR17+EFL will be in Fedora Core Extras repository :)
On Wed, 25 May 2005 11:23:33 +0800 Didier Casse [EMAIL PROTECTED] babbled: Hi all, I'm pleased to announce that I've been sponsored by Tom 'spot' Callaway (from RedHat) to push DR17+EFL in the Fedora Core Extras repository. I've been granted CVS access to it. I've yet to go for a formal review process of my packages. Well I've got to cleanup the packages first. But the important thing is that we made a step forward. If everything goes well with proper timing, DR17 should be available for FC4 users directly from Yum. i.e. the extras would be enable by default in the FC4 /etc/yum.conf file. cool :) nice nice. all happy. Ignacio Vazquez-Abrams have previously been pulling edb and eet into the FC extras. And he also proposed to somehow coordinate with me now to move forward. weird - why just edb and eet? -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] DR17+EFL will be in Fedora Core Extras repository :)
On Wed, 2005-06-01 at 08:04 +0900, Carsten Haitzler wrote: On Wed, 25 May 2005 11:23:33 +0800 Didier Casse [EMAIL PROTECTED] babbled: Ignacio Vazquez-Abrams have previously been pulling edb and eet into the FC extras. And he also proposed to somehow coordinate with me now to move forward. weird - why just edb and eet? Because there's only 24 hours in a day, and I'd rather package them properly than haphazardly. -- Ignacio Vazquez-Abrams [EMAIL PROTECTED] http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 signature.asc Description: This is a digitally signed message part
[E-devel] Announceing Extortion 0.05.01
Announcing Extortion 0.05.01. So, what is extortion? Well, its a little programming contest for the EWL. There are four categories (bugs, feature, graphics and overall), with the winner in each category getting a prize. For the bugs, feature and graphics section the prize is a tshirt with the category logo on the back. For the overall section the prize is either a tshirt or hoodie with the category logo on the back. For more information on Extortion, please take a look at: http://edevelop.org/extortion. Thanks, dan --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] DR17+EFL will be in Fedora Core Extras repository :)
On Tue, 31 May 2005 19:36:47 -0400 Ignacio Vazquez-Abrams [EMAIL PROTECTED] babbled: On Wed, 2005-06-01 at 08:04 +0900, Carsten Haitzler wrote: On Wed, 25 May 2005 11:23:33 +0800 Didier Casse [EMAIL PROTECTED] babbled: Ignacio Vazquez-Abrams have previously been pulling edb and eet into the FC extras. And he also proposed to somehow coordinate with me now to move forward. weird - why just edb and eet? Because there's only 24 hours in a day, and I'd rather package them properly than haphazardly. but if nothing depends on them... why package them? :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] DR17+EFL will be in Fedora Core Extras repository :)
On Wed, 2005-06-01 at 09:52 +0900, Carsten Haitzler wrote: On Tue, 31 May 2005 19:36:47 -0400 Ignacio Vazquez-Abrams [EMAIL PROTECTED] babbled: On Wed, 2005-06-01 at 08:04 +0900, Carsten Haitzler wrote: On Wed, 25 May 2005 11:23:33 +0800 Didier Casse [EMAIL PROTECTED] babbled: Ignacio Vazquez-Abrams have previously been pulling edb and eet into the FC extras. And he also proposed to somehow coordinate with me now to move forward. weird - why just edb and eet? Because there's only 24 hours in a day, and I'd rather package them properly than haphazardly. but if nothing depends on them... why package them? :) Because my eventual goal _was_ to get e17 into Extras. -- Ignacio Vazquez-Abrams [EMAIL PROTECTED] http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 signature.asc Description: This is a digitally signed message part
Re: Re: [E-devel] Memory module - new version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03:18, Sat 28 May 05, gimpel wrote: From: gimpel [EMAIL PROTECTED] To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] Memory module - new version X-Y-GMX-Trusted: 0 STUFF ... Yo gimpel, your public key isn't getting found here. Could you consider exporting it to a more commonly known pgp keyserver? gpg --keyserver pgp.mit.edu --send-key yourkeyhere Here are a few servers that will work as well. keyserver certserver.pgp.com keyserver pgp.ai.mit.edu Thanks - -- -- Ap Mechans Thes .-.Stephen Horner void.engineer(at)unix.net /v\AIMbeepbeepkaah // \\ MSNparse3rr0r(at)hotmail.com /( )\ PGP0xCDC2DD2B ^^-^^ - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCnQvNRRkTWiD8QjIRAoW0AJwMesUT/MfpndJngy4LZtncBip1kQCdFGHH KxCBKeuzfW7JhmFaezYwhas= =cfSZ -END PGP SIGNATURE- --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Memory module - new version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen Horner wrote: Yo gimpel, your public key isn't getting found here. Could you consider exporting it to a more commonly known pgp keyserver? gpg --keyserver pgp.mit.edu --send-key yourkeyhere Here are a few servers that will work as well. keyserver certserver.pgp.com keyserver pgp.ai.mit.edu Thanks I got it fine from pgp server: random.sks.keyserver.penguin.de PS: Started using e17 yesterday, love it! Subscribed so I can see if there is anything I can help with, though I havent done C in a while :-/ - -- Matt Lyons (B.CS SE) Analyst Programmer, Internode Systems Level 3, 132 Grenfell St, Adelaide SA 5000 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCnQ2uLuMxjpa11VERAlYtAJ95OTWfY9wjlmTVRmYAcM/RFKuheQCfXU5g 97daQ2Ja76NEFugMFEMNZBo= =CHPb -END PGP SIGNATURE- --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] DR17+EFL will be in Fedora Core Extras repository :)
On Tue, 31 May 2005 21:01:50 -0400 Ignacio Vazquez-Abrams [EMAIL PROTECTED] babbled: On Wed, 2005-06-01 at 09:52 +0900, Carsten Haitzler wrote: On Tue, 31 May 2005 19:36:47 -0400 Ignacio Vazquez-Abrams [EMAIL PROTECTED] babbled: On Wed, 2005-06-01 at 08:04 +0900, Carsten Haitzler wrote: On Wed, 25 May 2005 11:23:33 +0800 Didier Casse [EMAIL PROTECTED] babbled: Ignacio Vazquez-Abrams have previously been pulling edb and eet into the FC extras. And he also proposed to somehow coordinate with me now to move forward. weird - why just edb and eet? Because there's only 24 hours in a day, and I'd rather package them properly than haphazardly. but if nothing depends on them... why package them? :) Because my eventual goal _was_ to get e17 into Extras. aaah! :) cool! :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] DR17+EFL will be in Fedora Core Extras repository :)
On Tue, 31 May 2005 23:35:21 -0400 Mike Frysinger [EMAIL PROTECTED] babbled: On Tuesday 31 May 2005 10:32 pm, Carsten Haitzler wrote: On Tue, 31 May 2005 21:15:19 -0400 Mike Frysinger [EMAIL PROTECTED] babbled: On Tuesday 31 May 2005 08:52 pm, Carsten Haitzler wrote: On Tue, 31 May 2005 19:36:47 -0400 Ignacio Vazquez-Abrams [EMAIL PROTECTED] babbled: On Wed, 2005-06-01 at 08:04 +0900, Carsten Haitzler wrote: On Wed, 25 May 2005 11:23:33 +0800 Didier Casse [EMAIL PROTECTED] babbled: Ignacio Vazquez-Abrams have previously been pulling edb and eet into the FC extras. And he also proposed to somehow coordinate with me now to move forward. weird - why just edb and eet? Because there's only 24 hours in a day, and I'd rather package them properly than haphazardly. but if nothing depends on them... why package them? :) edb has been around for a while ... we've had a bunch of packages in Gentoo utilize it before e17 was ever packaged up -mike e projects? or others? just curious :) e16 related stuff, a p2p program ... iirc, some gnome stuff used to use it too ... someone wrote a backend for portage using edb but it has no reason to move forward... it worked! did everything it was every intended to do! :) oh well :) interesting. so others were using it. cool :) i think when edb sat at like 1.0.3 forever, people started moving away from it -mike --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] DR17+EFL will be in Fedora Core Extras repository :)
On Tue, 2005-05-31 at 21:15 -0400, Mike Frysinger wrote: On Tuesday 31 May 2005 08:52 pm, Carsten Haitzler wrote: On Tue, 31 May 2005 19:36:47 -0400 Ignacio Vazquez-Abrams [EMAIL PROTECTED] babbled: On Wed, 2005-06-01 at 08:04 +0900, Carsten Haitzler wrote: On Wed, 25 May 2005 11:23:33 +0800 Didier Casse [EMAIL PROTECTED] babbled: Ignacio Vazquez-Abrams have previously been pulling edb and eet into the FC extras. And he also proposed to somehow coordinate with me now to move forward. weird - why just edb and eet? Because there's only 24 hours in a day, and I'd rather package them properly than haphazardly. but if nothing depends on them... why package them? :) edb has been around for a while ... we've had a bunch of packages in Gentoo utilize it before e17 was ever packaged up edb and eet are *great* general-purpose libraries. I was going to put ecore in next before Didier came along. -- Ignacio Vazquez-Abrams [EMAIL PROTECTED] http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 signature.asc Description: This is a digitally signed message part
Re: [E-devel] DR17+EFL will be in Fedora Core Extras repository :)
On 6/1/05, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Wed, 25 May 2005 11:23:33 +0800 Didier Casse [EMAIL PROTECTED] babbled: Hi all, I'm pleased to announce that I've been sponsored by Tom 'spot' Callaway (from RedHat) to push DR17+EFL in the Fedora Core Extras repository. I've been granted CVS access to it. I've yet to go for a formal review process of my packages. Well I've got to cleanup the packages first. But the important thing is that we made a step forward. If everything goes well with proper timing, DR17 should be available for FC4 users directly from Yum. i.e. the extras would be enable by default in the FC4 /etc/yum.conf file. cool :) nice nice. all happy. But there's a bad news to it also. Instead of saying EFLs, I should now say some EFLs. :-( emotion BuildRequires /usr/bin/xine-config which is provided in FC by the package xine-lib-devel. Well this xine-lib-devel or xine-lib or associated package libfame is NOT and will NOT get into either Fedora Core CDs or FC extras repository due to legal/patent issues. It means that apps that depend on emotion or BuildRequires: emotion-devel will not make it to FC extras and still has to stay in a 3rd party repository. So stuff like eclair.spec emotion.spec engage.spec e_utils.spec ewl.spec examine.spec will not make it to FC extras unless BuildRequires: emotion-devel becomes optional. But so far when i removed the emotion-devel Build Requirement, the above packages (bar emotion of course) failed to compile. -- With kind regards, Didier. Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] DR17+EFL will be in Fedora Core Extras repository :)
On Wed, 2005-06-01 at 13:25 +0800, Didier Casse wrote: emotion BuildRequires /usr/bin/xine-config which is provided in FC by the package xine-lib-devel. Well this xine-lib-devel or xine-lib or associated package libfame is NOT and will NOT get into either Fedora Core CDs or FC extras repository due to legal/patent issues. This could be mitigated by moving to gstreamer or providing the ability to use gstreamer as a backend (as totem does). -- Ignacio Vazquez-Abrams [EMAIL PROTECTED] http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 signature.asc Description: This is a digitally signed message part
