On Sun, 19 Dec 2010 15:29:36 +0100 Thomas Sachau <to...@gentoo.org> said:
> Am 19.12.2010 14:16, schrieb Carsten Haitzler (The Rasterman): > > 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: > >>> > >> 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. > > There is just the OPTION to run those tests inside the ebuild, no suggestion > and no requirement for that. then why are you reporting bugs to us. if it's an option that you enable, then you look into it. you enabled the tests - ecore_x test fails on init which is obviously not the case in real life as if that failed e, elementary.. in fact every gui app wouldnt work. it wouldnt get past first base. obviously there isn't a problem with ecore_x or the build as such - it's a problem with your build system not providing a useful test environment. instead of just disabling tests (ie just not turning it on) you want US to change our test suite to work around your build system so you can keep turning it on? > You said, they are for developers to see, if they broke something. So running > those tests should not harm any packager or user. But if some dev did not run > the tests and broke something, it will prevent others from installing this > broken version. they don't harm a packager or user... if you don't run them. if you do - provide a working test environment. for most things thats not much at all - but for ecore_x... guess what.. that's a working xserver connection. > >>> 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. > > Let me quote you from last night: > <raster> just because DISPLAY is inherited in the build doesnt mean > that the build even runs as your UID <raster> nor that it inherits the > sams x authatiry <raster> x authority > > I did add a second X server for the user running the tests and they do work > that way. All i needed was this info. that info was in the build log output. why am *I* explaining how YOUR OS ebuild works? i dont use gentoo. never have. never likely will. why do I have to tell you how to fix issues of your own creation when you turn on a test suite and you use/know/control the build environment? why do i, yet again, have to read for people? it's there in the log output - ecore_x_init() fails. come on. thats so complex and mysterious you have to post it to us? > Please try to stay at the technical level in the future. Just writing 1 or 2 > lines about the requirements of ecore_x tests would have saved all of us a > good amount of time and would not have raised the barrier for developers to > run the tests. i did - "don't enable the tests as part of a packaging process". (packaging processes - build systems almost always provide lots of restrictions, like trying to filter out suid binaries, limit filesystem and/or network and other access, access to parts of or most of a host filesystem and so on). a packaging process creates a very restricted environment often and in such a case - tests are not going to always work. i TRIED that. a very short version. i got tired of explaining it. you insist on running tests AND putting the work on diagnosing the failures that are obviously not real positives, onto us. THATS what is annoying. you FIRST try and figure out what it is about your setup that may break things. if after that you can't figure it out, then you turn to us. if your ability to work things out turns out to be very limited.. then dont play with things you can't figure out (unless it really is a deep down code problem), then turn the tests off. that is what i said at the very start. -- ------------- 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
