Re: [E-devel] ecore tests fail with beta3 tarballs
All, I've not been around here long enough to know/care _where_ tests are located. Nor have I studied the tests in question (so I probably don't know what I'm talking about :-) ) However I have been a developer long enough to know that ideally all tests should be self contained. Tests should never rely on arbitrary existing env. variables and ideally not on the presence of any subsystems that the build env doesn't already need to know about. If it is possible for a test to work, it should work. Low-level function level tests can often be platform independent and self-contained, higher level tests can often use a loop-back approach. Tests which rely on special environments outside the source code should be skipped if those environments are not available. Graphics based tests should (in this case) be rendered in a software renderer and output images (png etc) compared to a reference image for Pass/Fail tests. Tests which rely on humans to pas/fail them are useful for quick debugging but are not helpful as part of an automated regression testing process. IMHO tests should either PASS or be automatically SKIPPED they should never FAIL. my 0.02c worth Now I suppose I should study the tests, but probably only after I've looked at simplifying the build process. cheers Kim On 19/12/2010, at 2:51 PM, Carsten Haitzler (The Rasterman) wrote: 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. 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. 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. the above is here for the benefit of the rest of e devs as to why i just did this. -- - 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 -- 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
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010, Kim Lester wrote: All, I've not been around here long enough to know/care _where_ tests are located. Nor have I studied the tests in question (so I probably don't know what I'm talking about :-) ) However I have been a developer long enough to know that ideally all tests should be self contained. Tests should never rely on arbitrary existing env. variables and ideally not on the presence of any subsystems that the build env doesn't already need to know about. If it is possible for a test to work, it should work. Low-level function level tests can often be platform independent and self-contained, higher level tests can often use a loop-back approach. Tests which rely on special environments outside the source code should be skipped if those environments are not available. Graphics based tests should (in this case) be rendered in a software renderer and output images (png etc) compared to a reference image for Pass/Fail tests. Tests which rely on humans to pas/fail them are useful for quick debugging but are not helpful as part of an automated regression testing process. IMHO tests should either PASS or be automatically SKIPPED they should never FAIL. tests are disabled by default. so they are skipped tests are for developpers, not packagers if they fail, open a ticket Vincent my 0.02c worth Now I suppose I should study the tests, but probably only after I've looked at simplifying the build process. cheers Kim On 19/12/2010, at 2:51 PM, Carsten Haitzler (The Rasterman) wrote: 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. 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. 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. the above is here for the benefit of the rest of e devs as to why i just did this. -- - 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 -- 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 -- 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
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010 09:11 +0100, Vincent Torri wrote : tests are for developpers, not packagers That is terribly wrong. Packagers care about testsuites for one simple reason: as thoroughly as developers may be testing the code, that will never guarantee proper behaviour on the system on which the code is built. When creating packages for Debian, I /do/ care about the testsuites because the testsuite not failing is the only reliable thing telling me the lib is not utterly broken on the system it is being built on. I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. Please reconsider your decision. Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- 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
Re: [E-devel] ecore tests fail with beta3 tarballs
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 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. 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'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. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010 10:28:20 +0100 Albin Tonnerre lu...@debian.org said: On Sun, 19 Dec 2010 09:11 +0100, Vincent Torri wrote : tests are for developpers, not packagers That is terribly wrong. Packagers care about testsuites for one simple reason: as thoroughly as developers may be testing the code, that will never guarantee proper behaviour on the system on which the code is built. When creating packages for Debian, I /do/ care about the testsuites because the testsuite not failing is the only reliable thing telling me the lib is not utterly broken on the system it is being built on. I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. problem is the usual gentoo one. people going beyond their abilities then dumping the support burden back onto us. ecore has a test that tests ecore_x - funnily enough that requires that you can connect to the xserver specified by $DISPLAY. not totally weird that that breaks in an ebuild. but i had had enough of saying dont enable them - they aren't by default - and this is one reason why and simply not getting through. tests are for developers so when they modify code they can check they didn't break anything. packagers can't do much with a test suite. does the linux kernel have a test suite that is run when people build packages? does xorg have one? i can continue with the list. they don't. any test suites are part of the development cycle not the packaging cycle, but as they are in the sr4c tree, some gentoo devs seem to think that they should work as part of their ebuild (which is packaging). this is not the case. -- - 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
Re: [E-devel] ecore tests fail with beta3 tarballs
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
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010 22:14 +0900, Carsten Haitzler wrote : On Sun, 19 Dec 2010 10:28:20 +0100 Albin Tonnerre lu...@debian.org said: On Sun, 19 Dec 2010 09:11 +0100, Vincent Torri wrote : tests are for developpers, not packagers That is terribly wrong. Packagers care about testsuites for one simple reason: as thoroughly as developers may be testing the code, that will never guarantee proper behaviour on the system on which the code is built. When creating packages for Debian, I /do/ care about the testsuites because the testsuite not failing is the only reliable thing telling me the lib is not utterly broken on the system it is being built on. I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. tests are for developers so when they modify code they can check they didn't break anything. packagers can't do much with a test suite. At the very least, they can notice the testsuite is failing and investigate possible issues (and report them when/if approriate). does the linux kernel have a test suite that is run when people build packages? does xorg have one? i can continue with the list. they don't. Glibc does have one. GCC has one. And they do find bugs - especially tricky, architecture-specific ones. any test suites are part of the development cycle not the packaging cycle, but as they are in the sr4c tree, some gentoo devs seem to think that they should work as part of their ebuild (which is packaging). this is not the case. Are you purposedly ignoring my point here? I just explained why those suites are useful in the process of building packages. And not only to Gentoo devs, since I've been using them pretty much since they've been around. Besides, moving them away from src/ is basically making them harder for just about everyone, not just packagers. As bored as you might be by some people's behaviour, this is wrong. I think you did get your point across fairly clearly, but let's be realistic: you're not doing anyone - not even yourself - a favour by moving the tests away. Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- 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
Re: [E-devel] ecore tests fail with beta3 tarballs
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. 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. 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: rasterjust because DISPLAY is inherited in the build doesnt mean that the build even runs as your UID rasternor that it inherits the sams x authatiry rasterx 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. 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. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- 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
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010, Albin Tonnerre wrote: On Sun, 19 Dec 2010 09:11 +0100, Vincent Torri wrote : tests are for developpers, not packagers That is terribly wrong. Packagers care about testsuites for one simple reason: as thoroughly as developers may be testing the code, that will never guarantee proper behaviour on the system on which the code is built. When creating packages for Debian, I /do/ care about the testsuites because the testsuite not failing is the only reliable thing telling me the lib is not utterly broken on the system it is being built on. I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. Please reconsider your decision. are you packaging the test suite ? Vincent -- 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
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010 19:49 +0100, Vincent Torri wrote : On Sun, 19 Dec 2010, Albin Tonnerre wrote: On Sun, 19 Dec 2010 09:11 +0100, Vincent Torri wrote : tests are for developpers, not packagers That is terribly wrong. Packagers care about testsuites for one simple reason: as thoroughly as developers may be testing the code, that will never guarantee proper behaviour on the system on which the code is built. When creating packages for Debian, I /do/ care about the testsuites because the testsuite not failing is the only reliable thing telling me the lib is not utterly broken on the system it is being built on. I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. Please reconsider your decision. are you packaging the test suite ? I'm not sure what you mean exactly, but anyway: the testsuite is run when the package is built for at least eina and ecore. Cheers, -- Albin Tonnerre -- 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
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010 20:02 +0100, Vincent Torri wrote : I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. keeping the unit tests inside the source code is a step backward ? Because that's what I want. Putting the unitt tests outside makes impossible (at least, i don't see anyway of doing that) coverage support. And that is for me a big step backward. I might have been misleading. I completely agree that tests should remain within the source tree - that's why I wrote that email in the first place :) Cheers, -- Albin Tonnerre -- 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
Re: [E-devel] ecore tests fail with beta3 tarballs
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
Re: [E-devel] ecore tests fail with beta3 tarballs
On 12/19/2010 09:26 PM, Thomas Sachau wrote: 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. You want to verify EFL, which is all about graphics, but you don't want to run X? thanks, Mike -- 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
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sat, 18 Dec 2010 17:14 +0100, Thomas Sachau wrote : Attached is a build log with the failures. Are you by any chance building on a headless machine, or in a tty ? If so, that failure is expected - the test fails whenever ecore can't reach the X server. I ended up disabling this test completely for the Debian packages. Cheers, -- Albin Tonnerre -- 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
Re: [E-devel] ecore tests fail with beta3 tarballs
hey On Sat, 18 Dec 2010, Thomas Sachau wrote: Attached is a build log with the failures. thanks for the log, but: 1) configure gcc to display english messages 2) please strip the log so that it contains the usefull messages 3) if it's about DSO (i looked at the log and it is too huge to really catch the error easily), then do not use beta3, but svn repository regards Vincent -- 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
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sat, 18 Dec 2010 17:14:02 +0100 Thomas Sachau to...@gentoo.org said: Attached is a build log with the failures. gentoo ebuild problem - not ecore. pay closer attention to what failed and have a think about it :) -- - 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
Re: [E-devel] ecore tests fail with beta3 tarballs
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. 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. 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. the above is here for the benefit of the rest of e devs as to why i just did this. -- - 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
