On Thu, 04 Mar 2010 20:13:55 +0100 Thomas Sachau <[email protected]> said:
> On 03/04/2010 02:23 AM, Carsten Haitzler (The Rasterman) wrote: > > On Wed, 03 Mar 2010 19:20:13 +0100 Thomas Sachau <[email protected]> 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. it's not a bug. it's our code. we want it to generate the package info a certain way. autofoo developers and their standdards want to make our lives more difficult by making what can be automated, a manual process. > 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. it is not a workaround. maybe you are too young to realise - autoreconf is fairly new. we've beeen doing autogen.sh for over a decade. it's incredibly common. and it works. it has worked for a decade. we're not changing things all of a sudden because you want to use different methods and they happen to not work. use the autogen.sh or deal with the problems you create yourself. autogen.sh is a DEVELOPER tool - for US DEVELOPERS - upstream to use. that is its point and intent. it's our own business. our end product is a tarball with a configure script in it etc. etc. - ie the product of "make dist". anything along the way to producing that tarball with source in it that compiles is our choice - we only happen to expose it because your svn is public. you walk into our svn - you walk into our factory/workshop- and thus, you play by our rules. whatever you, gentooo etc. may think of autoreconf, doing "touch README" etc. etc. etc. - that is our production process and it's staying as we have our reasons. and we gave them already. > >> 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 they never were committed - or if so by accident and they have been removed. i am relatively sure it was some work around for some autofoo issue long ago - it doesnt hurt anything now and it keeps the fix in case the issue is still at hand for a local autofoo. unlike you, i do a lot of work that involves cross-compiling, sdk's and such where you get stuck with atuofoo you cant go and change - often old versions or patched autofoo. what we have now works with cross-dev toolkits. it has for years. making changes is a good way to ensure it won't work with these older sdk's and maybe not existing ones. it ain't broke - i.e. it works, so don't fix it. i have spent enough days of my life hunting down obscure cross-dev issues and autofoo bugs and issues to simply not want to deal with them. they are a distraction from what we do and if we have a fix - then we keepit until such a time that it doesn't work. the fact you use autoreconf is not our problem. you are changing the conditions - not us. > 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. files that get generated - being put in the repo, is wrong, as the repo contains now 2 copies of something - the original and the output - this leads to problems like "someone sees the README and edits - then wonders why their edits keep vanishing". it also leads to missing changes in commits - u modified src but havent re-run configure to modify dest and thus commit missing both changes. it's just generally wrong. it's our production line and it has worked fine for years. > 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. it is an argument.. why? because it's our code. our repository. those bugs have existed - i remember vaguel working on it - no, i didn't have a link- hell i dont think i had a link at the time. it was discovered, fixed so it worked and did no harm, then we moved on. > 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? you don't work on software as your profession do you? you focus on your core WORK. autofoo is not the work. it is a distraction - a tool to get it done. you sticky tape up your broken tools and march on with your WORK. our work is our code - not autofoo. > >> 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. i'm letting you - and other packagers know for the umpteenth time that only a subset of svn is going to be released or looked after and what it is. that is e17 and just the libraries needed for it. despite this people take everything else in svn and then come to us and complain because their gnetoo overlay decided to build everything and we end up with the complaints - despite saying "we will only release and support this" it is the packagers of gentoo, debian, etc. etc. that end up putting a much bigger burden on our shoulders we explicitly said we didnt want. > >> 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. letting you know - .. that you shouldnt be packaging or releasing anything other than the set given. from svn. until told otherwise. but i know thiss won't change. it hasnt changed for a decade. people find stuff in svn - people ask to dump their stuff in svn. people build it. people end up on our inboxes or irc channel asking for help on it. we are saying "you're on your own with anything outside the list above" :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
