On 12/19/2010 06:52 PM, Carsten Haitzler (The Rasterman) wrote: > 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.
I've been silent this whole thread. Enough of that. Raster is correct here (IMO). You enable some obscure tests that are meant for devs, then complain when you're 'build' system cannot handle them. Lemme just say, as a 15+ Year Gentoo User/Dev, that it's your build system which is the issue. Don't get me wrong, I love Gentoo ... love the control it gives. Happy for the fact that I do not have to be 'stuck to' something that someone else thinks is correct for me. I know what's correct for me, thanks ;) But, if said system cannot produce an X11 connection, that you cannot expect something like ecore_x to function, whether that be "TEST" or "Release" ... either way, it will fail. Enough said of this. If you want the tests, they are still in SVN. Download and run'em till your heart is content. Facts being, E17, Efl (and others related as such), run the way they were meant to (for the most part, not precluding any bugs)... without an X connection, are you really going to expect some X11 test/demo app to run ?? (I know I would not expect that ;) (Behind ya mate !) dh > 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. > -- "If C gives you enough rope to hang yourself, then C++ gives you enough rope to bind and gag your neighborhood, rig the sails on a small ship, and still have enough rope to hang yourself from the yardarm" - Anonymous quote from the The UNIX-HATERS Handbook ------------------------------------------------------------------------------ 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
