On 03/04/2010 02:23 AM, Carsten Haitzler (The Rasterman) wrote: > On Wed, 03 Mar 2010 19:20:13 +0100 Thomas Sachau <to...@gentoo.org> said: > >> Hi, >> >> i tried to compile all packages, which are as ebuilds in official Gentoo >> enlightenment overlay from svn and i found some issues, which i will list >> below: >> >> Missing README file, when README.in exists, lets automake bail out: > > if you used the autogen.sh we provide - it'd work. but you aren't. :) so.. i'd > say this is your problem. (our autogen.sh touches README to get around this > pedanticism in autofoo).
You used the right word: "get around", it is just a workaround for a bug in your repo, independent on how you call it or where you point at. The autogen.sh itself is also a workaround too, i use eautoreconf (a function for Gentoo ebuilds doing basicly the same as autoreconf) for months now, there is no problem with autotools themselves. > >> eet >> embryo >> imlib2_loaders >> ecore >> evas >> >> autogen.sh containing lines, which hide issues in svn (like removing >> autotools related files or touching README), the issues should be fixed >> themselves, not worked around in autogen.sh: > > wrong. this is a pedanticism that is just there to be a pain. we want README > versioned - thus generated from the .in file when we do things like make dist > etc. so... if you choose to be pedantic - you get to live with the > consequences as our ideas and autofoo's developers disagree - and we fix that > up in autogen.sh. autotools isnt quite doing what we want and so we work > around > it. :) the rm's are there due to issues encountered years back and i'm not > going to remove something that works - as all you do is run into the same bug > again eventually and end up having to fix it again as above. if it ain't broke > - don't fix it. as our work isnt working on autofoo - we work around it where > we can. The removal of autotools files does just hide it, when someone does commit them, also they should not committed in the first place. Drop the line and you directly get it on next rebuild try, else you will never see the issue. Do you really want to hide bugs with workaround instead of fixing them? For README: Creating an empty README file in the repo will really fix the issue and does not create any pain with versioned README. Touching it in autogent.sh is also just a workaround hiding the real issue. And "there was some bug some years ago realated to this" is no argument at all, you did not in any way show us a link to the bug, not exactly how it showed up nor how it could be happen again today. With your "aint broken, dont fix it" attitude, you could also argue to not update anything. Why would you start development of e17, e16 did work and still does work, doesnt it? > >> eet >> embryo >> imlib2_loaders >> ecore >> evas >> >> Packages checking for ecore-data, which is now disabled by default: >> >> ewl >> wlan module > > happy to have them break as they are not being maintained actively. 3rd party > modules in E-MODULES-EXTRa are the responsibility of the person who put them > in > - people insisted on wanting svn to put their modules into - so we allowed it > and then the vast majority of these maintainers/developers vanished. dont > build > things from e-modules-extra. we dont intend to release anything from there - > so > dont expect any support for things there. we will release what is needed for > e17 only - and this isn't. (added - elementary will get a 1.0 too). You have commit powers, i dont, so i report those. It is upon you (or anyone else with svn access) to fix them or not, but you cannot tell me, that you did not know about them. > >> Makefile.am containing "ACLOCAL_AMFLAGS = -I m4", also that dir does not >> exist: >> >> execwatch module >> mpdule module >> winselector module > > same as above. if you want to build all of these you are on your own. upstream > isnt supporting them. we are supporting: > eina, eet, evas, ecore, embryo, edje, efreet, e_dbus, e > added bonus: > elementary As above: I dont have access, so all i can do is reporting it, fixing is on your (=e upstream) side. -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
