GNU/Linux Desktop (GUI Application) Testing Project (GNU LDTP) is aimed at producing high quality test automation framework and cutting-edge tools that can be used to test GNU/Linux / Solaris Desktop and improve it. It uses the Accessibility libraries to poke through the application's user interface. The framework also has tools to record test-cases based on user-selection on the application. GNU LDTP is a GNU/Linux / Unix GUI application testing tool. It runs on GNU/Linux / Solaris / FreeBSD / Embedded environment (Palm source). GNU LDTP core framework uses Appmap and the recorded test-cases to test an application and gives the status of each test-case as output. As of now, GNU LDTP can test any GNOME application based GUI applications, which are accessibility enabled, Mozilla, Openoffice.org, any Java application (should have a UI based on swing) and KDE 4.0 applications based on QT 4.0 (based on the press releases by KDE).
Created attachment 190894 [details] new ebuild for ldtp-1.5.1
First of all I would like to thank for your submission. Here are some issues I noticed in your ebuild. * You can use global "nls" USE flag instead of "localization" * I think there's no need for goptionparse USE flag since that exists since glib 2.6 you could leave that to default. * Python support should be optional (i.e you need a python USE flag) * LICENSE is invalid it should be LGPL-2.1 (according to sources) * dodoc needs a die call on error and COPYING should be omitted. * Does Java support need dev-java/java-access-bridge (This is probably something that upstream knows) * Hardcoded .x paths in SRC_URI could be generated by functions from versionator eclass.
Hi Nagappan, would you be able to comment on , * Does Java support need dev-java/java-access-bridge (This is probably something that upstream knows)
Created attachment 191640 [details] a second version of ldtp ebuild
Thanks for your comments Serkan. Here is a newer version based on your suggestion. >* You can use global "nls" USE flag instead of "localization" Done. >* I think there's no need for goptionparse USE flag since that exists since >glib 2.6 you could leave that to default. Since the minimal requirement of glib is 2.2, this USE flag is still necessary for the user whose glib is under version 2.6, I think. >* Python support should be optional (i.e you need a python USE flag) According to README, python in fact is mandatory. >* LICENSE is invalid it should be LGPL-2.1 (according to sources) Done. >* dodoc needs a die call on error and COPYING should be omitted. Done but not sure why COPYING should be omitted here. > * Does Java support need dev-java/java-access-bridge (This is probably > something that upstream knows) > * Hardcoded .x paths in SRC_URI could be generated by functions from > versionator eclass. Done. Additionally, I adds 2 USE flags for the following additional support: - Python Imaging Library (http://www.pythonware.com/products/pil/) to compare two images - Pystatgrab (http://www.i-scream.org/pystatgrab/) to moitor memory and CPU utilization
Created attachment 191643 [details] a second version of ldtp ebuild
Another issue is which category should this package go? x11-misc, dev-util, or something else?
Till now i have kept it under x11-misc.
(In reply to comment #5) > Thanks for your comments Serkan. You're welcome > Since the minimal requirement of glib is 2.2, this USE flag is still necessary > for the user whose glib is under version 2.6, I think. You can force 2.6. > >* Python support should be optional (i.e you need a python USE flag) > According to README, python in fact is mandatory. configure script has --without-pythonmodules switch to disable that > >* dodoc needs a die call on error and COPYING should be omitted. > Done but not sure why COPYING should be omitted here. We already have the license under /usr/portage/licenses > > * Does Java support need dev-java/java-access-bridge (This is probably > > something that upstream knows) Any news on this? > Additionally, I adds 2 USE flags for the following additional support: > - Python Imaging Library (http://www.pythonware.com/products/pil/) to compare > two images > - Pystatgrab (http://www.i-scream.org/pystatgrab/) to moitor memory and CPU > utilization These need to depend on python USE flag as well.
(In reply to comment #9) > > According to README, python in fact is mandatory. > configure script has --without-pythonmodules switch to disable that This is required only for embedded environment, where they don't have Python. So, I don't recommend this option for regular x86/64 system. Thanks
(In reply to comment #3) > Hi Nagappan, would you be able to comment on , > > * Does Java support need dev-java/java-access-bridge (This is probably > something that upstream knows) > Yes, if user want to automate Java related application, then they need this package, as of now we haven't made this as a mandatory requirement in Debian / Ubuntu / SUSE / Fedora systems. Maybe this is good to have as an optional requirement. Thanks
Thanks for clarifications, Nagappan. In the light of these, * I would still suggest python as an optional dependency to disable python modules on demand. * Add java USE flag to pull java-access-bridge optionally.
(In reply to comment #12) > Thanks for clarifications, Nagappan. In the light of these, > > * I would still suggest python as an optional dependency to disable python > modules on demand. Guess, I should explain the LDTP architecture here. Its a client server setup. The C code base is the engine (server) which takes the command from Python client and process the request, do some action / verification and returns the status to client. So, we need both of them in regular testing environment, unless the server and client has to run on two different machines. > * Add java USE flag to pull java-access-bridge optionally. This change is fine with me. Thanks
A third version: * remove goptionparse USE and set >=dev-libs/glib-2.6; * add python USE flag, but only for dev-python/pystatgrab and dev-python/imaging. dev-lang/python is still mandatory; * add java USE flag for java-access-bridge support; * sort IUSE & DEPEND by alphanumeric; Please review.
Created attachment 191692 [details] Third version
(In reply to comment #15) > Created an attachment (id=191692) [edit] > Third version > * java-access-bridge is probably RDEPEND only. * gettext is DEPEND only. * I couldn't decide on USE flag for extra dependencies. (Maybe python maintainers may suggest, I'm CCing them) By the way did you test it in all those arches?
(In reply to comment #16) > * java-access-bridge is probably RDEPEND only. I make it RDEPEND now. > * gettext is DEPEND only. Done. > * I couldn't decide on USE flag for extra dependencies. (Maybe python > maintainers may suggest, I'm CCing them) Waiting for python maintainers' reply. > By the way did you test it in all those arches? I've tested both on x86 and amd64 and all PASS. For ia64, I'm not sure since lack of such machine. Navtej, could you please comment on this one? Additionally, I've made python USE flag to RDEPEND only.
Created attachment 192036 [details] A Fourth version of ldtp-1.5.1 ebuild
(In reply to comment #17) > (In reply to comment #16) > > * java-access-bridge is probably RDEPEND only. > I make it RDEPEND now. > > > * gettext is DEPEND only. > Done. > > > * I couldn't decide on USE flag for extra dependencies. (Maybe python > > maintainers may suggest, I'm CCing them) > Waiting for python maintainers' reply. > > > By the way did you test it in all those arches? > I've tested both on x86 and amd64 and all PASS. > For ia64, I'm not sure since lack of such machine. > Navtej, could you please comment on this one? Sorry dont have any ia64 machine around to test. Would appreciate if someone can test that. > > Additionally, I've made python USE flag to RDEPEND only. >
Created attachment 193211 [details] a fifth version since there is no ia64 platform available for test, I remove ia64 keyword from this ebuild. Navtej, any comment on this modification? Thanks
(In reply to comment #20) > Created an attachment (id=193211) [edit] > a fifth version > > since there is no ia64 platform available for test, I remove ia64 keyword from > this ebuild. > We already have LDTP 1.6.0 released, probably we can propose that for here ? Thanks
(In reply to comment #20) > Created an attachment (id=193211) [edit] > a fifth version > > since there is no ia64 platform available for test, I remove ia64 keyword from > this ebuild. > > Navtej, any comment on this modification? > > Thanks Should be ok until someone can test and confirm. >
Created attachment 193359 [details] eubild for ldtp-1.6.0 Here is the ebuild for 1.6.0. The only difference between these 2 ebuild files is the file name. Tested both under amd64 and x86.
(In reply to comment #23) > Created an attachment (id=193359) [edit] > eubild for ldtp-1.6.0 > > Here is the ebuild for 1.6.0. > The only difference between these 2 ebuild files is the file name. > > Tested both under amd64 and x86. > Great, thanks :)
Hi Serkan, Could you please review the new ebuild and give some comments? Thanks
Is there anyone can tell what the status of this bug is? Or anything need to be done before it goes into portage tree? Thanks
Adding Project Sunrise.
Hi Serkan, I synced sunrise overlay today but can not find any ldtp ebuild there. Is there any extra work need to be done to add ldtp into sunrise? Please let me know if anything I can help. Thanks.
Just three things : - for each arch in KEYWORDS, did you test it ? (and put ~arch instead of arch) - Header is out dated ;) - Do you know eapi 2 ? (see devmanual), It could be interesting to use it for src_configure() for example, and avoids to call emake because already made by src_compile() (to conclude: more maintainable, and factorized) except these items, nice work :)
(In reply to comment #28) > Hi Serkan, > > I synced sunrise overlay today but can not find any ldtp ebuild there. > > Is there any extra work need to be done to add ldtp into sunrise? > Please let me know if anything I can help. > > Thanks. > The ebuild is not added by Serkan or anyone else. Serkan just added sunrise to CC of this bug. If you want to give others the chance for an easy access, i suggest you read [1] and [2] and add the ebuild to sunrise yourself. :-) [1] = http://www.gentoo.org/proj/en/sunrise/ [2] = http://overlays.gentoo.org/proj/sunrise/
Romain, Thanks a lot for your response, and please see my reply inline. Also thank you Thomas for your kind clarification, which makes know the process better. :) (In reply to comment #29) > Just three things : > > - for each arch in KEYWORDS, did you test it ? (and put ~arch instead of arch) I've tested it on both x86 and amd64 without any error. > > - Header is out dated ;) Updated. > > - Do you know eapi 2 ? (see devmanual), It could be interesting to use it for > src_configure() for example, and avoids to call emake because already made by > src_compile() (to conclude: more maintainable, and factorized) Updated. > > except these items, nice work :) >
Created attachment 199430 [details] Updated version based on Romain's comment
(In reply to comment #32) > Created an attachment (id=199430) [edit] > Updated version based on Romain's comment > Looks fine to me. Thanks Jing.
- src_compile() can be dropped because already defined by ebuild.sh - in src_configure() "if [[ -x ${ECONF_SOURCE:-.}/configure ]]" isn't necessary, because already tested by econf itself (see ebuild.sh) - econf doesn't need a || die - "nls" USE flag necesseraly needed ? (enable it as default should be best, because the nls support has usually 75 % of chances to be used) - What do you think about your KEYWORDS ? are you sure this ebuild is really stable ? are you sure to have tested each arch ? :)
Thx for your kind comments and here is my reply inline: (In reply to comment #34) > - src_compile() can be dropped because already defined by ebuild.sh done. > - in src_configure() "if [[ -x ${ECONF_SOURCE:-.}/configure ]]" isn't > necessary, because already tested by econf itself (see ebuild.sh) done. > - econf doesn't need a || die done. > - "nls" USE flag necesseraly needed ? (enable it as default should be best, > because the nls support has usually 75 % of chances to be used) done. > - What do you think about your KEYWORDS ? are you sure this ebuild is really > stable ? are you sure to have tested each arch ? done. > :) >
Created attachment 199890 [details] A third version of ldtp-1.6.0.ebuild
Hi. Are you still interested in packaging LDTP for Gentoo? Thanks for letting us know.
Actually, feel free to reopen if you want LDTP to make it into the tree.
