On Sun, 19 Dec 2010 13:26:21 +0100 Thomas Sachau <to...@gentoo.org> said:
> Am 19.12.2010 04:51, schrieb Carsten Haitzler (The Rasterman): > > On Sat, 18 Dec 2010 17:14:02 +0100 Thomas Sachau <to...@gentoo.org> said: > > > >> Attached is a build log with the failures. > > > > ok. since your position is that tests should work even if u enable them and > > they cant connect to a display, or that we need to go fine-graining tests > > just so you can --enable things that you wouldn't understand were they to > > fail, i've decided to remove all tests from src trees. > > I did not say exactly that. This is your view. I already told you, that <Tommy[D]> discomfitor: i asked you before, what about an option to only enable the other tests? I dont think, you should require everyone testing it as the user running X, not everyone likes your rm -rf / in there that's fine-graining the tests. it starts with splitting into x vs non-x ones. then what about ones that require a network connection? (test dns works - if we had them) and so on. > packagers should test the package, before they add them and if upstream > already has a test suite, it is the easiest way to test the package. As > already said, tests should not require external services like X to run and if > some tests need such a service, they should be skipped or there should be an > option to skip them. And once you said, that those tests require an X server > running as the same user, who does run the tests, i asked for making those > tests optional, but at least you did not react to that reqest. because i had already told you that you shouldnt be enabling the tests as they are not for you. they are not for packagers. the basis for your request is that you SHOULD run them and that x ones are "bad" and shouls be disabled from normal tests etc. etc. - i didnt response because the entire premise that you should be running the test suite in an ebuild is wrong in the first place. > > it seems gentoo (some) users and/or developers are unable to take the hint > > of "you enabled tests manually yourself - they are never enabled unless you > > explicitly enable them, then that makes it your problem". you shot yourself > > in the foot and then ask us why it hurts. we get the build logs that told > > you the problem (ecore_x_init fails - can't connect to a display somewhere) > > in the way intended (for developers to run test suites to see if they broke > > something fundamental while working on code), then that just wastes our > > time. > > See above for the tests requiring a running X server. > > Now, you removed the tests completly instead of adding an option to just skip > the X-related tests. Also it does not seem like many devs actually used the > ecore tests, now probably noone will use them and noone will find any issue > with their usage. So in the end, it looks more like you did shoot yourself in > the foot. i moved them to the TEST dir - they can be built and run there (sure - missing build infra. that's easy enough to fix). > > i'm grumpy because i tried to explain it the short way (on irc) "you enabled > > tests - they fail. don't enable them. if u cant run them in their expected > > test env they will fail". that fell on deaf ears, so the tests are > > summarily removed out of the src trees. if anyone has an issue with it - > > talk to thomas and/or gentoo developers. this week i replied to his issue > > twice. once in a trac ticket and again here. > > A simple "those tests require running a X server as the same user" and adding > a way to skip those would be faster, easier and better for everyone. they dont require an xserver of the same user id - they require to be able to connect to an xserver. doesn't matter who/where.. as long as DISPLAY specifies an xserver you can connect to. it's pretty obvious that you'd need that if you are testing ecore_x - ecore_con could very naturally require that dns lookups work and actually do tests that lookup real known hostnames remotely and even connect to known servers on the internet as part of a test suite. e_dbus could require a running dbus daemon to connect to and test quit. the list goes on. tests are not for packagers. not for ebuilds. not for making debs or rpm's. but you insist that that is otherwise and that -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
