Re: [E-devel] improvements of configure
On Fri, 5 Oct 2007 13:21:27 +0200 Albin Tonnerre <[EMAIL PROTECTED]> babbled: > On Fri, Oct 05, 2007 at 03:10:08PM +0900, Carsten Haitzler wrote : > > On Mon, 1 Oct 2007 20:07:41 +0200 Albin Tonnerre <[EMAIL PROTECTED]> > > babbled: > > > > > > > > While we're talking about configure... :) > > > I'm part of the team which packages E for debian, and there's something in > > > configure we'd really like to see changed (and of course we can provide > > > patches): > > > What we think is that when you enable a feature with > > > --enable-whatever, and if the requirements of that feature are not found, > > > configure should fail rather than silently disable it. > > > The rationale for that is that, in our humble opinions, when you package > > > for a distro, you want the stuff you enable to be actually present - > > > thus, fail if not found rather than disable and tell nothing. > > > As per discussion with raster on irc, I'm sure that some people may not > > > want this behavior, and thus thought we could possibly add a > > > --whatever-name-we-could-call-it , which implements such behavior (and > > > let the default as it is) > > > > > > Thoughts ? (hint: 'this is your distro's problem" is not a valid answer) > > > > we like our soft fallback so our build scripts can blindly run and adapt to > > system features :) this is a difference in philosophy i guess. do you take > > an error as a hard error - or a soft error. we go for soft. that's because > > we're all warm and fuzzy at heart! :) > > > > That's why my proposal wasn't to make such a behavior a default, but an > alternative :) we could - with a --enable-strict-dependencies or something... but then we'd have to go do something... got patches? :) (me - i've only got milk). > Regards > > > > Regards, > > > Albin Tonnerre > > > > > > On Sun, Sep 30, 2007 at 03:01:32PM -0700, Michael Jennings wrote : > > > > On Sunday, 30 September 2007, at 16:04:54 (+0200), > > > > Vincent Torri wrote: > > > > > > > > > Since I try to port the efl on windows, I've run into some problems > > > > > with autofoo (strange, isn't it ?). I've looked a bit at autoconf and > > > > > libtool doc, and I think that configure.in scripts can be improved a > > > > > bit. > > > > > > > > > > Here is what I propose. Feel free to tell me if my proposals are not > > > > > correct. > > > > > > > > > > ... > > > > > > > > > > Ideas ? remarks ? > > > > > > > > Most of that sounds fine, but why not provide us with a sample > > > > configure.in with examples of all 5 changes made to it so we can get a > > > > more concrete idea of what you're wanting to do? Then if people have > > > > any specific objections, they're easier to note. > > > > > > > > Michael > > > > > > > > -- > > > > Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL > > > > PROTECTED]> > > > > Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) > > > > --- > > > > "I am the one and only; nobody I'd rather be. I am the one and only. > > > > You can't take that away from me." -- Chesney Hawkes > > > > > > > > - > > > > This SF.net email is sponsored by: Microsoft > > > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > > > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > > > > ___ > > > > enlightenment-devel mailing list > > > > enlightenment-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > -- > > > Albin Tonnerre, aka Lutin > > > - Search a little longer, travel a little further > > > > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] > > 裸好多 > > Tokyo, Japan (東京 日本) > > -- > Albin Tonnerre, aka Lutin > - Search a little longer, travel a little further > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: improvements of configure
On Fri, 5 Oct 2007, Carsten Haitzler (The Rasterman) wrote: > On Tue, 2 Oct 2007 18:31:34 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> > babbled: > > ok- looking at the patch gives me meat to chew on :) overall this looks good. > i'm a little dubious of the whole libtool version thing - i actually HATE it. > i'd prefer the libtool revision/version/whatever stuff is sourced/generated > from the package itself (eg 0.5.0 for edje) and we will increment this ONE > version info only. i know what major and minor versions mean - most developers > do/should so i'd rather have a single version tag there if possible - all the > space used up by the libtool scheme comments could work on some script mojo to > work out the libtool version magic from the package version. i really want to > keep them consistent at all times if possible. thats my only issue - otherwise > it seems ok to me. ok so, about libtool : 1) I remove the big doc 2) from the package version (minor, major, micro), i create: version_info = ($major + $minor):$micro:$minor I know that ewl does not use that libtool behavio, so I'll not change libtool version info in ewl, but I'll do the other modifications I plan to add AC_LIBTOOL_WIN32_DLL to the following libraries in libs/ : eet, evas, ecore, embryo, edje, efreet, etk and ewl. I'll maybe add it later for emotion (when the evas sink will be finished), epeg and epsilon. I plan to do the other changes for all libs in libs/ except: edb, estyle, etox, evoak and ewd, as they are not maintained anymore Should I modify imlib2 ? Is it good for everyone ? (Especially etk maintainers, as they might not want that libtool version scheme). I'll look at proto/ and apps/ later Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: improvements of configure
On Fri, 5 Oct 2007 15:05:50 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> babbled: > > > On Fri, 5 Oct 2007, Carsten Haitzler (The Rasterman) wrote: > > > On Tue, 2 Oct 2007 18:31:34 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> > > babbled: > > > > ok- looking at the patch gives me meat to chew on :) overall this looks > > good. i'm a little dubious of the whole libtool version thing - i actually > > HATE it. i'd prefer the libtool revision/version/whatever stuff is > > sourced/generated from the package itself (eg 0.5.0 for edje) and we will > > increment this ONE version info only. i know what major and minor versions > > mean - most developers do/should so i'd rather have a single version tag > > there if possible - all the space used up by the libtool scheme comments > > could work on some script mojo to work out the libtool version magic from > > the package version. i really want to keep them consistent at all times if > > possible. thats my only issue - otherwise it seems ok to me. > > ok > > so, about libtool : > > 1) I remove the big doc > 2) from the package version (minor, major, micro), i create: > > version_info = ($major + $minor):$micro:$minor > > I know that ewl does not use that libtool behavio, so I'll not change > libtool version info in ewl, but I'll do the other modifications > > I plan to add AC_LIBTOOL_WIN32_DLL to the following libraries in libs/ : > > eet, evas, ecore, embryo, edje, efreet, etk and ewl. I'll maybe add it > later for emotion (when the evas sink will be finished), epeg and epsilon. > > I plan to do the other changes for all libs in libs/ except: > > edb, estyle, etox, evoak and ewd, as they are not maintained anymore > > Should I modify imlib2 ? yeah - modify that. imlib2 is on life support basically - but no development. > Is it good for everyone ? (Especially etk maintainers, as they might not > want that libtool version scheme). > > I'll look at proto/ and apps/ later for now lets do this with 1 package that covers most things and let that settle. if no one reports major breaks then make the same changes to others. for example do edje - it produces binaries and libs (no modules though) and you already mailed a patch - put changes in there, let it settle for 2 or 3 weeks - if all is well, do the rest? > Vincent > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: {Spam?} Re: improvements of configure
On Fri, 5 Oct 2007, Carsten Haitzler (The Rasterman) wrote: > On Fri, 5 Oct 2007 15:05:50 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> > babbled: > > for now lets do this with 1 package that covers most things and let that > settle. if no one reports major breaks then make the same changes to others. > for example do edje - it produces binaries and libs (no modules though) and > you > already mailed a patch - put changes in there, let it settle for 2 or 3 weeks > - if all is well, do the rest? ok Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Selective build of modules for evas/ecore
On Fri, Oct 05, 2007 at 11:28:28AM +0900, Carsten Haitzler wrote : > On Sun, 2 Sep 2007 21:16:31 +0200 Albin Tonnerre <[EMAIL PROTECTED]> babbled: > > > On Sat, Aug 25, 2007 at 12:43:28PM +0900, Carsten Haitzler wrote : > > > On Tue, 14 Aug 2007 16:50:09 -0300 "Gustavo Sverzut Barbieri" > > > <[EMAIL PROTECTED]> babbled: > > > > > > > Hi, > > > > > > > > I want to package e17 for maemo the "proper way" (so far I'm creating > > > > .deb with tar + ar and a custom shell script), but I'd like to disable > > > > build of some subpackages, like every evas engine other than > > > > software-x11 and software-16-x11 (which is not built right now). > > > > > > > > Maybe we could have a way to select which packages to generate? > > > > > > > > PS: May I add software-16-x11 to the list of build modules? > > > > > > sure - though really the debian or rpm packaging info is intended as a > > > SAMPLE for packagers to build off - to show them how best to package and > > > then add all the little bits their distribution demands or needs. it's a > > > starting point rather than an end point - IMHO. :) > > > > > > > About that Now that there is a team dedicated to package enlightenment > > for > > debian, is there really a point maintaining the debian/ dir *in* E's CVS ? I > > mean, this is generally seen as a bad practice in debian to have debian/ > > dirs > > bad in debian - not bad for us. basically it is meant to be: > > 1. an easy way for upstream to package themselves if they want. I'm quite dubious about the fact they'd want to package what they're developping (during the devel process). Just too much overhead to rebuild the package everytime you change something > 2. a template/example of how to package for packagers (how to plit things up, > what files to include or not include in packages (eg module .la and .a files > are pointless so don't keep them), other special things (some binaries e > produces are suid-root and so the packages need to reflect that, if they don't > things won't work like cpufreq, system reboot/shutdown etc.). > > you, as a packager are free to strip this out or follow it, but it is your > distribution, but this is our source - and we are giving a helping hand to you > guys in many ways this way as per above. > While this might help, they don't necessary belong to the source folder. If the packagers want exemples, easy enough for them to checkout the trees from a dedicated branch on the cvs. I understand that you want to provide samples etc, but as there are already ubuntu and debian repos available, I'm not quite sure that it is used by any user at all (of course falko uses them for the debian repo, but still), and it's mostly why I believe that moving them out of the sources wouldn't hurt much > > provided with upstream sources. As long as users now where the can grab the > > debian tree, wouldn't it possible to maintain it outside cvs ? > > Cheers > > in my experience, packagers of e have generally done a poor job (no offense > intended). they have modified things, broken things, and left things in an > inconsistent state (eg modifying e16 defaults but never updating the runtime > help docs for starters). there have been other numerous mis-packagings of libs > like evas which is modular, but keeping modules in the same package instead of > splitting them out as separate packages that should be depended on not by > evas, > but by apps if they require certain engines/loaders etc. I can't remember having ever distributed evas as a single package since I started maintaining the ubuntu packaging a year back. While I understand that you experienced issues with various packagers, please keep in mind that it's not because some of them don't things the way they should be that every single packager does. Either ways, a good communication upstream <-> packging will be better than forcing packagers into doing things, and making their job harder (yes, keeping debian/ in the sources make our job harder. surprising isn't it ?) Regards > > > Albin Tonnerre > > > > > > -- > > > > Gustavo Sverzut Barbieri > > > > -- > > > > Jabber: [EMAIL PROTECTED] > > > >MSN: [EMAIL PROTECTED] > > > > ICQ#: 17249123 > > > > Skype: gsbarbieri > > > > Mobile: +55 (81) 9927 0010 > > > > > > > > - > > > > This SF.net email is sponsored by: Splunk Inc. > > > > Still grepping through log files to find problems? Stop. > > > > Now Search log events and configuration files using AJAX and a browser. > > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > > ___ > > > > 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"
[E-devel] Nightly build log for E17 on 2007-10-05 07:03:31 -0700
Build log for Enlightenment DR 0.17 on 2007-10-05 07:03:31 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: eflpp http://download.enlightenment.org/tests/logs/eflpp.log engage http://download.enlightenment.org/tests/logs/engage.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, cpu, deskshow, eclair, ecore, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emu, engrave, engycad, enhance, enity, enterminus, enthrall, entice, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, exhibit, exml, expedite, express, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, net, news, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas raster
On 10/5/07, Enlightenment CVS <[EMAIL PROTECTED]> wrote: > Enlightenment CVS committal > > Author : raster > Project : e17 > Module : libs/evas > > Dir : e17/libs/evas/src/modules/engines/software_sdl > > > Modified Files: > evas_engine.c > > > Log Message: > > > cedric's sdl patch. Ops! You re-applied it, I applied but changed memset() by SDL_FillRect() to avoid problems with different depths and boundaries... I'll revert. > SDL_FillRect(re->surface, NULL, 0); > > + memset(re->surface->pixels, 0, w * h * 4); > + see the SDL_FillRect() does the same as memset() -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_Con
On 10/5/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Mon, 17 Sep 2007 10:29:54 +0200 Cedric BAIL <[EMAIL PROTECTED]> babbled: > > OK - i'm now catching up on my email/patches/whatever > > so got an updated patch? gustavo's comments are valid and good ones :) he fixed, uploaded to bugzilla and I've committed them already. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_evas_object_cursor_set
On 10/5/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Sat, 15 Sep 2007 20:27:21 +0200 Cedric BAIL <[EMAIL PROTECTED]> babbled: > > > Last pending patch on my disk :) > > > > I quickly looked inside etk and see that it was not using > > ecore_evas_cursor_set with framebuffer engine, because it wanted to set a > > icon from an edje file. And in fact if we want to set an edje object as a > > cursor we can't. Even if the code permit it. > > So I propose to add ecore_evas_object_cursor_set to directly set any > > evas_object as a cursor and modify ecore_evas_cursor_set to build itself the > > evas_object_image. As a border effect, it reduce per ecore_evas engine > > specific code. > > This patch break ecore_evas_cursor_get API, but no real apps are > > using it inside e17 cvs. > > hmmm - sounds good in principle. i'm torn between breaking the api (minor > though the break is) and just adding a new call to set the pointer to an evas > object so both work. too late, it's in cvs now. If you want to keep the old API, we can still check for type == image and then return the file_get()[0], with another call to retrieve the object. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Selective build of modules for evas/ecore
On Fri, 5 Oct 2007 15:39:46 +0200 Albin Tonnerre <[EMAIL PROTECTED]> babbled: > On Fri, Oct 05, 2007 at 11:28:28AM +0900, Carsten Haitzler wrote : > > On Sun, 2 Sep 2007 21:16:31 +0200 Albin Tonnerre <[EMAIL PROTECTED]> > > babbled: > > > > > On Sat, Aug 25, 2007 at 12:43:28PM +0900, Carsten Haitzler wrote : > > > > On Tue, 14 Aug 2007 16:50:09 -0300 "Gustavo Sverzut Barbieri" > > > > <[EMAIL PROTECTED]> babbled: > > > > > > > > > Hi, > > > > > > > > > > I want to package e17 for maemo the "proper way" (so far I'm creating > > > > > .deb with tar + ar and a custom shell script), but I'd like to disable > > > > > build of some subpackages, like every evas engine other than > > > > > software-x11 and software-16-x11 (which is not built right now). > > > > > > > > > > Maybe we could have a way to select which packages to generate? > > > > > > > > > > PS: May I add software-16-x11 to the list of build modules? > > > > > > > > sure - though really the debian or rpm packaging info is intended as a > > > > SAMPLE for packagers to build off - to show them how best to package and > > > > then add all the little bits their distribution demands or needs. it's a > > > > starting point rather than an end point - IMHO. :) > > > > > > > > > > About that Now that there is a team dedicated to package > > > enlightenment for debian, is there really a point maintaining the debian/ > > > dir *in* E's CVS ? I mean, this is generally seen as a bad practice in > > > debian to have debian/ dirs > > > > bad in debian - not bad for us. basically it is meant to be: > > > > 1. an easy way for upstream to package themselves if they want. > > I'm quite dubious about the fact they'd want to package what they're > developping (during the devel process). Just too much overhead to rebuild the > package everytime you change something no - we wouldnt build packages every time we compile something and run it - but we may use it for weekly or monthly snapshots etc. > > 2. a template/example of how to package for packagers (how to plit things > > up, what files to include or not include in packages (eg module .la and .a > > files are pointless so don't keep them), other special things (some > > binaries e produces are suid-root and so the packages need to reflect that, > > if they don't things won't work like cpufreq, system reboot/shutdown etc.). > > > > you, as a packager are free to strip this out or follow it, but it is your > > distribution, but this is our source - and we are giving a helping hand to > > you guys in many ways this way as per above. > > > > While this might help, they don't necessary belong to the source folder. If > the packagers want exemples, easy enough for them to checkout the trees from > a dedicated branch on the cvs. > I understand that you want to provide samples etc, but as there are > already ubuntu and debian repos available, I'm not quite sure that it is used > by any user at all (of course falko uses them for the debian repo, but > still), and it's mostly why I believe that moving them out of the sources > wouldn't hurt much i believe it would hurt. there are other distributions about. we provide an "official" example of packaging. if your distro policies demand it not be there then you need to remove it yourselves. > > > provided with upstream sources. As long as users now where the can grab > > > the debian tree, wouldn't it possible to maintain it outside cvs ? > > > Cheers > > > > in my experience, packagers of e have generally done a poor job (no offense > > intended). they have modified things, broken things, and left things in an > > inconsistent state (eg modifying e16 defaults but never updating the runtime > > help docs for starters). there have been other numerous mis-packagings of > > libs like evas which is modular, but keeping modules in the same package > > instead of splitting them out as separate packages that should be depended > > on not by evas, but by apps if they require certain engines/loaders etc. > > I can't remember having ever distributed evas as a single package since I > started maintaining the ubuntu packaging a year back. older deb and rpm packages did. until we actually updated and fixed al the in-cvs packaging info. > While I understand that you experienced issues with various packagers, please > keep in mind that it's not because some of them don't things the way they > should be that every single packager does. Either ways, a good communication > upstream <-> packging will be better than forcing packagers into doing things, > and making their job harder (yes, keeping debian/ in the sources make our job > harder. surprising isn't it ?) yes - it does seem amazing. i definitely don't want it out of cvs - but i'd be willing to compromise and not have it disted into the tarballs. so when we ship release tarballs (do a make dist) you wont have it in the tarball. nwe will keep the .spec file for rpm's and no rpm distro maintainers have no policies regard
Re: [E-devel] ecore_evas_object_cursor_set
On Fri, 5 Oct 2007 11:48:05 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled: > On 10/5/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > > On Sat, 15 Sep 2007 20:27:21 +0200 Cedric BAIL <[EMAIL PROTECTED]> > > babbled: > > > > > Last pending patch on my disk :) > > > > > > I quickly looked inside etk and see that it was not using > > > ecore_evas_cursor_set with framebuffer engine, because it wanted to set a > > > icon from an edje file. And in fact if we want to set an edje object as a > > > cursor we can't. Even if the code permit it. > > > So I propose to add ecore_evas_object_cursor_set to directly set any > > > evas_object as a cursor and modify ecore_evas_cursor_set to build itself > > > the evas_object_image. As a border effect, it reduce per ecore_evas engine > > > specific code. > > > This patch break ecore_evas_cursor_get API, but no real apps are > > > using it inside e17 cvs. > > > > hmmm - sounds good in principle. i'm torn between breaking the api (minor > > though the break is) and just adding a new call to set the pointer to an > > evas object so both work. > > too late, it's in cvs now. If you want to keep the old API, we can > still check for type == image and then return the file_get()[0], with > another call to retrieve the object. as i said i'm torn. let's leave it :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas raster
On Fri, 5 Oct 2007 11:14:45 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled: > On 10/5/07, Enlightenment CVS <[EMAIL PROTECTED]> wrote: > > Enlightenment CVS committal > > > > Author : raster > > Project : e17 > > Module : libs/evas > > > > Dir : e17/libs/evas/src/modules/engines/software_sdl > > > > > > Modified Files: > > evas_engine.c > > > > > > Log Message: > > > > > > cedric's sdl patch. > > Ops! You re-applied it, I applied but changed memset() by > SDL_FillRect() to avoid problems with different depths and > boundaries... I'll revert. bizarre - it applied without conflicts/rejects! > > > SDL_FillRect(re->surface, NULL, 0); > > > > + memset(re->surface->pixels, 0, w * h * 4); > > + > > see the SDL_FillRect() does the same as memset() > > > > -- > Gustavo Sverzut Barbieri > -- > Jabber: [EMAIL PROTECTED] >MSN: [EMAIL PROTECTED] > ICQ#: 17249123 > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_Con
On Fri, 5 Oct 2007 11:46:35 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled: > On 10/5/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > > On Mon, 17 Sep 2007 10:29:54 +0200 Cedric BAIL <[EMAIL PROTECTED]> > > babbled: > > > > OK - i'm now catching up on my email/patches/whatever > > > > so got an updated patch? gustavo's comments are valid and good ones :) > > he fixed, uploaded to bugzilla and I've committed them already. aaah cool - strike that one off my list then :) > > -- > Gustavo Sverzut Barbieri > -- > Jabber: [EMAIL PROTECTED] >MSN: [EMAIL PROTECTED] > ICQ#: 17249123 > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Friday, 05 October 2007, at 15:17:19 (+0900), Carsten Haitzler wrote: > ok- looking at the patch gives me meat to chew on :) overall this > looks good. i'm a little dubious of the whole libtool version thing > - i actually HATE it. i'd prefer the libtool > revision/version/whatever stuff is sourced/generated from the > package itself (eg 0.5.0 for edje) and we will increment this ONE > version info only. i know what major and minor versions mean - most > developers do/should so i'd rather have a single version tag there > if possible - all the space used up by the libtool scheme comments > could work on some script mojo to work out the libtool version magic > from the package version. i really want to keep them consistent at > all times if possible. thats my only issue - otherwise it seems ok > to me. The problem is, this is simply not the way shared library versioning works. The dynamic linker has specific ideas about how to tell which shared libraries will work with which executables based on the soversion, and your way of thinking about it violates that. There is absolutely no reason why, for example, an app linked against Imlib2 1.3.0 cannot continue to work (albeit improved) with 1.3.1 unless the ABI changes. That's why if you properly follow the libtool guidelines previously mentioned, you'll have to rebuild your binaries if, and only if, the shared library interface actually changes. If, however, you have a shared library that really DOES need to be tied to a specific version of the package (like libEterm is tied to each version of Eterm, for obvious reasons), instead of using "-version-info X:Y:Z" use "-release $(VERSION)". That is the accepted libtool way of doing what you want without wreaking havoc on poor defenseless ld.so. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "But I dumped her. My motto is, 'Get out before they go down.'" "That is so *not* my motto." -- Monica Geller and Joey Tribbiani, "Friends" - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Fri, 5 Oct 2007 09:35:31 -0700 Michael Jennings <[EMAIL PROTECTED]> babbled: > On Friday, 05 October 2007, at 15:17:19 (+0900), > Carsten Haitzler wrote: > > > ok- looking at the patch gives me meat to chew on :) overall this > > looks good. i'm a little dubious of the whole libtool version thing > > - i actually HATE it. i'd prefer the libtool > > revision/version/whatever stuff is sourced/generated from the > > package itself (eg 0.5.0 for edje) and we will increment this ONE > > version info only. i know what major and minor versions mean - most > > developers do/should so i'd rather have a single version tag there > > if possible - all the space used up by the libtool scheme comments > > could work on some script mojo to work out the libtool version magic > > from the package version. i really want to keep them consistent at > > all times if possible. thats my only issue - otherwise it seems ok > > to me. > > The problem is, this is simply not the way shared library versioning > works. The dynamic linker has specific ideas about how to tell which > shared libraries will work with which executables based on the > soversion, and your way of thinking about it violates that. There is > absolutely no reason why, for example, an app linked against Imlib2 > 1.3.0 cannot continue to work (albeit improved) with 1.3.1 unless the > ABI changes. That's why if you properly follow the libtool guidelines > previously mentioned, you'll have to rebuild your binaries if, and > only if, the shared library interface actually changes. i know how it works :) i just don't want to work with libtool's abortion of a versioning system. i want to do it the old fashioned way. .so major version changes == abi break. old calls removed or changed abi or functionality. minor version == calls added, but no functionality changes in existing calls. micro == no calls added or removed, no functionality changes, just internal fixes/improvements. i want to keep the version of the package the same as the lib .so version. it's cleaner and nicer. unless we go screw things up and decide to name release versions without thought to compatibility - then we need to do the below, but if we do things right, we don't need to. if i break abi i will cal the package evas-2.0.0.tar.gz (or whatever) as opposed to 1.0.0. i will make the package release # the same as the lib .so version as needed. > If, however, you have a shared library that really DOES need to be > tied to a specific version of the package (like libEterm is tied to > each version of Eterm, for obvious reasons), instead of using > "-version-info X:Y:Z" use "-release $(VERSION)". That is the accepted > libtool way of doing what you want without wreaking havoc on poor > defenseless ld.so. nooo - i don't want to make a new .so for each version with -release. there is no need to put the link version directly in the library name. i ONLY need to do this if i plan on having 2 or more versions of the lib around AND application needing to explicitly link at compile time to either a newer or older version. eg. gtk2 vs gtk1. (at that point - mayaswell have new lib names too as the version is now part of the lib name anyway as far as ld.so etc. are concerned). > Michael > > -- > Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> > Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) > --- > "But I dumped her. My motto is, 'Get out before they go down.'" > "That is so *not* my motto." > -- Monica Geller and Joey Tribbiani, "Friends" > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Selective build of modules for evas/ecore
On Friday, 05 October 2007, at 15:39:46 (+0200), Albin Tonnerre wrote: > I'm quite dubious about the fact they'd want to package what they're > developping (during the devel process). Just too much overhead to > rebuild the package everytime you change something Talk about being hypocritical! You're USING software that's in development, and you're PACKAGING it too! What is it that gives a packager some unalienable right to package up development software and yet somehow fails to give the authors themselves that very same right? :-P > While this might help, they don't necessary belong to the source > folder. If the packagers want exemples, easy enough for them to > checkout the trees from a dedicated branch on the cvs. The packaging info belongs with the source. That's where it's been since the very earliest days when bma was doing our Debian packages, and there's no reason at all for them to not stay. > I understand that you want to provide samples etc, but as there are > already ubuntu and debian repos available, I'm not quite sure that > it is used by any user at all (of course falko uses them for the > debian repo, but still), and it's mostly why I believe that moving > them out of the sources wouldn't hurt much If they really bother you that much, "cvs remove" them from your anonymous checkout or write yourself a little wrapper script. :-) > I can't remember having ever distributed evas as a single package > since I started maintaining the ubuntu packaging a year back. Just because you didn't make a particular mistake means neither that you haven't made others (not accusing...I have no idea...just making the point) nor that others haven't made them. We make mistakes ourselves as well. But we (collectively, not me in particular) have the advantages of having been doing Debian packaging for a very long time and having made, corrected, and learned from numerous errors in that time. > While I understand that you experienced issues with various > packagers, please keep in mind that it's not because some of them > don't things the way they should be that every single packager does. The problem is not that some or all packagers do things in any particular (or right, or wrong) way. That's not the issue. The simple fact is this: We keep RPM spec files in CVS because developers (like me) and others like to be able to build RPM packages directly from the CVS repository. (It doesn't get much easier than "./autogen.sh && make distcheck && mzbuild" IMHO.) We keep Debian packaging directories in the same place for the same reason. We will continue to do so because it makes things easier and better for us, the developers. CVS is *our* territory; it does not belong to end users, packagers, distribution maintainers, or anyone else, as we've been saying over and over again for years. CVS is a developer tool, not a user tool. > Either ways, a good communication upstream <-> packging will be > better than forcing packagers into doing things, and making their > job harder (yes, keeping debian/ in the sources make our job > harder. surprising isn't it ?) Sorry, but if keeping one little directory in CVS makes your job harder, you're doing it wrong. It's painfully easy to use various combinations of "rm," "cvs rm," and "$EDITOR" to perform whatever changes you deem necessary to your local copy of any tree you choose. :-) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "When all is said and all has come undone; when the sun, the moon, and stars grow dark; before the days of youth are left in vain; before the dust reclaims its own again. Breathe on me, breathe oh breath of God. Breathe on me till my heart is new." -- Newsboys - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Saturday, 06 October 2007, at 01:50:06 (+0900), Carsten Haitzler wrote: > i know how it works :) i just don't want to work with libtool's > abortion of a versioning system. i want to do it the old fashioned > way. .so major version changes == abi break. old calls removed or > changed abi or functionality. minor version == calls added, but no > functionality changes in existing calls. micro == no calls added or > removed, no functionality changes, just internal fixes/improvements. That's really how it works already, or at least pretty close. The middle number is micro, so if anything at all changes, you bump the middle number. If you add new API calls, you increment BOTH the first and third number; this will keep the major soversion the same and bump the minor version. If you remove any API calls, set the last number to 0 after incrementing the first number -- this will bump the major soversion. Is that what you were saying? If so, I totally missed it. Too early I guess. :) > i want to keep the version of the package the same as the lib .so > version. it's cleaner and nicer. unless we go screw things up and > decide to name release versions without thought to compatibility - > then we need to do the below, but if we do things right, we don't > need to. if i break abi i will cal the package evas-2.0.0.tar.gz (or > whatever) as opposed to 1.0.0. i will make the package release # the > same as the lib .so version as needed. That will work as long as everyone understands that the *package* version is now a slave to the *library* version, not the other way around. We have to make sure the package is versioned based on the ABI, not just force the soversion to match whatever arbitrary package version we pick. It's nice and clean, that's true -- but it's going to take discipline! > nooo - i don't want to make a new .so for each version with > -release. there is no need to put the link version directly in the > library name. i ONLY need to do this if i plan on having 2 or more > versions of the lib around AND application needing to explicitly > link at compile time to either a newer or older version. eg. gtk2 vs > gtk1. (at that point - mayaswell have new lib names too as the > version is now part of the lib name anyway as far as ld.so etc. are > concerned). Right, but it does give one the ability to use the package version when building the library without breaking soversioning. But if you're wanting to keep them in sync by focusing on the library version, not the package version, that's fine. It's just not the way most projects seem to think these days. :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "The world isn't run by weapons any more, or energy, or money. It's run by little 1's and 0's, little bits of data. It's all just electrons! There's a war out there, old friend -- a world war, and it's not about who's got the most bullets. It's about who controls the information: what we see and hear, how we work, what we think. It's all about the information." -- Cosmo (Ben Kingsley), "Sneakers" - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas raster
Hi,
This patch somehow broke ETK. I just reverted it and it works fine. To
test just run etk_test and select the tree test, then try to scroll
the list using the scrollbar button. Nothing happens. I don't have
time to work on it right now, but if somebody can take a look at it,
it would be great.
BR
On 10/5/07, Enlightenment CVS <[EMAIL PROTECTED]> wrote:
> Enlightenment CVS committal
>
> Author : raster
> Project : e17
> Module : libs/evas
>
> Dir : e17/libs/evas/src/lib/canvas
>
>
> Modified Files:
> evas_object_gradient.c evas_object_image.c evas_object_line.c
> evas_object_main.c evas_object_rectangle.c evas_object_smart.c
>
>
> Log Message:
>
>
> 1. default object size to 0x0
> 2. remove some float numbers (were cast anyway)
> 3. make smart object mmove/resize only called if the obj changes
>
> ===
> RCS file: /cvs/e/e17/libs/evas/src/lib/canvas/evas_object_gradient.c,v
> retrieving revision 1.18
> retrieving revision 1.19
> diff -u -3 -r1.18 -r1.19
> --- evas_object_gradient.c 28 Jun 2007 23:22:20 - 1.18
> +++ evas_object_gradient.c 5 Oct 2007 04:52:09 - 1.19
> @@ -779,10 +779,10 @@
> obj->cur.color.g = 255;
> obj->cur.color.b = 255;
> obj->cur.color.a = 255;
> - obj->cur.geometry.x = 0.0;
> - obj->cur.geometry.y = 0.0;
> - obj->cur.geometry.w = 32.0;
> - obj->cur.geometry.h = 32.0;
> + obj->cur.geometry.x = 0;
> + obj->cur.geometry.y = 0;
> + obj->cur.geometry.w = 0;
> + obj->cur.geometry.h = 0;
> obj->cur.layer = 0;
> obj->cur.anti_alias = 1;
> obj->cur.interpolation.color_space = EVAS_COLOR_SPACE_ARGB;
> @@ -809,8 +809,8 @@
> o->cur.map.direction = 1;
> o->cur.fill.x = 0;
> o->cur.fill.y = 0;
> - o->cur.fill.w = 32;
> - o->cur.fill.h = 32;
> + o->cur.fill.w = 1;
> + o->cur.fill.h = 1;
> o->cur.fill.angle = 0.0;
> o->cur.fill.spread = EVAS_TEXTURE_REFLECT;
> o->cur.type.name = strdup("linear");
> ===
> RCS file: /cvs/e/e17/libs/evas/src/lib/canvas/evas_object_image.c,v
> retrieving revision 1.57
> retrieving revision 1.58
> diff -u -3 -r1.57 -r1.58
> --- evas_object_image.c 30 Sep 2007 15:04:51 - 1.57
> +++ evas_object_image.c 5 Oct 2007 04:52:10 - 1.58
> @@ -1786,10 +1786,10 @@
> obj->cur.color.g = 255;
> obj->cur.color.b = 255;
> obj->cur.color.a = 255;
> - obj->cur.geometry.x = 0.0;
> - obj->cur.geometry.y = 0.0;
> - obj->cur.geometry.w = 32.0;
> - obj->cur.geometry.h = 32.0;
> + obj->cur.geometry.x = 0;
> + obj->cur.geometry.y = 0;
> + obj->cur.geometry.w = 0;
> + obj->cur.geometry.h = 0;
> obj->cur.layer = 0;
> obj->cur.anti_alias = 0;
> obj->cur.render_op = EVAS_RENDER_BLEND;
> @@ -1808,8 +1808,8 @@
> /* alloc obj private data */
> o = calloc(1, sizeof(Evas_Object_Image));
> o->magic = MAGIC_OBJ_IMAGE;
> - o->cur.fill.w = 32.0;
> - o->cur.fill.h = 32.0;
> + o->cur.fill.w = 1;
> + o->cur.fill.h = 1;
> o->cur.smooth_scale = 1;
> o->cur.border.fill = 1;
> o->cur.cspace = EVAS_COLORSPACE_ARGB;
> ===
> RCS file: /cvs/e/e17/libs/evas/src/lib/canvas/evas_object_line.c,v
> retrieving revision 1.22
> retrieving revision 1.23
> diff -u -3 -r1.22 -r1.23
> --- evas_object_line.c 28 Jun 2007 23:22:20 - 1.22
> +++ evas_object_line.c 5 Oct 2007 04:52:10 - 1.23
> @@ -222,10 +222,10 @@
> obj->cur.color.g = 255;
> obj->cur.color.b = 255;
> obj->cur.color.a = 255;
> - obj->cur.geometry.x = 0.0;
> - obj->cur.geometry.y = 0.0;
> - obj->cur.geometry.w = 32.0;
> - obj->cur.geometry.h = 32.0;
> + obj->cur.geometry.x = 0;
> + obj->cur.geometry.y = 0;
> + obj->cur.geometry.w = 0;
> + obj->cur.geometry.h = 0;
> obj->cur.layer = 0;
> obj->cur.anti_alias = 1;
> obj->cur.render_op = EVAS_RENDER_BLEND;
> ===
> RCS file: /cvs/e/e17/libs/evas/src/lib/canvas/evas_object_main.c,v
> retrieving revision 1.60
> retrieving revision 1.61
> diff -u -3 -r1.60 -r1.61
> --- evas_object_main.c 3 Oct 2007 04:09:36 - 1.60
> +++ evas_object_main.c 5 Oct 2007 04:52:10 - 1.61
> @@ -7,11 +7,11 @@
> * if they are moved to the position they are already in
> * (e.g. if they are in 0,0 and you call evas_object_move(o, 0, 0)
> */
> -#define FORWARD_NOOP_MOVES_TO_SMART_OBJS
> +//#define FORWARD_NOOP_MOVES_TO_SMART_OBJS
>
> /* likewise, for resizes
> */
> -#define FORWARD_NOOP_RESIZES_TO_SMART_OBJS
> +//#define FORWARD_NOOP_RESIZES_TO_SMART_OBJS
>
> static Evas_Object_List *
> get_layer_objects_last(Evas_Layer *l)
> ===
> RCS file: /cvs/e/e17/libs/evas/src/lib/canvas/evas_object_rectangle.c,v
> retrieving revision 1.12
> retri
Re: [E-devel] Selective build of modules for evas/ecore
On Fri, 5 Oct 2007 09:57:54 -0700 Michael Jennings <[EMAIL PROTECTED]> babbled: > On Friday, 05 October 2007, at 15:39:46 (+0200), > Albin Tonnerre wrote: > > > I'm quite dubious about the fact they'd want to package what they're > > developping (during the devel process). Just too much overhead to > > rebuild the package everytime you change something > > Talk about being hypocritical! You're USING software that's in > development, and you're PACKAGING it too! What is it that gives a > packager some unalienable right to package up development software and > yet somehow fails to give the authors themselves that very same right? > :-P > > > While this might help, they don't necessary belong to the source > > folder. If the packagers want exemples, easy enough for them to > > checkout the trees from a dedicated branch on the cvs. > > The packaging info belongs with the source. That's where it's been > since the very earliest days when bma was doing our Debian packages, > and there's no reason at all for them to not stay. > > > I understand that you want to provide samples etc, but as there are > > already ubuntu and debian repos available, I'm not quite sure that > > it is used by any user at all (of course falko uses them for the > > debian repo, but still), and it's mostly why I believe that moving > > them out of the sources wouldn't hurt much > > If they really bother you that much, "cvs remove" them from your > anonymous checkout or write yourself a little wrapper script. :-) > > > I can't remember having ever distributed evas as a single package > > since I started maintaining the ubuntu packaging a year back. > > Just because you didn't make a particular mistake means neither that > you haven't made others (not accusing...I have no idea...just making > the point) nor that others haven't made them. We make mistakes > ourselves as well. But we (collectively, not me in particular) have > the advantages of having been doing Debian packaging for a very long > time and having made, corrected, and learned from numerous errors in > that time. > > > While I understand that you experienced issues with various > > packagers, please keep in mind that it's not because some of them > > don't things the way they should be that every single packager does. > > The problem is not that some or all packagers do things in any > particular (or right, or wrong) way. That's not the issue. > > The simple fact is this: We keep RPM spec files in CVS because > developers (like me) and others like to be able to build RPM packages > directly from the CVS repository. (It doesn't get much easier than > "./autogen.sh && make distcheck && mzbuild" IMHO.) We keep Debian > packaging directories in the same place for the same reason. We will > continue to do so because it makes things easier and better for us, > the developers. CVS is *our* territory; it does not belong to end > users, packagers, distribution maintainers, or anyone else, as we've > been saying over and over again for years. CVS is a developer tool, > not a user tool. > > > Either ways, a good communication upstream <-> packging will be > > better than forcing packagers into doing things, and making their > > job harder (yes, keeping debian/ in the sources make our job > > harder. surprising isn't it ?) > > Sorry, but if keeping one little directory in CVS makes your job > harder, you're doing it wrong. It's painfully easy to use various > combinations of "rm," "cvs rm," and "$EDITOR" to perform whatever > changes you deem necessary to your local copy of any tree you > choose. :-) i think though it might be that we ALSO add the debian dir and its contents in the dist tarballs - ie make dist and the tarball we ship ships with debian packaging info. personally i think this is a very nice service to early adopters, packagers for all distros to get the source and go "ooh - they did 90% of my work for me already! thanks!" or for us devs to take any snapshot or release and insta-build (i always loved rpm -ta blah-1.0.0.tar.gz if you just throw a .spec file into the tarball). debian doesn't have such an instant-build tool as such as debian "policy" vetos us shipping debian packaging info (yes - debian has a tonne of anal policies. no point in arguing over them), so to do the same you need to botch up a script of your own. so i'm willing to leave the debian/ dir in cvs, but remove it from the dist tarballs (going to keep spec - i know you and many others like and and can instantly use it direct from the tarball). > Michael > > -- > Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> > Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) > --- > "When all is said and all has come undone; when the sun, the moon, > and stars grow dark; before the days of youth are left in vain; > before the dust reclaims its own again. Breathe on me, br
Re: [E-devel] improvements of configure
On Fri, 5 Oct 2007 10:19:59 -0700 Michael Jennings <[EMAIL PROTECTED]> babbled:
> On Saturday, 06 October 2007, at 01:50:06 (+0900),
> Carsten Haitzler wrote:
>
> > i know how it works :) i just don't want to work with libtool's
> > abortion of a versioning system. i want to do it the old fashioned
> > way. .so major version changes == abi break. old calls removed or
> > changed abi or functionality. minor version == calls added, but no
> > functionality changes in existing calls. micro == no calls added or
> > removed, no functionality changes, just internal fixes/improvements.
>
> That's really how it works already, or at least pretty close. The
> middle number is micro, so if anything at all changes, you bump the
> middle number. If you add new API calls, you increment BOTH the first
> and third number; this will keep the major soversion the same and bump
> the minor version. If you remove any API calls, set the last number
> to 0 after incrementing the first number -- this will bump the major
> soversion.
>
> Is that what you were saying? If so, I totally missed it. Too early
> I guess. :)
yeah - that's what i;m saying. the fact that it has a different numbering
scheme just is painful - have to maintain 2 sets of numbers (yes - the forumla
is what you say to convert from package version to .so version going via
version-info). i'm only saying that we have a lump of shell script there
instead of a big wad of comments to do that for us. i.e. (in extreme ugliness
and a quick 1 minute job in an email:
VER=1.2.3.045
...
AM_INIT_AUTOMAKE(edje, $VER)
...
VMAJ=`echo $VER | awk -F . '{printf("%s", $1);}'`
VMIN=`echo $VER | awk -F . '{printf("%s", $2);}'`
VMIC=`echo $VER | awk -F . '{printf("%s", $3);}'`
SNAP=`echo $VER | awk -F . '{printf("%s", $4);}'`
version_info=`expr $VMAJ + $VMIN`":$VMIC:$VMIN"
AC_SUBST(version_info)
etc.
i.e. - just a lump of shell logic that takes the package version and creates
a .so version from it that matches by appeasing the libtool version info gods
and sacrificing a little math to them.
a slight problem here is that the .so version for evas is already 1.0.0 so we
are going to make an exception until release (need to check other libs too).
> > i want to keep the version of the package the same as the lib .so
> > version. it's cleaner and nicer. unless we go screw things up and
> > decide to name release versions without thought to compatibility -
> > then we need to do the below, but if we do things right, we don't
> > need to. if i break abi i will cal the package evas-2.0.0.tar.gz (or
> > whatever) as opposed to 1.0.0. i will make the package release # the
> > same as the lib .so version as needed.
>
> That will work as long as everyone understands that the *package*
> version is now a slave to the *library* version, not the other way
> around. We have to make sure the package is versioned based on the
> ABI, not just force the soversion to match whatever arbitrary package
> version we pick.
>
> It's nice and clean, that's true -- but it's going to take discipline!
indeed! absolutely. and i hope to maintain that discipline. until 1.0 i'm
reserving the right to break anything and ignore the version - but from 1.0 on
it's "slave to the abi" - we break abi - we go evas 2.0 or edje 3.0 etc. etc.
and onwards as needed, and not because of some marketing desires to call it 2.0
or 3.0 etc. :)
> > nooo - i don't want to make a new .so for each version with
> > -release. there is no need to put the link version directly in the
> > library name. i ONLY need to do this if i plan on having 2 or more
> > versions of the lib around AND application needing to explicitly
> > link at compile time to either a newer or older version. eg. gtk2 vs
> > gtk1. (at that point - mayaswell have new lib names too as the
> > version is now part of the lib name anyway as far as ld.so etc. are
> > concerned).
>
> Right, but it does give one the ability to use the package version
> when building the library without breaking soversioning. But if
> you're wanting to keep them in sync by focusing on the library
> version, not the package version, that's fine. It's just not the way
> most projects seem to think these days. :)
yeah - i know :) i'm trying to avoid that though by wanting to use .so
versioning as much as we can without juping into package versioning. that is a
work around after a project has been around long enough to require
compatibility back to older apps (gtk1 vs gtk2 for example) and allowing
development on older branches of the code etc. to continue. i hope not to get
into that boat :)
> Michael
>
> --
> Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]>
> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org)
> ---
> "The world isn't run by weapons any more, or energy, or money. It's
> run by little 1's and 0's, little bits of data. It's all just
> electr
